Closed rickyson96 closed 3 months ago
Hi! I think this would be some kind of syntactic sugar added on top of code tags - however, I want always code tags to be pure Elisp and nothing else, in order to make Verb's design overall simpler, and helping to avoid surprises.
However, Verb-variables are really nothing special, just a buffer-local alist stored in the verb--vars
variable. Verb provides a user-friendly way of setting them and inspecting them, but that's it. If you want something less verbose, you can always use just (setq myvar "hello")
and then later {{myvar}}
in a code tag - that will work fine!
So in conclusion I appreciate the idea, but it does not fit with my vision of how Verb and code tags work overall.
I see. One benefit I can think of when using verb variables is that it doesn't pollute the global variables, hence the feature request. But I get your point.
Thanks for the clarification and thanks for the immensely useful package!
No problem! Feel free to suggest other ideas in the future 👍🏻
AFAIK, one would use
{{(lisp)}}
to make a dynamic variable inside a request. One main use of this is to use`{{(verb-var some-var)}}
here. In fact, I have bunch of those in my verb file.What do you think about simplifying this, so that we could use
{{some-var}}
which would use the result of(verb-var some-var)
?One thing that would possibly break is that if anyone relies on
{{some-var}}
to resolve emacs' variable, but we could side step that by checking emacs' variable when(verb-var some-var)
is not found, and if the name clashes, we could use(identity some-var)
for emacs' variable instead.