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 <address@hidden> 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
> address@hidden
> http://lists.gnu.org/mailman/listinfo/emacs-devel
>


-- 
Benjamin Rutt