[bug#57069] [PATCH v2] etc: Add tempel snippets.

[Liliana Marie Prikler <liliana.prikler@gmail.com>]

Am Freitag, dem 12.08.2022 um 08:20 +0200 schrieb Nicolas Graves:
> > > +text-mode :when (git-commit-mode)
> 
> Here I have a bug when magit has never been opened before opening a
> text-mode file, saying that git-commit-mode is not defined. Not sure
> what the best way to resolve this is. Will investigate that.
A strange error indeed.  I encounter a similar one if I use emacs as
EDITOR in git.

> > I'd suggest skipping the completing-read and just (p "gnu").  Most
> > build systems should be easy enough to type without autocompletion.
> 
> But then you have to know the name and loose the listing if you're a
> beginner and not sure. I'm fine with both options. I will follow your
> suggestion if you confirm that you took this type of user into
> account and still prefer just (p "gnu").
The reason I prefer (p "gnu") is because completing-read completely
breaks tempel.  Yes, I'm aware that this won't yield complete feature
parity between tempel and yasnippet, but you have to consider that
these *are* distinct systems after all.

FWIW you could try using NOINSERT t for the p, but I'd hazard a guess
that that still won't give you the prompt at the right time with the
correct safeties.

> > Here, I think (p "url-fetch"), but (s "method") might also work.
> 
> I'm not sure I understand what you meant here. Can you write the
> final method you would get this way?
I got (p "url-fetch" method), which uses "url-fetch" as default value
and binds method.

> > Will this cl-case be dynamically recomputed?  I wonder if we can
> > get the result of the previous p/s here...
> 
> Yes it is recomputed. p/s stores the variable and for evaluations
> "Named fields are lexically bound." It works when tested, we can get
> the result of the previous p. As Daniel Mendler stressed here
> (https://github.com/minad/tempel/issues/65), there is no possibility
> to do a recursive template i.e. with a FORM evaluating to elements of
> a snippet. So the best thing we might do with conditionals is to
> return a string.
Bummer, but I got something working out of it anyway.

> > Rather than that I think adding a template (git-file-name...) which
> > expands to (file-name (git-file-name (p "name") (p "version")) and
> > variants for the others is a better idea.
> 
> In most guix packages, it is left as simply name and version strings,
> since they are defined for the package itself. I took the same
> approach as the yasnippet template, since these field are almost
> always left untouched. I don't see the benefit of this other
> approach.
The benefit would have been that auto-completion is relatively cheap,
so folks could just write git, see git-file-name, TAB, M-RET, done.

> Your other comments have been taken into account, I'm sending an
> updated series as soon as I'm done with the git-commit-mode issue.
> Feel free to send an idea for this issue if you have one! 
I see you already solved it, so I'm now processing v3.  As laid out
above, I replaced all occurrences of completing-read with simple ps, as
those are easier to work with in tempel.  I did keep your cl-case to
conditionally insert git-file-name, etc. but I fixed it up a little so
that it's dynamically recomputed.  I also fixed up the documentation
and dropped the license: completion as it was a completing-read once
more.  You could replace those with a bunch of self-expanding snippets,
but I think geiser and/or dabbrev ought to have us covered here.

Cheers