Richard Lawrence <richard.lawre...@berkeley.edu> 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,
