Newsgroups: gnu.emacs.help
Path: sparky!uunet!cis.ohio-state.edu!gnu.ai.mit.edu!rms
From: r...@gnu.ai.mit.edu (Richard Stallman)
Subject: Merging features from Lucid Emacs
Message-ID: <9207010945.AA19149@mole.gnu.ai.mit.edu>
Sender: dae...@cis.ohio-state.edu
Organization: Gatewayed from the GNU Project mailing list help-gnu-em...@prep.ai.mit.edu
Date: Wed, 1 Jul 1992 01:45:09 GMT
Lines: 88

I've had a chance to read the news file from Lucid Emacs.
Here is a list of some features I think might be good to adapt
for use in Emacs 19.

* The "Zmacs" region-handling option (but the functons and variables
  should be renamed, because the term "zmacs" is not descriptive except
  for a small group of people).

* The handling of truenames, if it can be done without assuming a
  `realname' system call which most systems don't have.

* The Lucid menu support.

  This has some advantages over what we have now.

  I hesitate to adopt it as it stands because it uses an entirely new
  interface and data structure.  I have an idea that I think would make
  menus cleaner and more convenient.  It's not that I dislike the ideas
  in the Lucid design, so much as that there are other ideas I also
  like.

  I think menus should be a special case of keymaps.  Emacs 19 already
  has partial support for this--each entry in a keymap can have a
  documentation string which would be the string to display in the
  menu.  You can also include strings by themselves in the keymap; these
  could serve as header lines for the menu.  All that we need is code to
  display the menu based on the keymap, and a way to mark a keymap as
  one that should be displayed as a menu when appropriate.

  "When appropriate" means whenever the keymap is reached via mouse
  activity.  If such a keymap is reached via keyboard commands, it
  should read more keyboard input, just as keymaps are currently used.

  One convenient side effect of this change is that dialog boxes would
  work automatically.  They would simply be menus which contain
  definitions for mouse clicks.

  So I'm looking for someone who'd like to implement this.

  Having a menu bar would be a good feature also.  But I'd like it to
  work without using any widgets; I don't think adding 300k to the
  program's size is negligible.

* It's possible that the Lucid code for handling X selections and the
  clipboard is more general than what we have.  If so, then perhaps we
  should install the Lucid code.  I don't fully understand selections and
  clipboards, or the precise selection features of Lucid Emacs and Emacs 19,
  so I don't know how they compare.

* Other features that would be nice to install include supporting
  local variables in the -*- construct, and the improved tags
  package.  Can someone tell me where to find these packages?

* Some of the functions associated with mouse tracking might be useful too.

* We will use the optimizing byte-compiler sooner or later.


The Lucid Emacs features not listed above either came from Emacs 19 to
begin with, have been installed in Emacs 19 already, are duplication
of features we have implemented also, or pose some sort of problem.
Some examples:

* We are using the Lucid mail abbreviation feature.

* We have generalized input events and keymaps to include function
  keys and mouse clicks, but without needing any additional primitive
  data types.

* We still do redisplay at interrupt level.  This is useful because it
  lets Emacs repaint the window even while it is busy executing Lisp
  code.

* We haven't implemented timers in Emacs itself, but
  I'm not convinced they are important enough to be worth added code
  in Emacs.  The wakeup subprocess seems to do the job.

* We don't have anything comparable to the Lucid extent features.
  These are useful features, but if they are to coexist with permanent
  intervals, then the implementation has to be completely different.

  We could merge the Lucid extent support as an interim measure if
  people are adamant for it.  Keep in mind, though, that any code
  you write to use this interface would have to be rewritten for Emacs 20,
  because the interface in Emacs 20 will use different concepts.

  I hesitate to support features now, knowing that in a year or two
  I would replace them with something incompatible.