snippet.el

snippet.el

[Richard Stallman]

I'm interested in hearing what people think of snippet.el
and how it compares, for convenience, with skeleton.el and tempo.el.
Should we install snippet.el?
If we install snippet.el, are the other two still useful?
Can we mark one or both obsolete?

Re: snippet.el

[joakim]

Richard Stallman <rms@gnu.org> writes:

> I'm interested in hearing what people think of snippet.el
> and how it compares, for convenience, with skeleton.el and tempo.el.
> Should we install snippet.el?
> If we install snippet.el, are the other two still useful?
> Can we mark one or both obsolete?

Could msf-abbrev.el, "mode specific abbreviations" please also be
included in this discussion? I havent used snippet.el, but Ive used the
other ones, and of these  msf-abbrev is the most convenient.

It has the same basic idea as snippet, but also lets the user store
templates in text-files.

-- 
Joakim Verona

Re: snippet.el

[Stefan Monnier]

>> I'm interested in hearing what people think of snippet.el
>> and how it compares, for convenience, with skeleton.el and tempo.el.
>> Should we install snippet.el?
>> If we install snippet.el, are the other two still useful?
>> Can we mark one or both obsolete?

> Could msf-abbrev.el, "mode specific abbreviations" please also be
> included in this discussion? I havent used snippet.el, but Ive used the
> other ones, and of these  msf-abbrev is the most convenient.

There's a whole bunch of alternatives indeed.  I remember looking at Tempo
and Skeleton and thinking it'd be good to unify them.
Both are used by other Elisp packages so we can't just drop them without
providing backward compatibility.


        Stefan

Re: snippet.el

[Tassilo Horn]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> I'm interested in hearing what people think of snippet.el
>>> and how it compares, for convenience, with skeleton.el and tempo.el.
>>> Should we install snippet.el?
>>> If we install snippet.el, are the other two still useful?
>>> Can we mark one or both obsolete?
>
>> Could msf-abbrev.el, "mode specific abbreviations" please also be
>> included in this discussion? I havent used snippet.el, but Ive used the
>> other ones, and of these  msf-abbrev is the most convenient.
>
> There's a whole bunch of alternatives indeed.  I remember looking at Tempo
> and Skeleton and thinking it'd be good to unify them.
> Both are used by other Elisp packages so we can't just drop them without
> providing backward compatibility.

I like the syntax and simplicity of snippet.el.  I've read a message of
the snipped author on emacs-sources to make snippet and tempo compatible
somehow.  But those message is about two years old and I don't know what
happened since then.

And msf-abbrev.el is quite nice, too.  But there are two versions out
there and when I tried to use it the abbrevs for message-mode didn't
work, so I dropped it.

So before installing any of those packages, I'd check if anybody really
feels responsible for them and is willing to fix bugs and things.

Bye,
Tassilo

Re: snippet.el

[Richard Stallman]

    Could msf-abbrev.el, "mode specific abbreviations" please also be
    included in this discussion? I havent used snippet.el, but Ive used the
    other ones, and of these  msf-abbrev is the most convenient.

    It has the same basic idea as snippet, but also lets the user store
    templates in text-files.

Would someone like to study msf-abbrev.el alongside snippet.el
and write a report on the advantages of each?

Also please send me a copy of msf-abbrev.

Re: snippet.el

[Richard Stallman]

    There's a whole bunch of alternatives indeed.  I remember looking at Tempo
    and Skeleton and thinking it'd be good to unify them.
    Both are used by other Elisp packages so we can't just drop them without
    providing backward compatibility.

If one of these packages is clearly better than tempo and/or skeleton,
we could mark the latter obsolete and begin converting the packages
that use it.

Re: snippet.el

[Richard Stallman]

These packages are probably not so complex that they are a big maintenance
burden.  Therefore, I think the main question is, which package is best?

Re: snippet.el

[Benjamin Rutt]

I am the author of msf-abbrev.el and am following this thread and can
give some comments.  If people would like to see what it does the best
way is to watch the demo linked off of
http://www.bloomington.in.us/~brutt/msf-abbrev.html

The primary objections I would see people on this list having to
including this package in Emacs would be:

1) a portion of the user interface code deals with setting up and
handling form-like fields within Emacs buffer.  I originally intended
to factor the general-purpose form stuff out into a separate
library,called fld.el, but finally decided to include this code
in-line within msf-abbrev.el for ease of installation.  So, the
package currently pollutes the fld- namespace.  This can be remedied
with some simple effort, such as renaming functions with the fld-
prefix to msf-abbrev-fld- prefix.

2) I feel that it currently suffers from an unresolved
bootstrapping/loading issue.  When it loads up, for each directory in
`msf-abbrev-root', if the directory names a mode, say 'foo-mode', then
if foo-mode exists in Emacs, all the files within 'foo-mode' directory
will have abbreviations created with the same name as the file.  The
problem is that foo-mode must be loaded in Emacs prior to msf-abbrev
loading, so that this detection logic will work.  If anyone has ideas
here, let me know.

3) When a matching directory is detected for say foo-mode, msf-abbrev
will first look for foo-mode-abbrev-table and install the
abbreviations there, if the variable exists (shouldn't all proper
major modes define this?).  If not, it will add a series of
define-abbrev calls to foo-mode-hook.  This scheme generally works
okay, although there are some modes which seem to do funny things like
clearing out their abbrev tables on load which prevents the scheme
from working.

On 10/27/07, Richard Stallman <rms@gnu.org> wrote:
> These packages are probably not so complex that they are a big maintenance
> burden.  Therefore, I think the main question is, which package is best?
>
>
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel
>


-- 
Benjamin Rutt

Re: snippet.el

[Richard Stallman]

The issues you mention would need to be addressed somehow if we
decide to install msf-abbrev.el.  But they would not prevent us
from installing it with changes if we decide that is what we want.

Right now the question is whether we want that.

Can someone please study msf-abbrev.el and snippet.el, then report on
how they compare with each other and with skeleton.el and tempo.el?