From: Martin Marshall <law@martinmarshall.com>
To: emacs-devel@gnu.org
Subject: Code snippets/template consolidation and potential improvements
Date: Wed, 17 Jan 2024 16:48:52 -0500 [thread overview]
Message-ID: <877ck7r5q3.fsf@martinmarshall.com> (raw)
(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
next reply other threads:[~2024-01-17 21:48 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-17 21:48 Martin Marshall [this message]
2024-01-18 6:48 ` Code snippets/template consolidation and potential improvements Eli Zaretskii
2024-01-18 18:29 ` Martin Marshall
2024-01-18 21:13 ` Stefan Kangas
2024-01-18 22:03 ` Stefan Monnier
2024-01-19 8:27 ` João Távora
2024-01-19 16:40 ` Martin Marshall
2024-01-19 23:58 ` João Távora
2024-01-21 16:16 ` Martin Marshall
2024-01-19 6:52 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=877ck7r5q3.fsf@martinmarshall.com \
--to=law@martinmarshall.com \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.