* snippet.el @ 2007-10-26 3:49 Richard Stallman 2007-10-26 8:30 ` snippet.el joakim 0 siblings, 1 reply; 9+ messages in thread From: Richard Stallman @ 2007-10-26 3:49 UTC (permalink / raw) To: emacs-devel 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? ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: snippet.el 2007-10-26 3:49 snippet.el Richard Stallman @ 2007-10-26 8:30 ` joakim 2007-10-26 18:38 ` snippet.el Stefan Monnier 2007-10-27 2:28 ` snippet.el Richard Stallman 0 siblings, 2 replies; 9+ messages in thread From: joakim @ 2007-10-26 8:30 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: snippet.el 2007-10-26 8:30 ` snippet.el joakim @ 2007-10-26 18:38 ` Stefan Monnier 2007-10-26 21:10 ` snippet.el Tassilo Horn 2007-10-27 13:57 ` snippet.el Richard Stallman 2007-10-27 2:28 ` snippet.el Richard Stallman 1 sibling, 2 replies; 9+ messages in thread From: Stefan Monnier @ 2007-10-26 18:38 UTC (permalink / raw) To: joakim; +Cc: emacs-devel >> 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: snippet.el 2007-10-26 18:38 ` snippet.el Stefan Monnier @ 2007-10-26 21:10 ` Tassilo Horn 2007-10-27 13:58 ` snippet.el Richard Stallman 2007-10-27 13:57 ` snippet.el Richard Stallman 1 sibling, 1 reply; 9+ messages in thread From: Tassilo Horn @ 2007-10-26 21:10 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: snippet.el 2007-10-26 21:10 ` snippet.el Tassilo Horn @ 2007-10-27 13:58 ` Richard Stallman 2007-10-28 14:40 ` snippet.el Benjamin Rutt 0 siblings, 1 reply; 9+ messages in thread From: Richard Stallman @ 2007-10-27 13:58 UTC (permalink / raw) To: Tassilo Horn; +Cc: emacs-devel 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? ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: snippet.el 2007-10-27 13:58 ` snippet.el Richard Stallman @ 2007-10-28 14:40 ` Benjamin Rutt 2007-10-29 9:21 ` snippet.el Richard Stallman 0 siblings, 1 reply; 9+ messages in thread From: Benjamin Rutt @ 2007-10-28 14:40 UTC (permalink / raw) To: rms; +Cc: Tassilo Horn, emacs-devel 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: snippet.el 2007-10-28 14:40 ` snippet.el Benjamin Rutt @ 2007-10-29 9:21 ` Richard Stallman 0 siblings, 0 replies; 9+ messages in thread From: Richard Stallman @ 2007-10-29 9:21 UTC (permalink / raw) To: Benjamin Rutt; +Cc: tassilo, emacs-devel 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? ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: snippet.el 2007-10-26 18:38 ` snippet.el Stefan Monnier 2007-10-26 21:10 ` snippet.el Tassilo Horn @ 2007-10-27 13:57 ` Richard Stallman 1 sibling, 0 replies; 9+ messages in thread From: Richard Stallman @ 2007-10-27 13:57 UTC (permalink / raw) To: Stefan Monnier; +Cc: joakim, emacs-devel 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: snippet.el 2007-10-26 8:30 ` snippet.el joakim 2007-10-26 18:38 ` snippet.el Stefan Monnier @ 2007-10-27 2:28 ` Richard Stallman 1 sibling, 0 replies; 9+ messages in thread From: Richard Stallman @ 2007-10-27 2:28 UTC (permalink / raw) To: joakim; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2007-10-29 9:21 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2007-10-26 3:49 snippet.el Richard Stallman 2007-10-26 8:30 ` snippet.el joakim 2007-10-26 18:38 ` snippet.el Stefan Monnier 2007-10-26 21:10 ` snippet.el Tassilo Horn 2007-10-27 13:58 ` snippet.el Richard Stallman 2007-10-28 14:40 ` snippet.el Benjamin Rutt 2007-10-29 9:21 ` snippet.el Richard Stallman 2007-10-27 13:57 ` snippet.el Richard Stallman 2007-10-27 2:28 ` snippet.el Richard Stallman
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).