[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#57069] [PATCH v2] etc: Add tempel snippets.
From: |
Liliana Marie Prikler |
Subject: |
[bug#57069] [PATCH v2] etc: Add tempel snippets. |
Date: |
Tue, 30 Aug 2022 11:51:33 +0200 |
User-agent: |
Evolution 3.42.1 |
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
- [bug#57069] [PATCH 3/4] etc: Add tempel snippet for license:., (continued)
[bug#57069] [PATCH v2] etc: Add tempel snippets., Nicolas Graves, 2022/08/11
[bug#57069] [PATCH v3 1/4] etc: Add tempel snippets., Nicolas Graves, 2022/08/12