I don't know what Leo is, but the usual solution to this sort of problem is to introduce some kind of quoting convention, e.g. @@ gets passed through as a single @ to Python, any other @something gets treated as a Leo directive. Is there some reason that wouldn't work?
Yes, in Leo's case there is a strong reason for not using an "escape" or "quoting" mechanism. As I said in my original post, not using an escape mechanism turns out to be the correct choice. The basic problem is that there are two (or is it three?) views of the data in the Leo world: the view presented to the user in the outline, the data in the .leo file, and the data in the derived files. Leo has a mechanism for automatically converting data in derived files into the one or two other forms. This is call "untangling". It turns out that it is extremely difficult to handle escapes properly when untangling. I know this sounds weird, and it's true nevertheless. If the @ syntax goes through, Leo will have to allow users to define their own lead-in string, and the format of derived files will have to change a bit to specify what the lead-in string is. It's not a huge deal, I think. It would surely be much easier than changing how Leo tangles or untangles code. BTW, I find the arguments for list-after-def to be persuasive, viz., that annotations should clearly be part of a function. Edward -------------------------------------------------------------------- Edward K. Ream email: edreamleo@charter.net Leo: Literate Editor with Outlines Leo: http://webpages.charter.net/edreamleo/front.html --------------------------------------------------------------------