arthur miller <[email protected]> writes: > I think you could relax there the requirement, and use princ under the > hood, instead of insert in org-capture-expand-embedded-elisp, without > introducing backward incompatibility. Since org-capture-fill-template is > always printing to a buffer, and return buffer string, it should be OK > to do. There is no reason to enforce string in %(). Just a suggestion.
Do you mean %(variable-name) should expand to its value and %(function-name) should expand to function call result? If yes, what about %(temporary-file-directory)? Should it call a function? get variable? >>> About opening other threads: nobody has answered on the other one, so I >>> guess opening more threads is not best use of the time and energy, >>> neither mine nor yours. >> >> I asked you to open new threads for a reason. Mixing too many things in >> the discussion will just create a mess. For context, I actually believe > > I understand that; I am just not interested in long discussions on Emacs > mailing list. Forgive me, been there done that. If it wasn't of the interest > to > add this extra patch, and org-capture would continue to be used just for > shorter capture templates as it is used by now, than it is not a problem. > Even if I agree with what you say later on that it is a bug, and that was my > intention to say too, it is probably not important, so lets not engage in long > discussions 🙂. That was the reasoning. If your intention was not reporting a bug but supporting your patch, it is not fully clear to me what exactly you are asking for. The patch you proposed in this thread does not do anything about untabify and newline issues; it just allows custom %(...) template expansion. >> that unconditional untabification is simply a bug -- consider code >> blocks in template that are in python. Stripping tabs will be an error >> there. Similar for a new line. Regardless what we decide about changing >> template syntax for Elisp expansion, these bugs need to be fixed. That's >> why I asked to open new threads. > > That is my stand about untabify. As you say Python, and for example as I > tried to illustrate Makefiles. I am not sure it is worth much > discussions there tbh, and it is easier for you to just comment away > that line than to apply a separate pacth if I or someone else would to > send it in. > > For the newline at the end; the author explicitly say they want it, in a > comment, so I am not equally sure if it is a bug or not. I don't > understand though why they need it. Might be due to how they use > expansions elsewhere in org. I am confused. Is your intention here is to continue discussing these bugs as bugs now? (That would make this thread longer, so I feel that I miss something). >> Let me provide a more accurate link: >> https://github.com/progfolio/doct?tab=readme-ov-file#keyword-expansion >> The %{keyword} syntax from doct is pretty close to what you are talking >> about. Please check. It may be a better way to address your request. > > Aha. Ok, thanks. As said I haven't study it, just glanced over it. The > reason I suggested my patch was because I use org-capture to implement a > little "project capture" framework, so I am already using it. It would > be a minimal addition since org-capture already does something > similar and I would not need to use a third party library. Before considering patches, I feel like we need to discuss what exactly we are trying to solve. For now, I feel like we have several things at hand. >> If we were to consider the feature you are asking for, I'd go for >> something closer to doct keyword, maybe allowing %{keyword} to refer to >> %{elisp-variable} is :keyword is not defined in the template. WDYT? > > I agree. As mentioned in the above paragraph, I implemented something > similar already. I saw the glass as half full rather than half empty, > and took the opportunity to scale away anything I didn't need. For the > same reason, to avoid possible confusion I have chosen to use "$" as the > placeholder symbol. Basically I need just $() to eval lisp, but I have > kept $[], $<> and introduced also ${} as a shortcut for environment > variables. I haven't had time to test extensively yet, due to hollidays > and family time. > > I have attached my new little framework as a curiosa; still WIP. I am > happy to get critique and suggestions if anyone is interesting to take > a look at it. Could you please explain what your framework is trying to achieve? I can see that it (1) gets rid of org-capture behavior when %[...] can be expanded inside %(...); (2) changes %(...) to demand full sexp inside - %((...)) for function call; (3) adds ${ENV}. Is this framework trying to replace org-capture-fill-template? Do additional expansion before? After? -- 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>
