arthur miller <[email protected]> writes: > You have been clear in the first one too, I did understood what you mean > :). I am just not sure how much extra functionalty you would like. If > you only want that "keyword" thing, as said I think it is possible with > %: notation.
Yes, I was thinking to add %:keyword, with :keyword that can optionally be defined inside a template, as in doct. > I was more thinking about how users percieve the framework. It is > probably easier to just say, "a shortcut notation" %:some-variable for > %(eval some-variable) than to explain entire new placeholder perhaps? I > forgot to mention last time, you also skip the :full-lisp t property, > even with %:some-variable. I prefer it too for that reason. I wasn't > really happy with :full-lisp myself, but it was an easy way to switch > between parsers. > > For the doc/manual string, I would prefer to be explicit about saying: > "If you want to insert a variable value, you have to use a function to > obtain the value, for example %(format "%s" variable) or %(eval > variable). In the latter case, the variable has to contain a value of > string type." I have previously pushed https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=0f534d5d6 Do you want to expand that commit? > Anyway, sorry for the rant, back to doct, :keyword seem to be a outside > of the template too. If you don't want :keyword to end outside of the > template, like my :full-lisp, than something like %{} would be > preferable. Than one can't just use read on the string, but has to parse > tokens in %{} separately, i.e. write a parser, but its not a big problem > I think. I am actually ok with :keyword to be outside the template. My problem with :full-lisp is mostly that the *meaning* of the template will subtly change depending on that keyword. If we have a separate syntax that is clearly dependent on something outside template (like %:keyword already is - it depends on the last link captured), that's totally fine IMHO. > If you would to include something of these suggestion/brain-stormes > whatever to call them, what is the plan to procede? If you want I can > give you a bug-report to remove untabify and new-line and patches, or > can you or Max just add them yourself? Both are trivial, but some > wording about changes and potential incompatibilty for those (?) who > rely on that behaviour is needed, since they affect the end-user. Since > both are outside of "parsers" and affect the entire function and end > result, they can't be added as opt-in. Option is to add a new property > for each which I think is overkill, but we can discuss it if you want a bug > report for that. Their breaking nature is exactly the reason why I want to discuss in separate thread. We need to think about potential bad consequences of naive fix. > Adding new parser, whichever it is, %: or %{} can be done relatively > easy I think. I am not sure TBH how much extra functionality you want, > so I don't know if I am the best person to help you, but at this point > in time I am quite familiar with org-capture-fill-template, I can try. > If you, Max or someone else have spare time, and can do it, it would > be appreciated, but since I have triggered this, I can at least try to > help with this. Implementing new non-critical features is something I have to put at the bottom of my todo list, prioritizing bugs and high-level discussions instead. If you work on the patches, it will be the fastest way to get things done. For context, I have 948 feature requests in my notes with high-priority items like timezone support being on top there, and non-features being yet higher in the priorities. Smaller things are going to take very long time (if done at all) unless someone else steps in. -- Ihor Radchenko // yantar92, Org mode maintainer, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
