emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] Citation syntax: a revised proposal


From: Nicolas Goaziou
Subject: Re: [O] Citation syntax: a revised proposal
Date: Sun, 15 Feb 2015 19:25:13 +0100

Richard Lawrence <address@hidden> writes:

>> However, it would be nice to integrate it somehow with the syntax. Maybe
>> something like
>>
>>   [cite: ... @key ...; ... @key2 ... |latex: :prop val |html: :prop val]
>>
>
> But I think there are three reasons this does not quite improve on what
> I proposed:
>
> 1) It looks like it only supports properties directed at specific
> backends.  How should users specify custom properties that they want to
> be handled in multiple backends (by their own filter)?

They cannot (unless they want to use something like "|custom: ...").

Note they cannot either for regular elements using attributes. The
reason is that multiple back-end properties are very rare. For
example, :width hasn't the same unit in "ox-latex" and "ox-html".

> 2) It requires us to decide *now* on conventions for specifying
> properties to specific backends

Indeed. This is also part of the syntax we're trying to define, isn't
it?

> (and also to build a parser for them, instead of just calling `read'),

We won't be calling "read". OTOH, there's already
`org-export-read-attribute', which does a reasonable job.

> instead of just using arbitrary s-expressions and seeing what people
> come up with in the future. (See my reply to Tom for more about how
> I was thinking this part of the syntax would evolve.)

The point is that this syntax (which isn't new in this thread, excepted
the "|" character) is extensible at will. It can evolve.

> 3) Putting the properties inside the brackets introduces an (admittedly
> very minor) additional restriction on suffix text, and can't be used
> with the simple syntax for in-text citations.  (See my reply to Rasmus
> on this point.)

I don' think this is a real issue. Each back-end can decide what command
should be used for simple syntax. It is even possible to provide
a defcustom for it.


Regards,



reply via email to

[Prev in Thread] Current Thread [Next in Thread]