Emacs 19
Richard P. Gabriel
come from Lucid. Its is GNU Emacs 19. I still can't say exactly when
public release is going to be, but we are about to start testing at a
number of sites.
Free software is a great thing - freedom of distribution and use, and
freedom from price. It's such a great thing that some companies
recognize the value of giving things away, as a mechanism of goodwill,
of ``paying back'' the community it serves, and as a mechanism to show
potential customers the quality and style of software you can expect
from those companies.
Four years ago we embarked on a development project one of whose
central portions would be Emacs, but an Emacs with enhanced
capabilities - active regions, properties of text, fonts, color,
menubars, pop-up menus, and true X integration. Free Software
Foundation at the time was beginning to work on Emacs 19. Lucid paid
the author of the then-current Emacs 19 prototype to help us get it
ready. Well, $50,000 poorer and 18 months older, we were no closer to our
goal than when we started.
So, I assigned 5 of our best developers to work on Emacs 19, and last
summer we released it to the world. It runs on a bunch of platforms,
it is actively maintained (it is the centerpiece of our user interface
for our commercial product), thousands of people use it, we are
working with volunteers around the world, and - the best part - we
operate just like FSF on it: it's free, source code and all, there's
an updated manual for it, and we incorporate all reasonable changes
just the way FSF does.
The difference is, we have Emacs 19, it is well-tested, and its users
love it. Another difference is, we have 35 developers and we don't
need handouts to keep maintaining Emacs - it's just good business.
The concept of free software doesn't belong to anyone. The dream of
those who value free software is that the idea will be so compelling
that others will pick up the standard and improve it, that others will
take more time, do more things, champion the cause so that the
community get more because fresh blood is applied to it.
We waited for years and years for Emacs 19. The idea of free software
is a good one, and if you cannot live up to its needs, you should let
go. Free software is an idea so good that you shouldn't smother it by
claiming you own it. Free Software Foundation doesn't own the concept
of free software, and it doesn't own the exclusive rights to work on
Emacs.
Wait for the private tests, wait for the beta tests, wait for general
release, wait, wait, wait. Or, FTP it from /pub/gnu/lucid on
labrea.stanford.edu today and use it this afternoon. Help us move on
from Emacs 19 to Emacs 20.
-rpg-
Richard Stallman
with getting Emacs 19 out the door soon with the features it had
then. I got about two weeks notice that he was leaving.
While you set him to work implementing new features that I had planned
for Emacs 20, I had to try to get Emacs 19 back on track. It took a
while for the new maintainer to come up to speed. The result: a long
delay. Emacs 19 would have come out two years ago if not for this.
Later you assigned programmers to work on another version of Emacs
without telling me about it. I found out months later by luck. Why
didn't you tell me? Why didn't you ask them to discuss the design
with me before they implemented it? Whatever the reason, you didn't,
which was not a very cooperative way of working.
Well, we have finally dealt with the problem caused two years ago, and
what happens? Now you are asking people to make up their minds that
GNU Emacs 19 is dead, quickly, before it has a chance to crack the
shell.
Overall your conduct leaves something to be desired.
I would be happy to see someone capable take over the work on Emacs
from the FSF. I might have been happy to see Lucid do so, if you had
approached it openly and with a good spirit.
Lucid can implement things. And some of them are good features. But
some of them are clunky. If you had asked the programmers to work
with me, I think it would be better. (People will soon be able to
compare the design of analogous features and form their own opinions.)
Above all, you've shown a bad spirit. I want Emacs to be in more
worthy hands than that. I think there are possibilities.
I have just about finished updating the Emacs Lisp manual. In the
next three weeks I'll update the user's manual.
Richard P. Gabriel
Lucid's involement with Emacs 19 and FSF. I still think we tried as
hard as any reasonable organization can to work with you and FSF. I am
still saddened and puzzled by your peculiar memory of it. I reproduced the
exchange below so people can see it (again) and judge for themselves our
relative behavior.
Our Emacs is used widely and I have yet to hear anything but
embarassingly high praise for it. We only want to help the community,
but I think you just couldn't let go enough to allow us to help. There
are things that I think need to be done to it to make it better, but
unfortunately you and I continue to duplicate effort. Everyone loves a
race, I suppose.
-rpg-
Date: Sat, 20 Jun 92 12:38:59 +0100
From: rms%lelu....@lucid.com
To: dans...@autodesk.com
Cc: ebu...@ebu.ericsson.se, ep...@cs.uiuc.edu, help-luc...@lucid.com
Subject: Epoch and EMACS merger
In-Reply-To: Daniel Smith's message of Fri, 19 Jun 1992 12:50:15 PDT <9206191950.AA05392@bermuda.YP.acad>
Reply-To: r...@gnu.ai.mit.edu
The long delay in releasing Emacs 19 is the FSF's fault. (In some
sense, therefore, mine.) While it's regrettable that there are
multiple versions, I can't blame people for filling the gap that the
FSF left. One of the goals of the copyleft is to allow people to do
this--so that one central maintainer's lapse does not hold back the
rest of the community.
However, the people who wrote the Lucid version didn't try to to make
the changes usable for us. They charged ahead without discussing the
design with me or with the main Emacs maintainer. They reimplemented
things we had already done. I asked them to do some work making parts
usable for us, but they said no.
The result is that not much of the code in Lucid's version will ever
appear in the FSF's version. Some of the features are worth having,
but need to be reimplemented. If you'd like this to happen sooner,
one way is to volunteer to do some of the work.
Emacs 19 already has most of the features of Epoch.
------------------------------
Date: Mon, 22 Jun 92 21:37:51 PDT
From: rpg%inf...@lucid.com (Richard P. Gabriel)
To: help-luc...@lucid.com, ep...@cs.uiuc.edu
Cc: r...@gnu.ai.mit.edu, dans...@autodesk.com, ebu...@ebu.ericsson.se
Subject: Epoch and EMACS merger
I read RMS's message with sadness. Over the past two years I have
tried very hard to figure out a way to work with FSF on Emacs, and for
a lot of that time I thought we were working together, but apparently
I failed. For those of you who wish to read about that effort, you can
read the postscript to this note, which outlines Lucid's involvement -
a sort-of history of the events.
We still want to work with FSF and have our contributions become part
of FSF Emacs, and we are eager to hear suggestions on how to proceed.
-rpg-
P.S. RMS's letter paints an unflattering and unfair picture of Lucid's
involvement with Emacs, and in particular on the motives and efforts
of our hackers.
The Free Software Foundation is a remarkable organization - for many
years I have supported it personally (and still do), and my company
supports it, its goals, and its products. This support is in terms of
time, effort, and dollars.
RMS says:
However, the people who wrote the Lucid version didn't try to to make
the changes usable for us. They charged ahead without discussing the
design with me or with the main Emacs maintainer. They reimplemented
things we had already done. I asked them to do some work making parts
usable for us, but they said no.
This is not how we at Lucid remember events, although it may be a difference
without a distinction. I'll recount the events as I recall them and let the
reader supply the characterization.
Lucid set a course 4 years ago to develop a C/C++ programming environment,
using Emacs as a key component. We needed a small number of specific
things:
* it had to run under X using multiple windows
* it had to support multiple fonts (at least a little)
* it had to support embedded glyphs (icons)
* it had to support attaching active regions to contiguous blocks of
characters (to support a hypertext-like facility)
* it had to support menubars
* it had to support readonly regions of text
My goals with respect to FSF were these:
* do anything (including paying money) to get our changes into the
official FSF sources
* not sacrifice quality or the schedule (which was lengthy, and therefore
apparently safe)
For the first two years we prototyped the functionality we needed in an
X-widget-based text editor and in Epoch.
By the Summer of 1990, Emacs 19 appeared to be right around the corner, so
we entered discussions with the person at FSF whom we were led to believe
was the official Emacs 19 coder - Joe Arceneaux. It appeared that our goals
and FSF's were in line, and so he proposed that we pay him a consulting fee
to speed up Emacs 19 development plus get our changes in. We agreed, wrote a
contract, and volunteered manpower to help.
The contract period started October 1990, was to last approximately 9
months. We were to pay him approximately $50k. He was paid on milestones,
on which he appeared to deliver. In addition, we provided him office space
and his own Sparcstation at Lucid. (At the conclusion of this period, it
appeared that Joe Arceneaux was no longer the official Emacs 19 coder.)
In the Spring of 1991 it became apparent that the effort was going badly -
Emacs 19 as a text editor was slow, and full of bugs. The only people at
Lucid who dared use it were Arceneaux and myself. Moreover, Emacs 19
performed hideously in the new areas outlined above. Its behavior was
especially bad with respect to active regions -- even worse than our
seat-of-the-pants prototype in Epoch.
Nevertheless, we persevered: We re-arranged our Emacs team and priorities
to work more closely with Arceneaux, and we were confident the arrangement
could work. To be safe, I put 4 of our best hackers on it with
Arceneaux. By Summer of last year we became aware that RMS had
hired/appointed Jim Blandy as the official Emacs 19 person.
At that time, one of our hackers went out to Cambridge to talk RMS about how
to proceed, and it appeared we reached a reasonable working arrangement.
But, as time went on we determined that the FSF code for Emacs 19 was too
unwieldy, bug-ridden, and convoluted to work with, so we started rewriting
parts of it.
In addition to not listening to any design ideas we had, RMS's policy was
to require us to provide source diffs and to explain every changed line.
Because our efforts towards release were mounting, and we were re-writing
massive amounts of the system, source diffs didn't make sense, but RMS and
Blandy were unwilling or unable to work at a higher level. I traveled to
Cambridge to work things out, and my team had numerous phone conversations
with RMS.
One area that was completely rewritten was the implementation of active
regions. Various attempts were made to discuss the design with RMS,
including a 2 hour telephone conversation from one of my hackers, but he
was completely unwilling to consider another point of view. At first, he
apparently didn't understand the differences between attaching active
regions to text and attaching fonts to text, and when he finally did, he
was so wedded to his design for putting fonts in the text that he wanted
us to implement BOTH his design for fonts and ours for other active region
support.
Our hacker wanted RMS to cooperate to the extent that we would first
implement our version to support all of these features, and see how well it
worked, but he wouldn't even agree to that. It is worth noting that with
the original FSF version, in spite of some rather elaborate tree-balancing
code and other hackery for precomputing display characteristics, Emacs
redisplay spent more than 40% of its time in the active regions code. In
our much simpler version it spends significantly less than 1% of the
redisplay time in the corresponding code, even for buffers with a few
thousand active regions. (This isn't to say that the original design
couldn't be made to work, but several man-months of effort had gone into
their original version, and it took less than 2 man-months to implement and
debug the code that we shipped with our version. Finally, our version is
approximately 1/2 the number of lines of the original, it is more general,
and it uses less memory.)
Early last Fall, after spending approximately $70k on Arceneaux, we let
his contract expire, but we did put a leased 38.4 kb digital line and an
X terminal in Arceneaux's apartment in San Francisco (35 miles away from
Lucid), so he could continue to work on Emacs 19 for FSF with Lucid
support.
When we learned last Summer that FSF had established an Emacs steering
committee, and no one from my organization was put on that, or even
informed of its existence, we came to the conclusion that the FSF had
no interest in working with us, and we stopped trying. The punch line
of RMS' statement is true -- we wouldn't do things they way he wanted.
But we didn't ``charge ahead'' without talking to FSF. While we did
reimplement some things that they had already done, the things we
reimplemented were completely broken. It's true that in the end our
work has been unusable by the FSF, but that seems to us to have more
to do with their willingness to use it than with anything else.
RMS concludes:
The result is that not much of the code in Lucid's version will ever
appear in the FSF's version. Some of the features are worth having,
but need to be reimplemented. If you'd like this to happen sooner,
one way is to volunteer to do some of the work.
I have trouble imagining how anyone could have worked with with them
on this. We may have failed in this attempt, but we have a history of
trying, and we have succeeded in other areas.
In addition to working on Emacs, and contributing to Cygnus initial
implementations of some new features for gdb, such as a malloc that
supports multiple heaps, code to save the internal gdb ``symbol
table'' state for a given executable file, and a various C++ debugging
features, (as well as paying $100K to have these features officially
incorporated into gdb), during the past year we dedicated
approximately 1 person-year, spread over 3 people, to producing a new
Emacs manual. In addition we have spent a lot of time trying to
figure out how to work amicably with FSF.
We have also supported FSF and RMS by selecting several FSF components
for our product, an endorsement of their quality and usefulness.
Since 1987 Lucid has regularly contributed code (and occasionally
money) to FSF. Lucid paid over $200k to support FSF products over the
last 2 years. We contributed over 8 hacker-years to improve FSF
products.
I personally am a member of LPF (not related to FSF, but related to
RMS). I travel about debating various people in RMS's name, and I
have actively supported RMS in various private ways. I couldn't
figure out how to work with FSF and RMS even though I had years to do
it, hundreds of thousands of dollars to spend, and 8 man-years to
volunteer. What would you have done differently?
We offer a free Emacs 19 to anyone who wants it, under exactly the
same conditions as the FSF, providing commercial support to our paying
customers (all improvements arising out of this support become part of
the free version as well, of course), as well as answering questions
and incorporating changes received from users on the net, and we will
continue to develop it. We will rewrite the redisplay code, and we
will very probably do work to internationalize Emacs. We also are
using scarce documentation resources on the Emacs manual (copyright
still held jointly with RMS). However, unlike the FSF, we will also
listen to ideas from other people. For one thing, if someone
implements an improved version of a feature, we aren't arrogant or
inflexible enough to refuse to consider using it. The hackers that
worked on our version are concerned about doing a good job for the
sake of Emacs, not just for the sake of our company or their egos.
By this time I've ceased expecting that we will work closely with FSF
on Emacs, but we would still like to do so. As far as we can tell,
the reason that FSF won't use any of our work is that they aren't
interested in working *with* us (rather they want us to work *for*
them, doing precisely what they tell us to do the way they say to do
it, and on their own schedule). Perhaps they assume that our designs
and implementations are substandard, but as far as I know they have
never really looked at what we have done.
------------------------------
Richard Stallman
to the delay in Emacs 19, because I was being polite.
(Yes, I really do that sometimes.) I took the blame on myself
for the sake of amity.
But now that you are using our mailing lists to actively urge people
not to work with us, I have the feeling that it is too late to seek
amity. What you tell the public does not match what you actually do.
Richard Stallman
but I think you just couldn't let go enough to allow us to help.
This is a handy cheap shot. It is always easy to make this
accusation, and no one can ever disprove it.
But I can point out that
(1) I gave the work on Emacs to other people within the FSF,
(2) I've given maintenance on other programs I wrote
to people outside the FSF, and
(3) I'm raising funds now to give away the maintenance of GCC
to someone outside the FSF.
(4) I politely kept quiet last year about your role in the Emacs 19 delay,
even when you were criticising me publicly,
in the hope of achieving cooperation with you.
I wouldn't have done these things if I were the sort of person whose
ego would never let go of a project. I hope I will find someone
suitable to hand over Emacs maintenance to. Someone competent,
cooperative and upright.
I don't think I've found someone yet. You would be capable enough if
you were sometimes willing to listen. But at every step of the way
you have given cooperation only lip service. It takes special gall to
present my earlier politeness as indication I am "misremembering" what
happened.
I believe in cooperating with people who approach me trying to
cooperate. At one point I hoped you were that person. But at this
point, your actions say no.
To the users:
I'm not going to ask you to stop cooperating with Lucid. Since Lucid
Emacs is free software, it is not wrong for you to cooperate with them
about it.
But I do appeal to you of GNU Emacs to continue working with the FSF
on GNU Emacs, and not to listen when Lucid asks you to stop.
Richard P. Gabriel
of us could stand to learn. I'll try to learn it if that's what you
think my problem is. Shall we try an experiment? I am ready and more
than eager to try to make this work one more time - I've got over a
million $ into Emacs already. Shall we cc our conversations on the design
of our cooperative efforts to this list?
Tell me and JWZ what it takes to start over.
-rpg-
Richard Stallman
than eager to try to make this work one more time - I've got over a
million $ into Emacs already.
My understanding is that it is technically very hard to merge the two
versions now.
Lucid Emacs is set up to use and require an X toolkit; our version
does not use one. I think it is too expensive to require a toolkit.
Especially since we have already got most of the features we want,
without a toolkit.
In principle, I like the idea of supporting both modes of
operation--with toolkit and without. But the programmers at Lucid
told me last summer that using a toolkit required far-reaching changes
in many parts of Emacs, including making C-g fail to interrupt a
running program (something I worked hard a couple of years ago to make
work right).
So it sounds impractical to support both modes--at least, unless
something is done to change the requirements of the toolkit.
I don't blame Lucid for this. If anyone made a mistake, it was those
who designed the X toolkits.
But here is an idea. You mainly support Suns. They have threads.
More and more other systems have threads.
Would it be possible to use a separate thread to do the synchronous
interaction with the toolkit, and make it mimic the usual kind of
asynchronous input interface Emacs expects? And hide that within a
toolkit interface file that fits into GNU Emacs 19 in a modular way?
This might also make C-g work right in the toolkit case.
Perhaps this will make it possible after all to support both toolkit
and non-toolkit modes of operation. Perhaps then our versions could
be merged.
Two other areas of difference are in the design of menus and of
events. Lucid Emacs has separate opaque data types for these. GNU
Emacs uses pre-existing Lisp objects for the same job: keymaps serve
as menus, and ordinary numbers, symbols and lists serve as input
events. It should not be very hard to write Lisp functions to imitate
the Lucid functions, using these data structures, and then support
both interfaces.
A final area of difference is in intervals. But if that is the
only discrepancy, I'm sure it won't be hard to deal with.
Jamie Zawinski
>
> Lucid Emacs is set up to use and require an X toolkit; our version
> does not use one. I think it is too expensive to require a toolkit.
> Especially since we have already got most of the features we want,
> without a toolkit.
There are features that you don't have, such as guaranteed correct
interaction with X resources and app-defaults files, and the ability to
build other widgets into the emacs process.
Also, using a toolkit improves portability, since whoever ported the toolkit
has done all of the hairy select() hacking for you already. (But if you
want to compile without support for X (which is different from running
without X) then this is not an issue, because you have to do this
system-dependent hacking anyway.)
I think the overhead of using Xt is not anything to be concerned about;
the speed cost associated with Xt is insignificant, and the increase in
executable size is both A: small, and nonexistent if you are using shared
libraries, and B: proven to be acceptable by the already widespread use of
this toolkit and toolkits derived from it.
> In principle, I like the idea of supporting both modes of
> operation--with toolkit and without. But the programmers at Lucid
> told me last summer that using a toolkit required far-reaching changes
> in many parts of Emacs, including making C-g fail to interrupt a
> running program (something I worked hard a couple of years ago to make
> work right).
The event loop was rewritten to support the Xt-based command loop, true; but
it was rewritten in what I believe is a much more retargetable way. It is
not dependent on Xt; it just happens that currently Xt is the only backend
supported. I'm sure it would be much easier to write a home-grown non-Xt
backend for the event-loop with lemacs than it would be to make the FSF v19
command loop work with Xt. (In fact, that's why I designed it this way.)
Perhaps I was unclear in a previous message, but you seem to be confusing an
implementation detail of the C-g handing with the user-visible behavior. I
spent a lot of time ensuring that the emacs command loop, including its
handling of C-g as an elisp-level interrupt, is identical in behavior to
emacs 18 from the user's point of view. We would certainly not break things
badly enough that C-g didn't work!
> I don't blame Lucid for this. If anyone made a mistake, it was those
> who designed the X toolkits.
Mistakes were made in the design of the X toolkits, to be sure. But I don't
think they have adversely affected Lucid Emacs (aside from the time I had to
spend to work around them.)
-- Jamie
Richard Stallman
toolkit. The people who use Lucid Emacs are part of that segment.
There is also a segment of people whose machines won't support that.
I think there are a large number of such sites with limited memory and
no shared libraries, now using GNU Emacs. I know of some myself. I
also know I have always had complaints about how large Emacs is, from
people whose machines are small and overloaded.
Lucid won't get many complaints from these people. (If you don't like
liver, you won't complain to the chef that the chopped liver has liver
in it.) But that doesn't mean they are few in number.
There is also a segment of users whose machines don't have X windows.
If all three segments are large, a program that appeals only to one of
them can get an enthusiastic reception. I think that's what Lucid has
found. But if the FSF follows suit, a large number of users will be
unhappy.
So I would like add the capability to use a toolkit, without giving up
the ability to work without one. I'd like to add this in a modular
way, for the sake of future maintenance.
My beliefs and opinions about Lucid's changes in input structure are
all based on what Lucid's staff told me last summer. I was told the
toolkit insisted on calling Emacs as a subroutine, and would not
deliver another event until Emacs returned to it. I recall noting out
that this would stop C-g from working, and that someone confirmed
this. I asked if the toolkit provided any way to peek ahead, and was
told no.
This information dissuaded me from the goal of merging the two
versions. Other Lucid programmers agreed that it was impossible to
support both modes of operation because the changes were too
pervasive.
Now I think you are saying it is possible, and that you have a clean
design to propose. I'm glad to hear it.
Can you write up a technical proposal for how to change the Emacs
command loop and/or input reading routines in preparation for
supporting toolkit, non-toolkit X, and no-X-at-all modes of operation?
Jamie Zawinski
>
> My beliefs and opinions about Lucid's changes in input structure are
> all based on what Lucid's staff told me last summer. I was told the
> toolkit insisted on calling Emacs as a subroutine, and would not
> deliver another event until Emacs returned to it. I recall noting out
> that this would stop C-g from working, and that someone confirmed
> this. I asked if the toolkit provided any way to peek ahead, and was
> told no.
Who told you this? If you think it was me, then we had a very serious
miscomunication, because none of this is true, and I have never believed
it to be true. And I'm the one who wrote basically all of the code in
question.
> Can you write up a technical proposal for how to change the Emacs
> command loop and/or input reading routines in preparation for
> supporting toolkit, non-toolkit X, and no-X-at-all modes of operation?
Even better, I can point you at a working implementation, liberally
commented. I find it upsetting that, despite all of the criticism you
heap upon us, it is clear that you have never even *run* Lucid Emacs.
Here is a description of what Lucid Emacs currently does at the lowest
level.
The basic notion is that there is an event_stream structure which
encapsulates all system-dependent input, in an analagous way to the v18
redisplay hooks. There is only one event_stream structure in use at a
time.
struct event_stream
{
int (*event_pending_p) (int);
void (*next_event_cb) (struct Lisp_Event *);
void (*handle_magic_event_cb) (struct Lisp_Event *);
int (*generate_wakeup_cb) (unsigned int, unsigned int,
Lisp_Object, Lisp_Object);
void (*disable_wakeup_cb) (int);
void (*select_tty_cb) (int);
void (*unselect_tty_cb) (int);
void (*select_process_cb) (struct Lisp_Process *);
void (*unselect_process_cb) (struct Lisp_Process *);
#ifdef SIGIO
void (*sigio_cb) ();
#endif
};
next_event_cb A function which fills in an emacs_event struture
with the next event available. If there is no event
available, then this should block.
event_pending_cb A function which says whether there are events to be
read. If called with an argument of 0, then this
should say whether calling the next_event_cb will
block. If called with an argument of 1, then this
should say whether there are user-generated events
pending (that is, keypresses or mouse-clicks.) This
is used for redisplay optimization, among other
things. On dumb ttys, these two results are the
same, but under a window system, they are not.
handle_magic_event_cb Emacs calls this with an event structure which
contains window-system dependent information that
emacs doesn't need to know about, but which must
happen in order. If the next_event_cb never returns
an event of type "magic", this will never be used.
generate_wakeup_cb Called with an int, the number of milliseconds after
which a wakeup event should be generated; the number
of milliseconds after which this timeout should *next*
occur (or 0 if it's a one-shot); a function to call
when the wakeup occurs; and some other object which
that function will be called with. This callback
should return an int id-number which uniquely
identifies this wakeup, and the "resignalled" wakeups.
If an implementation doesn't have millisecond
granularity, it should round up to the closest value
it can deal with.
disable_wakeup_cb Called with an int, the id number of a wakeup to
discard. This id number must have been returned by
the generate_wakeup_cb. If the given wakeup has
already expired, this should do nothing.
select_process_cb These callbacks tell the underlying implementation to
unselect_process_cb add or remove a file descriptor from the list of fds
which are polled for inferior-process input. When
input becomes available on the given tty, an event of
type "process" should be generated.
select_tty_cb These callbacks tell the underlying implementation
unselect_tty_cb to add or remove a file descriptor from the list of
fds which are polled for user-input. Each character
read from the fd generates a keypress event. This
is dumb-tty-type input; anything more complicated
than that needs to be handled differently.
(Handwave, handwave.)
Possibly we should implement these in terms of
select_process_cb.
sigio_cb A handler function for SIGIO interrupts, if on a
system which generates them. event_streams should
should be designed to not *require* SIGIO, but can
take advantage of it if it's present.
Emacs has its own event structures, which are distinct from the event
structures used by X or any other window system. It is the job of the
event_stream layer to translate to this format.
key_press_event
event_channel A token representing which keyboard generated it.
For this kind of event, this is a screen object.
(This is for eventual support of multiple displays.)
timestamp When it happened
key What keysym this is; an integer or a symbol.
If this is an integer, it will be in the printing
ASCII range: >32 and <127.
modifiers Bucky-bits on that key: control, meta, etc.
For most keys, Shift is not a bit; that is implicit
in the keyboard layout.
button_press_event
button_release_event
event_channel A token representing which mouse generated it.
For this kind of event, this is a screen object.
timestamp When it happened
button What button went down or up.
modifiers Bucky-bits on that button: shift, control, meta, etc.
x, y Where it was at the button-state-change (in pixels).
pointer_motion_event
event_channel A token representing which mouse generated it.
For this kind of event, this is a screen object.
timestamp When it happened
x, y Where it was after it moved (in pixels).
process_event
timestamp When it happened
process the emacs "process" object in question
timeout_event
timestamp Now (really, when the timeout was signalled)
function The elisp function to call for this timeout. It is
called with one argument, the event.
object Some lisp object associated with this timeout, to
make it easier to tell them apart.
eval_event
timestamp When it happened.
function An elisp function to call with this event object.
object Anything.
This kind of event is used internally; sometimes the
window system interface would like to inform emacs of
some user action (such as focusing on another screen)
but needs that to happen synchronously with the other
user input, like keypresses.
menu_event
timestamp When it happened.
function An elisp function to call with this event object.
object Anything.
This is similar to an eval_event, except that it is
generated by selections in the menubar. It is a
"command" event, like key and mouse presses (and
unlike mouse motion, process output, and enter and
leave window hooks.) In many ways, eval_events are
not the same as key- or menu-events.
magic_event
No user-serviceable parts within. This is for things
like KeymapNotify and ExposeRegion events and so on
that emacs itself doesn't care about, but which it
must do something with for proper interaction with
the window system.
Magic_events are handled somewhat asynchronously, just
like subprocess filters. However, occasionally a
magic_event needs to be handled synchronously; in that
case, the asynchronous handling of the magic_event will
push an eval_event back onto the queue, which will be
handled synchronously later. This is why eval_events
exist; I'm not entirely happy with this aspect of
this event model. The alternative is to make these
kinds of magic events be events that emacs knows about
at a higher level, but that lets window-system-specific
concepts leak higher than I am comfortable with.
In the Xt model, the callback functions work like this:
emacs_Xt_event_pending_p:
If `user_p' is false, then this function returns whether there are any
X, timeout, or fd events pending (that is, whether emacs_Xt_next_event()
would return immediately without blocking.)
if `user_p' is false, then this function returns whether there are any
*user generated* events available (that is, whether there are keyboard
or mouse-click events ready to be read.) This also implies that
emacs_Xt_next_event() would not block.
In a non-SIGIO world, this also checks whether the user has typed ^G,
since this is a convenient place to do so. We don't need to do this
in a SIGIO world, since all input causes an interrupt.
emacs_Xt_next_event:
This basically calls XtAppNextEvent() and converts it to the appropriate
kind of Lisp_Event. (It is a little complicated to work around a design
bug in the way XtAppNextEvent() deals with fd and timeout events.)
emacs_Xt_handle_magic_event:
This calls repaint_lines(), or the emacs functions that handle selection
transfers, etc, or XtDispatchEvent() if the event is not destined for
emacs.
emacs_Xt_select_process:
This calls XtAppAddInput() and does some bookkeeping.
emacs_Xt_generate_wakeup:
This calls XtAppAddTimeOut() and does some bookkeeping.
emacs_Xt_event_sigio_handler:
This scans the current X event queue for KeyPress events that are C-g
(really, that are equivalent to `interrupt_char') and calls
interrupt_signal() if appropriate. Since this may be called from a
signal handler, it obeys `x_input_blocked'.
emacs_Xt_select_tty:
This doesn't do anything right now, but will eventually be the function
that causes emacs to start interpreting input on an arbitrary fd as
user input coming from an ASCII channel. It will do this using
XtAppAddInput, which works even if emacs is not connected to an X server.
If compiled with Xt support, but not connected to an X server, the above
functions (once the select_tty routines are written) would be used.
If compiled without any X support, then the event_stream structure would be
populated with routines which do exactly what the analagous code in v18 does.
I expect this would be a fairly mechanical re-arrangement of the v18 code.
If compiled with support for two different window systems (assuming that at
some point in the future there is another window system besides X to which
emacs is given direct access) then at startup time, the event_stream would be
populated with the appropriate set of callback functions.
If compiled with X but without Xt, then there are two options: the first is
to write another set of event_stream functions. The other option, which is
probably easier, is just to write a small simulation of Xt, which does no
more than what emacs needs. This would probably be easier; you just need to
encapsulate the calls to select() and XNextEvent() behind functions with the
same interface as the few Xt routines that the emacs_Xt callbacks use.
============================================================================
That explains how the lowest level of interactions with the window system
works. At the next level up, the emacs event loop has been rewritten in
terms of event objects instead of ASCII characters. An event is a new
data type that contains several pieces of information. There are several
kinds of event, and corresponding accessor and utility functions. We
tried to abstract them so that they would apply equally well to a number
of window systems.
Events are reused efficiently; the event loop does no consing.
key_press_event
event_channel A token representing which keyboard generated it.
For this kind of event, this is a screen object.
(This is for eventual support of multiple displays.)
timestamp When it happened
key What keysym this is; an integer or a symbol.
If this is an integer, it will be in the printing
ASCII range: >32 and <127.
modifiers Bucky-bits on that key: control, meta, etc.
For most keys, Shift is not a bit; that is implicit
in the keyboard layout.
button_press_event
button_release_event
event_channel A token representing which mouse generated it.
For this kind of event, this is a screen object.
timestamp When it happened
button What button went down or up.
modifiers Bucky-bits on that button: shift, control, meta, etc.
x, y Where it was at the button-state-change (in pixels).
pointer_motion_event
event_channel A token representing which mouse generated it.
For this kind of event, this is a screen object.
timestamp When it happened
x, y Where it was after it moved (in pixels).
process_event
timestamp When it happened
process the emacs "process" object in question
timeout_event
timestamp Now (really, when the timeout was signalled)
function The elisp function to call for this timeout. It is
called with one argument, the event.
object Some lisp object associated with this timeout, to
make it easier to tell them apart.
eval_event
timestamp When it happened.
function An elisp function to call with this event object.
object Anything.
This kind of event is used internally; sometimes the
window system interface would like to inform Emacs of
some user action (such as focusing on another screen)
but needs that to happen synchronously with the other
user input, like keypresses.
menu_event
timestamp When it happened.
function An elisp function to call with this event object.
object Anything.
This is similar to an eval_event, except that it is
generated by selections in the menubar. It is a
"command" event, like key and mouse presses (and
unlike mouse motion, process output, and enter and
leave window hooks.) In many ways, eval_events are
not the same as key- or menu-events.
magic_event
No user-serviceable parts within. This is for things
like KeymapNotify and ExposeRegion events and so on
that Emacs itself doesn't care about, but which it
must do something with for proper interaction with
the window system.
Magic_events are handled somewhat asynchronously, just
like subprocess filters. However, occasionally a
magic_event needs to be handled synchronously; in that
case, the asynchronous handling of the magic_event will
push an eval_event back onto the queue, which will be
handled synchronously later. This is why eval_events
exist.
The function `next-event' blocks and returns one of the above-described
event objects. The function `dispatch-event' takes an event and processes
it in the appropriate way.
For a process-event, dispatch-event calls the process's handler; for a
mouse-motion event, the mouse-motion-handler hook is called, and so on.
For magic-events, dispatch-event does window-system-dependent things,
including calling some non-window-system-dependent hooks: map-screen-hook,
unmap-screen-hook, mouse-enter-screen-hook, and mouse-leave-screen-hook.
The function `next-command-event' calls `next-event' until it gets a key
or button from the user (that is, not a process, motion, timeout, or
magic event). If it gets an event that is not a key or button, it calls
`dispatch-event' on it immediately and reads another one. The
next-command-event function could be implemented in elisp, though it isn't.
read-char calls next-command-event; if it doesn't get an event that can be
converted to an ASCII character, it signals an error. Otherwise it returns
an integer.
The variable `last-command-char' always contains an integer, or nil (if the
last read event has no ASCII equivalent, as when it is a mouse-click or a
non-ASCII character chord.)
The new variable `last-command-event' holds an event object, that could be
a non-ASCII character, a button click, a menu selection, etc.
The variable `unread-command-char' no longer exists, and has been replaced
by `unread-command-event'. With the new event model, it is incorrect for
code to do (setq unread-command-char (read-char)), because all user-input
can't be represented as ASCII characters. This is an incompatible change.
Code which sets `unread-command-char' must be updated to use the
combination of `next-command-event' and `unread-command-event' instead.
The functions `this-command-keys' and `recent-keys' return a vector of
event objects, instead of a string of ASCII characters. This also is an
incompatible change.
Almost nothing happens at interrupt level; the SIGIO handler only looks at
the X event queue for KeyPress events which map to ^G, and sets `quit-flag'
when appropriate. All redisplay happens in the main thread of the
process.
It would be possible to make repaint_lines() be called from the SIGIO
handler when appropriate, but I don't think it is a good idea, or
especially worthwhile.
We envision the dumb-tty handler functions doing function-key handling at
the lowest level. So the terminal-specific code would set up some data
structure that would cause the key sequences that some ttys generate for
function keys to be converted to 'f1 and so on before next-event saw them.
This will allow the construct like (global-set-key 'f1 'my-function) to
work regardless of what terminal or window system you happen to be using.
-- Jamie
Richard Stallman
> all based on what Lucid's staff told me last summer. I was told the
> toolkit insisted on calling Emacs as a subroutine, and would not
> deliver another event until Emacs returned to it. I recall noting out
> that this would stop C-g from working, and that someone confirmed
> this. I asked if the toolkit provided any way to peek ahead, and was
> told no.
Who told you this?
I don't know which person at Lucid told me this. But that doesn't
seem important. What matters is that it isn't so. I'm glad, because
it was discouraging news at the time.
The event_stream mechanism sounds good. Could you send me the code
for that part of Lucid Emacs? I think we can install it, if you will
do the job of separating it out from the mass of the rest. (This is
something you can do much more easily than I.) I doubt it can
be installed verbatim, since we've probably made changes in the
surrounding context, but at least it sounds like a job worth doing.
Where else are changes needed to work with your toolkit-use code?
Richard Stallman
> Where else are changes needed to work with your toolkit-use code?
It's hard to say; our changes have been pervasive. As you said, a merge
will be a very large task.
It's almost impossible to merge one program with another as a unit,
when there is a lot of difference. By far the easiest way is to find
cohesive "unit changes" in one program--various parts that were
changed together and need each other to work, but are separate from
other changes--and think about them one at a time.
The merging in of the changes is most efficiently done by us; the
extraction is most efficiently done by you.
Please help us merge by doing this.
Jamie Zawinski
>
> The event_stream mechanism sounds good. Could you send me the code
> for that part of Lucid Emacs? I think we can install it, if you will
> do the job of separating it out from the mass of the rest. (This is
> something you can do much more easily than I.) I doubt it can
> be installed verbatim, since we've probably made changes in the
> surrounding context, but at least it sounds like a job worth doing.
I'll send you the files, but I doubt there is much surrounding context
left at all.
> Where else are changes needed to work with your toolkit-use code?
It's hard to say; our changes have been pervasive. As you said, a merge
will be a very large task.
-- Jamie
Per Abrahamsen
Sorry to interrupt the peace conference...
>>>>> On 26 Feb 93 01:30:16 GMT, j...@lucid.com (Jamie Zawinski) said:
Jamie> The event loop was rewritten to support the Xt-based command
Jamie> loop, true; but it was rewritten in what I believe is a much
Jamie> more retargetable way. It is not dependent on Xt; it just
Jamie> happens that currently Xt is the only backend supported. I'm
Jamie> sure it would be much easier to write a home-grown non-Xt
Jamie> backend for the event-loop with lemacs than it would be to make
Jamie> the FSF v19 command loop work with Xt. (In fact, that's why I
Jamie> designed it this way.)
Would you think it was a good idea to write a XView (really Notifier)
backend? It would make it possible to have a free OPEN LOOK compliant
GNU Emacs, something that would be much appreciated by two important
communities: Solaris and Linux users.
To put it differently: IF someone contributed a clean optional XView
backend, would you then consider integrating it in a future version of
GNU Emacs?
Richard Stallman
backend, would you then consider integrating it in a future version of
GNU Emacs?
Yes. Whether to install it would depend on things like
how clean it is, and how much continuing work it would need.
Jamie Zawinski
>
> Would you think it was a good idea to write a XView (really Notifier)
> backend? It would make it possible to have a free OPEN LOOK compliant
> GNU Emacs, something that would be much appreciated by two important
> communities: Solaris and Linux users.
If by Open Look you don't mean something radically different from what
OpenWindows means, then there's a much easier way to go about this than
by adding a new event_stream: OLIT gives you the OpenLook-and-feel with
an Xt-based interface, so all that needs to happen is that the OLIT code
in lwlib (the Lucid Widget Library) be made to work (it's almost done.)
But maybe there's a problem with this approach I'm missing; I know next
to nothing about Open[A-Z][a-z]*.
> To put it differently: IF someone contributed a clean optional XView
> backend, would you then consider integrating it in a future version of
> GNU Emacs?
I would welcome it.
-- Jamie
abr...@research.att.com
>>>>> On Fri, 26 Feb 93 15:07:50 -0500, r...@gnu.ai.mit.edu (Richard
>>>>> Stallman) said:
abraham> To put it differently: IF someone contributed a clean optional XView
abraham> backend, would you then consider integrating it in a future version of
abraham> GNU Emacs?
rms> Yes. Whether to install it would depend on things like
rms> how clean it is, and how much continuing work it would need.
If GNU Emacs will provide a clean separation between backends, the
maintenance required for the Notifier backend would be at the level
required by the Xt backend.
Supporting a XView GUI (menus, dialog boxes) should be as much work as
supporting a widget based GUI, again given a clean generic interface
to the GUI front end.
I guess there is no reason to start thinking about integrating XView
in GNU Emacs before those interfaces have been defined.
Ethan Bradford
backwards, eliminating support for very many systems and modes of
operation. I have not considered trying Lucid Emacs because I often
dial in from home (on a 1200 baud line from a machine without X), so I
need a non-X version. Epoch handles simultaneous X and ASCII
interfaces quite well.
Richard Stallman
in GNU Emacs before those interfaces have been defined.
I think we will adopt the event-stream data structure and conventions
that Lucid uses, for communication with toolkits of any sort.
abr...@research.att.com
>>>>> r...@gnu.ai.mit.edu (Richard Stallman) writes:
rms> I think we will adopt the event-stream data structure and conventions
rms> that Lucid uses, for communication with toolkits of any sort.
That should make it possible to prototype the functionality with Lucid
Emacs.
Would the backend be an Emacs 19, Emacs 19.xx or Emacs 20 kind of
thing?
How about generic GUI support (menus, dialog boxes)?
Per Abrahamsen
In gnu.emacs.help Per Abrahamsen <abr...@research.att.com> wrote:
Per> Would you think it was a good idea to write a XView (really Notifier)
Per> backend? It would make it possible to have a free OPEN LOOK compliant
Per> GNU Emacs, something that would be much appreciated by two important
Per> communities: Solaris and Linux users.
>>>>> On Fri, 26 Feb 93 20:18:21 GMT, Jamie Zawinski <j...@lucid.com> said:
Jamie> If by Open Look you don't mean something radically different from what
Jamie> OpenWindows means, then there's a much easier way to go about this than
Jamie> by adding a new event_stream: OLIT gives you the OpenLook-and-feel with
Jamie> an Xt-based interface, so all that needs to happen is that the OLIT code
Jamie> in lwlib (the Lucid Widget Library) be made to work (it's almost done.)
OPEN LOOK is a specification of a user interface. It is completely
implementation independent, and described in two books, one for
library writers and one application programmers. Anyone writing an
application with a GUI (such as Emacs 19) should read the second book,
it is very well written and you learn a lot about GUI design that can
be used independent of what toolkit you have.
OLIT is a specification of a programming interface (API). It is
possible to write OPEN LOOK programs with OLIT, but using OLIT is no
guarantee that your program will be OPEN LOOK.
XView is an alternative interface, the main technical difference being
that OLIT is build on top of X Intrinsics, while XView is not.
OpenWindows is a collection of programs and libraries, all of which
OPEN LOOK specification, except for bugs. One of the libraries also
implements the OLIT API, another the XView API.
Jamie> But maybe there's a problem with this approach I'm missing; I know next
Jamie> to nothing about Open[A-Z][a-z]*.
There are no free implementation of the OLIT API. Thus, it would not
be usable on a PC running Linux or a SPARC running Hurd, or in fact
anything but Solaris and some (other) SVR4 implementations.
It would be nice if e.g. Lucid would pay one of their programmers to
read the OPEN LOOK specification and make a compliant Emacs
implementation using OLIT. However, it would be something you would
do purely for business reasons, it would never be free software.
Per> To put it differently: IF someone contributed a clean optional XView
Per> backend, would you then consider integrating it in a future version of
Per> GNU Emacs?
Jamie> I would welcome it.
Glad to hear that :-) ... and sorry for the lecture.
Stephen Anderson
people is very heartening.
>>>>> On 26 Feb 93 03:45:50 GMT, r...@gnu.ai.mit.edu (Richard Stallman) said:
rms> There is also a segment of people whose machines won't support
rms> that. I think there are a large number of such sites with
rms> limited memory and no shared libraries, now using GNU Emacs. I
rms> know of some myself. I also know I have always had complaints
rms> about how large Emacs is, from people whose machines are small
rms> and overloaded.
[...]
rms> There is also a segment of users whose machines don't have X
rms> windows.
Does this imply that FSF's emacs-19 might support other windowing
systems? In particular, I'm interested in the possibility of an
emacs-19 that uses NeXTstep windowing natively. I've done a small
amount to help get lemacs to work on a NeXT, but given the real
problems of getting X to run smoothly on top of NeXTstep, there's no
way to make the current heavily-X-dependent version work well for NeXT
users. Of course, some may say that (with the recent demise of neXT as
a hardware company) that's a vanishingly small segment of the
community anyway, but if NeXTstep/Intel (and other proposed ports)
should take off, it might not be so small after all.
--Steve Anderson
Nick Kline
^Does this imply that FSF's emacs-19 might support other windowing
^systems? In particular, I'm interested in the possibility of an
^emacs-19 that uses NeXTstep windowing natively. I've done a small
^amount to help get lemacs to work on a NeXT, but given the real
^problems of getting X to run smoothly on top of NeXTstep, there's no
^way to make the current heavily-X-dependent version work well for NeXT
^users. Of course, some may say that (with the recent demise of neXT as
^a hardware company) that's a vanishingly small segment of the
^community anyway, but if NeXTstep/Intel (and other proposed ports)
^should take off, it might not be so small after all.
^
^--Steve Anderson
I was thinking the same thing. Specifically, if I had a description
of the types of events and what they meant to give to this "event
stream", then we could write a header function for the next which
would convert next events to the form expect by emacs.
And we could also write wrapper functions for the next which
implemented whatever X calls emacs was making.
However, I wonder how gross and low level these calls are. If they are things
like moveXY(x,y); drawString(font, "string"); we could do those easily.
But if they are like things like oh, I don't know:
set opacity of buffer to xyz
if(2 bit deep buffer) do this
else if 4 bit deep do that
and so forth then it would be hard. Of course, I haven't even looked
at the X code in emacs.
-nick
Jamie Zawinski
other window systems, and to keep the X-specific code well isolated. There
are currently a lot of Xisms in lemacs, but they're almost entirely related
to redisplay, which we haven't done much work on yet.
I've always thought that a native NeXTstep port would be great, because I
think NeXTstep is a nice window system. Certainly the design won't have
been truly vindicated until it is used with a window system other than X.
But I suspect that a Windows NT port will be more useful...
> And we could also write wrapper functions for the next which
> implemented whatever X calls emacs was making.
I know of someone who has done this (simulate Xt) for another window system.
I think it's a pretty poor way to go about it, though it might be easier in
the short term.
> However, I wonder how gross and low level these calls are. If they are
> things like moveXY(x,y); drawString(font, "string"); we could do those
> easily.
Lemacs doesn't exercise Xlib very heavily (there are probably some
abstractions missing, like getting the pixel-size of a string in a particular
font, but that's easy to fix), and all of the Xt stuff is isolated under the
event-stream callbacks.
-- Jamie
Richard Mlynarik
when there is a lot of difference. By far the easiest way is to find
cohesive "unit changes" in one program--various parts that were
changed together and need each other to work, but are separate from
other changes--and think about them one at a time.
The merging in of the changes is most efficiently done by us; the
extraction is most efficiently done by you.
Please help us merge by doing this.
I've largely merged FSF Emacs V19 into Lucid Emacs (except for
redisplay code, keyboard.c, and the neverending changing extra
arguments to functions in window.c)
I am totally uninterested in doing the merge the other way, if for no
other reason than that I believe the people at Lucid working on Emacs
are far more competent and more far tasteful programmers, and aren't
wasting large amounts of FSF resources which would much, much better
have been spent elsewhere.
Working on programs with people like Jamie Zawinski (or many other
excellent hacker types) is also vastly easier than trying to cooperate
with RMS on anything.
Neil Jerram
There is also a segment of users whose machines don't have X windows.
...
...
Can you write up a technical proposal for how to change the Emacs
command loop and/or input reading routines in preparation for
supporting toolkit, non-toolkit X, and no-X-at-all modes of operation?
Why is it necessary to support all three possibilities in a single
binary. The code running at any one time could be made smaller and
more bug-free by having three separate executables which are
compatible at the Lisp level. Otherwise it seems that the numerous
possibilies of window systems will be help back by ANSI terminals.
Neil.
Mike Tiller
Well, I for one don't want to have one executable for X and one without
because I use both and that means I have to have two Emacs executables
on my system. I'm all for being able to leave out extra stuff if you
don't want it though.
Michael Tiller
University of Illinois
Benjamin R. Liblit
> Why is it necessary to support all three possibilities in a single
> binary. The code running at any one time could be made smaller and
> more bug-free by having three separate executables
What about having one executable that holds all of the common code,
and having support libraries for various display systems (XWindows,
text terminals, et al). The libraries could be dynamically loaded by
Emacs when it starts up and figures out what it's running on.
Advantages would be small executable size, no duplication of common
code, and easy extensibility. Disadvantages include slower startup,
and the fact that dynamic loading like this seems kind of, well,
funky. How OS-specific would this sort of thing be? If it would
close Emacs out from certain OS's, then it is probably a bad idea.
Thoughts on the matter?
--
Ben Liblit ----- "Fais que tes reves soient plus longs que la nuit."
lib...@cs.psu.edu -- brl...@psuvm.psu.edu -- brl...@psuvm.bitnet
Daniel Louis Smith
I going to toss in a little historical context below for those
who weren't reading this stuff last June...
In <930225212...@inferno.lucid.com> r...@lucid.com (Richard P. Gabriel) writes:
> I went back and found the mail exchange that you and I had about
> Lucid's involement with Emacs 19 and FSF. I still think we tried as
....
> Date: Sat, 20 Jun 92 12:38:59 +0100
> From: rms%lelu....@lucid.com
> To: dans...@autodesk.com
> Cc: ebu...@ebu.ericsson.se, ep...@cs.uiuc.edu, help-luc...@lucid.com
> Subject: Epoch and EMACS merger
> In-Reply-To: Daniel Smith's message of Fri, 19 Jun 1992 12:50:15 PDT <9206191950.AA05392@bermuda.YP.acad>
> Reply-To: r...@gnu.ai.mit.edu
> The long delay in releasing Emacs 19 is the FSF's fault. (In some
> sense, therefore, mine.) While it's regrettable that there are
> multiple versions, I can't blame people for filling the gap that the
> FSF left. One of the goals of the copyleft is to allow people to do
> this--so that one central maintainer's lapse does not hold back the
> rest of the community.
[etc.]
ok,
* dans...@autodesk.com is now d...@autodesk.com... too many
Dan Smith's in the world, but that's not really why I'm writing :-)
* I don't want anyone to get the impression that I was ragging
on rms, prompting his response (why I'm including some context
below). Here's what was going through my head last June, and
why I am glad to see the flurry of postings from the reps
of the Lucid, Epoch, and Emacs 19 camps: I had written to the
Epoch and Lucid mailing lists, following up on a letter asking
if the two were ever going to be merged. I'll post that here
as 1) a historical reference, and 2) re-expressing the hope that
we'll see a One True X Emacs at some point that merges the best
ideas from the different camps. My perspective is that of
"interested user and observer".
* Some ideas are being tossed around about Xt toolkits, XView,
and so on. I'll toss in "would using Tk/Tcl make sense?"
>>From dansmith Fri Jun 19 12:50:15 1992
>>Date: Fri, 19 Jun 1992 12:50:15 PDT
>>In-Reply-To: Bertil Askelid's 34-line message on Jun 19, 12:57am
>>Return-Path: autodesk!dansmith
>>X-Organization: Autodesk, Sausalito, CA
>>X-Mailer: Mail User's Shell (7.2.2 4/12/91)
>>To: ebu...@ebu.ericsson.se (Bertil Askelid),
ebu.ericsson.se!cs.uiuc.edu!epoch
>>Subject: Re: Epoch and EMACS merger
>>Cc: r...@ai.mit.edu, help-luc...@lucid.com
>>Status: OR
> > > Bertil Askelid wrote about "Re: Epoch and EMACS merger":
> In article <1992Jun18.2...@mintaka.lcs.mit.edu>, chicks@hal (Christopher H
icks) writes:
> <> I am curious as to what people think of the likelyhood of EMACS and Epoch
> <> merging into a single release.
>
> Isn't that what's called Emacs 19?
> --
[from June of '92...]
Further, it would be nice if any new Lucid-emacs features
get rolled in. It's getting confusing with Emacs 18.X, Epoch, Emacs 19,
and Lucid Emacs based on 19 all floating around at the same time.
For instance, I make frequent use of ^Z2 to dup a screen in Epoch..it's
something else in lucid emacs, and I haven't used Emacs 19 [1] but I'm
wondering if it's yet another thing.
[1] I gather 19 really isn't widely available yet.
Anyways, I think competition is a good thing and all, but
I'm also hoping it doesn't start getting out of hand. Are we going
to have three different versions of Emacs under the GNU license?
>From my perspective as a relatively new user of Emacs (about 1 year
and 9 years of Vi before that), I can keep the differences straight
in my mind, and there's ways of binding keys so that everything
looks the same, etc. However, if I'm explaining something about Emacs
versions to someone who's new to all of this, I can see contortions on
their face, etc :-) It's starting to look like the history of
some rock bands (like what's happened over the years to the band "Yes").
Would it be worthwhile for people to work towards a common
GNU Emacs goal?
[the followup at the time seemed to be "yep"]
What does Richard Stallman think of all of this?
[see above]
I'm just tossing this out there. If there's going to be
2 or three GNUish Emacii, fine, I can keep that straight. I just
personally hope there isn't any more splintering. Perhaps there
should be an Emacs Summit Meeting? Anyways, this is all from a user's
perspective who is wondering what is going on, but who doesn't
necessarily know all of the history behind it...so keep any flames
informative rather than outright hostile :-)
Daniel
--
d...@autodesk.com dans...@well.sf.ca.us
Daniel L Smith, Autodesk, Sausalito, California, (415) 332-2344 x 2580
formerly dans...@autodesk.com, changed my login recently
meta everything!
As an avid Epoch and NeXTstep user, I'd be interested in hearing more about
the possibility of generalizing the windowing interface of Emacs 19.
I'm not familiar with Lucid Emacs, so I don't have a feel for whether
this will be necessary, practical, or even desirable.
From rms/lucid discussion, it wasn't entirely clear whether or not supporting
both the vanilla X & Xt toolkit designs would require enough
restructuring to make another layer of indirection worthwhile.
I'd like to work on native NeXTstep support (if such an interface could
be implemented).
marcus daniels
------------------------------------------------------------------------------
- mar...@eecs.ee.pdx.edu / ....!uunet!tektronix!psueea!eecs!marcus
- "The power of accurate observation is called cynicism by those who
don't have it"
Richard Stallman
possible for GNU Emacs to support Xt in the future as an optional
feature. The first step towards this will be supporting a generic
interface for reading input events. GNU Emacs 19 already has a
generic event structure, much like the Lucid one, so the main job is
supporting general hooks for interface to the program that does the
reading.
The second step might be to support a new kind of frame that
interfaces via Xt instead of via Xlib, and perhaps to create a set of
clean hooks for that interfacing.