🚀 go-pugleaf

In article <JWZ.93Oct28164013@thalidomide.lucid.com> Jamie Zawinski <jwz@lucid.com> writes:
 - If there are specific pieces of functionality that you miss (as opposed to
   wanting all the existing code to work without a second thought) then let us
   know; you can quite easily influence which parts get done first.


OK, then, the reason I'm still using epoch instead of anymacs-19.xx is
that I embed emaxen windows inside of other windows.  I'm using about
half of the X functions epoch offers for figuring each window's XID
and handling X communications, such as ClientMessages (with Xatoms in
them) and changing properties on windows for data transfer in and out
of emacs.  I also use the display change hooks to implement scrollbars
(after-update-hook, window-select-hook, set-window-buffer-hook).  When
lemacs can do these things, I guess I'll leave epoch behind.

BTW, these are kludges I use to allow emacs windows inside of Tk/Tcl
widgets.  If you could properly integrate Tk into lemacs as an option
instead of Motif et cetera, that would be much superior.  TkEmacs did
that with emacs 18.59, allowing arbitrarily complex widgets and other
GUI stuff to be built from elisp scripts.

--
Brian L. Kahn   "In theory, there is no difference between theory and practice.
blk@mitre.org    In practice, of course, there is."

 

>>>>> "Jamie" == Jamie Zawinski <jwz@lucid.com> writes:

Jamie> Well I'm obviously biased, but the advantages that I see over
Jamie> the FSF version are:

While most of your posting is correct, or at least a matter of taste,
there are two factual errors I'd like to correct...

Jamie>  - Any key sequence you can generate on your keyboard can be
Jamie> bound to a command using a logical and consistent interface
Jamie> that does not rely on pretending you're really dealing with 7
Jamie> bit integers.

Neither does FSF Emacs 19.  Characters are represented by 24-bit
integers, and special keys by symbols.

The event interface for Lucid and FSF are functionally equivalent, the
difference is mostly a matter of taste.  The FSF interface is slightly
more Emacs 18 compatible, and more convenient for the remap package
described below.  Undoubtly, there exist applications where the Lucid
interface is more convenient.

Jamie>  - Input and display of Latin1 chars *just works*, without any
Jamie> contortions.  (By "just works" I mean things like Isearch as
Jamie> well.)

It also *just works* in FSF Emacs 19 (including things like Isearch).

With my unbundled `remap' package it also works with Latin2, PC, Mac,
EBCDIC and about all other 8 and 7 bit character sets.  You can even
specify different character sets for the keyboard, screen, and the
buffer.  Lucid lacks many of the primitives needed for doing this.

For internationalization, FSF Emacs is currently stronger, but see
also MULE.

In gnu.epoch.misc Per Abrahamsen <abraham@research.att.com> wrote:
> 
> Jamie>  - Any key sequence you can generate on your keyboard can be
> Jamie> bound to a command using a logical and consistent interface
> Jamie> that does not rely on pretending you're really dealing with 7
> Jamie> bit integers.
> 
> Neither does FSF Emacs 19.  Characters are represented by 24-bit
> integers, and special keys by symbols.

In FSF19, a key is either: a 7 bit element of a string (with the eighth bit
indicating meta, not a Latin1-non-ASCII character, or maybe it's the other way
around, or maybe it varies, I don't remember); a 24 bit (or possibly 26 bit,
depending on how emacs was compiled) element of a vector, encoding the
modifiers in some nonintuitive way; or a symbol, where the actual characters
of the symbol-name are parsed to determine what modifiers it has.

In Lucid Emacs, a key is a set of modifier names, and a keysym name.  Plain
and simple.  Unambiguous.  No nonintuitive truncation/loss of precision can
occur.  No obscure bugs involving .elc files becoming non-portable.

It's clear to me that users have more trouble making sense of the FSF way;
simply count up how many questions about keybindings you see on gnu.emacs.help
in a week (lots) versus how many you see on alt.lucid-emacs.help (none.)

As for the programmer's interface: in FSF19, an "event" is either an integer,
or a symbol, but usually an integer, making it easy for user code to fall
into the assumption that things are always integers.  In lemacs, input is
always in the form of events, which are never integers, thus preventing this
mistake.  I think this is the right tradeoff.  Using integers for everything
confuses the important distinction between file-characters and input events.

> The event interface for Lucid and FSF are functionally equivalent, the
> difference is mostly a matter of taste.

The APIs are essentially equivalent, but I think there's strong evidence that
the Lemacs user interface (meaning .emacs-file level) is less confusing.  I
also think that the Lemacs API is more robust in terms of preventing
programmer errors that would slip through the cracks in the FSF version.

It's fair to call this a "matter of taste," but I think it's more a matter
of "robustness of interface," which is where my tastes lie I suppose.

> Jamie>  - Input and display of Latin1 chars *just works*, without any
> Jamie> contortions.  (By "just works" I mean things like Isearch as
> Jamie> well.)
> 
> It also *just works* in FSF Emacs 19 (including things like Isearch).

I was under the impression that one could not isearch for keys that were
produced as a result of compose sequences entered using "C-x 6" or whatever
prefix it is that FSF19 uses for this.  I might be wrong, but I saw several
posts where people indicated that they were losing in this way.

And it doesn't "just work" out of the box in FSF19, you have to explicitly
tell it to use Latin1 characters, I presume because of the confusion between
the "meta" bit and the 8th bit.  Possibly this is a minor point (meaning
possibly all of the other internal problems this ambiguity leads to have been
kludged around) but possibly not.  In any event, lemacs has no need for this
distinction.

> With my unbundled `remap' package it also works with Latin2, PC, Mac,
> EBCDIC and about all other 8 and 7 bit character sets.  You can even
> specify different character sets for the keyboard, screen, and the
> buffer.  Lucid lacks many of the primitives needed for doing this.

Tell me what functionality you need, and why you think that representing
almost-but-not-quite everything with integers is important.

	-- Jamie