>> Because as said, I would expect EXP to be a valid symbolic expression, >> since that is what manual says. I could have used lambda as well, but >> why keeping undocumented bug if it can be fixed? > > We are open to fixing the documentation in this area. Both in the manual > and in the docstrings. > >>> Changing the current meaning of the form would break configurations that >>> Salready rely on it. >> >> Yeah, I am aware of it myself. >> >> Question is how many people use that feature at all? > > Packages like doct use it. I personally use it. I have seen many people > using it, for example, to auto-generate heading :ID: on capture template > level.
I am using %[] to insert entire files with org-capture-fill-template. Those files themselves are templates where I use %() in lots of places to generate the content of the file. Not being able to just type %(some-var) is elaborate. I can't believe nobody has complained about it yet :). >> ... All templates >> I have seen, use just simple pre-defined escapes and interactive escapes. I >> don't doubt that someone is using them, question is if it is worth of not >> being able to use variables %() just to not break few templates, which would >> be easily fixed (just add a pair of parenthesis around). >> >> We could also have it as opt-in, keep the old one as the default, and the >> new one as the opt-in. > > If we document that (EXP), not EXP should be a valid expression, we are > good. In practice it will make it least more clear why using a variable failes :) It would be even better if the documentations spells out clearly: can't use variables only functions. Anyway, that still means the usage in a bigger template, like a file generator is more elaborate than needed. But if you don't want it, so it is. Thanks for looking at it.
