unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Code snippets/template consolidation and potential improvements
@ 2024-01-17 21:48 Martin Marshall
  2024-01-18  6:48 ` Eli Zaretskii
  0 siblings, 1 reply; 10+ messages in thread
From: Martin Marshall @ 2024-01-17 21:48 UTC (permalink / raw)
  To: emacs-devel

(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



^ permalink raw reply	[flat|nested] 10+ messages in thread
end of thread, other threads:[~2024-01-21 16:16 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-01-17 21:48 Code snippets/template consolidation and potential improvements Martin Marshall
2024-01-18  6:48 ` 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

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).