>> 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 have to admit, some time has passed and I have been doing something else, so I have almost forgot how all this looks like. Took me some time to get into it again. I have changed my mind about "%:" see below. >> 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? Looks good; thank you for very hard work! I am horrible at wording myself, forgive me for not giving you much help there. >> 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. The point is to change the meaning of the template; actually to replace it with a different parser, and it is an explicit opt-in, so I don't see it as problematic. I understand what you say, and I agree if it was something not as explicit it would be problematic for the unaware user, but in an _explicit_ opt-in, I would be fine with it. Anyway, tomatos - tomatoes :). I wasn't happy with :full-lisp either, but I needed to somehow switch between parsers. > 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. Now when I think of it, I like the %:keyword, something like this: (... "some %:foo template %:here" :foo "FOO" :here "THERE" ...) => "some FOO template THERE" However, the problem with the notation is the same one why I couldn't use just %symbol-name as expander for globally defined symbol vaules. Org-capture already reserves a big number of keywords for the (in)conveience. For example, %user-full-name would clash with predefined %u which includes a timestamp. Similarly %:name or %:group would clash with globally defined symbols with the same name. I think %: looks a bit less-intrusive on the eye than {}, but one would need some sort of overriding mechanism to set aside link types: That would complicate things, so I think {} is the way to go, or perhaps some other pair. Pipes perhaps: %|keyword|? (... "my name is %{(user-login-name)}" ...) (... "my name is %|(user-login-name)|" ...) The "local" declaration of a variable could be done within the pair: (defvar foo "FOO") (... "foo could be %{foo} or %{foo :foo "BAR"}, and is %{foo} now!" ...) => "foo could be FOO or BAR, but is ???" <-- which one? The idea is it would be BAR. The reasoning behind is that one does not need at all to introduce a keyword if it is going to be used in a single template only. If that is the case, one can just type the value directly. Here the declaration from the first template, would continue to hold in consecutive templates, but it does not look very intuitive to me. It is probably more intuitive to type: (... "foo can only be %{foo} and is %{foo}!" :foo "BAR" ...) "foo can only be BAR and is BAR!" In other words, it shadows the global value completely in all templates, which I think is completely fine. Something like that? Too complicated? Too simple? :) One could declare a keyword declared within the pair that trumps over the keyword declared in the template definition which trumps the global definition of the symbol. But I don't see anything practically meaningful in that one. It would complicate the logic for zero practical value. In general I like the idea with :keyword. It is a let in disguise, and like let-forms, it allows people to declare local variables, and not have to pollute the global environment with variables to be used just in templates. >> 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. NP, can do that. >> 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. No worries. I understand you. I'll see if I can try to find some more time.
