arthur miller <[email protected]> writes: > For others, if we are at it, I think it is much better to type > (princ default-directory) than (eval default-directory), if you gonna have > that example in a doc string or manual.
That example is already in the docstring and the manual. As for princ, it has a side effect of putting things into standard output, which may be unexpected. So, I do not think that it is better than eval. Maybe simply identity? (although it feels long) > Also, while the example gives an example of how to use a variable, what > I said from the beginning, would be good to state that explicitly in the text: > > "If you need to use variables, you have to wrap them in some function call, > i.e. (princ var)", Good idea. Let's first decide whether we want to replace eval with something else and then add explicit clarifications about variables. >> I am open to your patches, as long as some more people find them useful. > > We have seen it was more interesting to point out which doc string I > refer to, than to reflect over anything else I said, so I guess it > is not very popular demand, which is of course ok as well :). This is not true. I just wanted to focus on something we can improve quickly. Your patches need to be discussed in more details, and there is a reason I pointed your to doct package. More on this below. >>> There are also two other problems. org-capture-fill-template calls >>> unconditionally untabify. There is no note why the original author calls >>> this, but that seems unfortunate, since it does respect the users >>> choice. A user might wish to have a tab in their expanded template. For >>> my part for example, consider a templatized Makefile, something like >>> this: ... >> >> Can you please open a new thread for this? >> >>> Finally, for some reason, each expansion ends up with a new line? Is >>> that some necessary feature that org-capture templates rely on? >>> >>> Consider if I would to generate a file with a name expanded from a tempalte: >>> >>> %(project-name).asd >>> %(project-name).asd >>> >>> I have to call (string-trim ...) everywhere where I call >>> org-capture-fill-template. Can we remove that ending new line, or is >>> that expected in expanded templates? >> >> Maybe. Again, could you please open a new email thread? > 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 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. >> Have you seen https://github.com/progfolio/doct ? > > I did a web-search after you mentioned it previously and found Nicholas > package. But I haven't had time to study it, just glanced over the > readme. What is with it? As I understand he introduces different syntax, > at least what README says. I have no idea if it adds more capabilities, > if he has a different implementation completely or if it runs on the > existing org-capture. There is a good reason why I mentioned doct. It has somewhat similar ideas. Moreover, at some point, we asked to include that package into Org. 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. > I don't introduce any new syntax, I am just trying to fix a fundamental > flow, which shouldn't be there from the very beginning to make the thing > easier to work with. In like ~50 sloc, no additional libraries needed. > That would make writing bigger templates, like entire files easier > and less clunky, as shown with attached example. I can buy it is not > interesting to other people, so it is fine :). In my book, changing the meaning of the existing syntax is much worse than adding new. The fact that it is opt-in, does not change this fact. Several possible interpretations of template syntax will lead to confusion for some people. 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? -- 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>
