[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Code snippets/template consolidation and potential improvements
From: |
Martin Marshall |
Subject: |
Code snippets/template consolidation and potential improvements |
Date: |
Wed, 17 Jan 2024 16:48:52 -0500 |
(Please accept my apologies in advance for the long message. I've
tried to organize it to make it easier to digest or piece through, at
the reader's option.)
Hello, there's an item in the TODO file regarding Emacs's template
systems[1], but I'm not sure if I understand it the way it's intended.
What is meant by "consolidate", and what specific improvements should
be prioritized?
I've been looking through the templating packages for a while,
thinking about ways to improve them and writing some code. I hope to
start a discussion, obtain guidance on improvements to submit, and
coordinate with anyone else who has the time and desire to work on
this.
Here are a few ideas I have, along with some background information:
- Make the same location-jumping commands usable without regard to
which template package was used.[2]
+ Current situation: expand.el provides commands[3] for jumping
within its templates. Skeleton templates can use the same
commands to a limited extent.[4]
Observation: Only one template at a time can use the expand.el
commands. When a new template expands, it clears the markers
stored by the last template. On the other hand, this makes it
possible for expand.el abbreviations to set markers in a
non-linear order (since they don't need to be sorted with other
templates' markers).
+ Current situation: tempo.el includes its own commands for jumping
to locations within tempo templates.[5]
Observation: Unlike the expand.el commands, the markers that
tempo.el stores when expanding a template will persist between
template expansions and the locations are sorted automatically.
This allows you to nest a template inside of a surrounding
template without losing the location-markers of the surrounding
template.
Would it be desirable to have one or both packages' jumping commands
made usable for all 3 template systems?
It seems they have different benefits and drawbacks.
- Improve the expand.el package.
Expand.el makes an excellent simplified templating system, but it's
unknown to most users and its out-of-the-box method for defining
templates isn't convenient.
It improves upon traditional abbrevs by adding a single very useful
feature, the ability to jump to specified locations within the
expanded text.
+ Current situation: Defining an expand.el abbrev involves calling
'expand-add-abbrev' (or 'expand-add-abbrevs') and providing a
manually-calculated list of location indices for use by
expand.el's location-jumping commands.
Some ideas to improve the method of defining expand.el abbrevs:
* Provide an interactive method of defining expand.el templates.
Since this is the simplest of the template systems, it should
have the simplest method for defining templates. This works
much like the traditional interactive method of defining an
abbrev. You select the expansion text and call a command to
define the abbrev. But then a buffer pops up containing the
expansion text, and you can designate the jump-locations on the
text in this buffer.
This would allow creation of templates without any specialized
syntax, not even Elisp.
* Provide a function for defining an expand.el abbrev that allows
designating jump-locations by a special character in the
expansion string.
By default, this would use the "@" character, because that's
what skeletons use. But unlike a skeleton definition, this is a
text character within the expansion string, not a symbol. In
case "@" is to be part of the expanded text, a different
character can be specified by passing an optional argument to
the function call.
+ Current situation: Expand.el doesn't come with prompting of any
kind. It would be more useful if there were some way to remind
oneself what text to insert at a specific point, or provide some
default text that could be easily replaced.
I think expand.el's strength is its simplicity, but I also think
it can be improved without making it overly complex.
Idea:
* Extend expand.el templates so that a jump-location can be either
a single location or a region which becomes activated upon
reaching it with one of the jumping commands. Once activated,
the region can be left as-is, overwritten by newly typed text,
or deleted by simply pressing "DEL". This is a feature included
in many more modern template systems (e.g.\nosentn{} yasnippets, tempel
templates).
Caveat: Adding this feature might complicate consolidation of
the location-jumping commands. A potential way to alleviate
that would be to add this to skeleton.el's and tempo.el's
templates.
+ Expand.el isn't documented.
Idea:
* After adding new features and consolidating expand.el with the
other template systems, document it in the Autotyping manual
and/or the Emacs manual.
There's almost no mention of expand.el online, but I find the
simplicity of its templates quite attractive. You expand an abbrev
and can jump to locations within the expanded text. I imagine this
covers the requirements of 80-90% of templates. Most of the time
you just need some pre-written text with an easy way to change
specific parts of it.
- Consolidation in general
How should these template systems be consolidated?
+ Should there be a single function/macro for creating any type of
template?
+ Should the definition syntax itself be consolidated? (I would
think not, but the meaning of "consolidate" might encompass that.)
>From my perspective, Emacs's existing template options each fill a
role, because each comes with different levels of versatility, which
correlates to the learning curve of a user getting started with one of
them.
If you have read this far (or even if you just jumped to this
location), I thank you for your attention!
Footnotes:
[1] It reads, "** Improve the 'code snippets' support
Consolidate skeleton.el, tempo.el, and expand.el (any other?) and then
advertise/use/improve it."
[2] This was the subject of a patch I submitted a couple of days ago,
but that may have been premature.
[3] They are 'expand-jump-to-next-slot' and
'expand-jump-to-previous-slot', bound by default to "C-x a n" and
"C-x a p" respectively.
[4] The locations are specified in the skeleton using '@' symbols.
The skeleton must be added to an abbrev-table using
'expand-add-abbrev', and the commands will only work when the skeleton
has been expanded by the abbrev. They will not work when the skeleton
was expanded by calling its command (unless you've applied my patch to
expand.el and skeleton.el).
[5] The tempo.el commands are 'tempo-forward-mark' and
'tempo-backward-mark'. They have no default keybindings.
--
Best regards,
Martin Marshall
- Code snippets/template consolidation and potential improvements,
Martin Marshall <=
- Re: Code snippets/template consolidation and potential improvements, Eli Zaretskii, 2024/01/18
- Re: Code snippets/template consolidation and potential improvements, Martin Marshall, 2024/01/18
- Re: Code snippets/template consolidation and potential improvements, Stefan Kangas, 2024/01/18
- Re: Code snippets/template consolidation and potential improvements, Stefan Monnier, 2024/01/18
- Re: Code snippets/template consolidation and potential improvements, João Távora, 2024/01/19
- Re: Code snippets/template consolidation and potential improvements, Martin Marshall, 2024/01/19
- Re: Code snippets/template consolidation and potential improvements, João Távora, 2024/01/19
- Re: Code snippets/template consolidation and potential improvements, Martin Marshall, 2024/01/21
- Re: Code snippets/template consolidation and potential improvements, Eli Zaretskii, 2024/01/19