emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: vms for emacs


From: David Kastrup
Subject: Re: vms for emacs
Date: Mon, 21 May 2007 09:21:34 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/23.0.51 (gnu/linux)

Thien-Thi Nguyen <address@hidden> writes:

> () Jason Rumney <address@hidden>
> () Sun, 20 May 2007 21:38:01 +0100
>
>    Did we drop vms support for Emacs 22, or did someone come forward to
>    support it?
>
> there was no official support for Emacs 21, and that situation has
> not changed since then.  thus "drop" is not entirely correct
> although the result is the same from user point of view.

So we basically have the situation where basically working code for
all platforms we want to see supported exists.

For merging, I think we would want to have the code in a state where
people have a clue about how to work on it in order to iron out
problems they are having.  So we need some sort of design description
fit for inclusion into the Elisp manual.

We can partly come up with it by diffing current branch and trunk, but
if Károly could give us a head start by writing out the principles,
APIs and details, this would certainly help.

In unitty Emacs, terminals and terminal-locality are very much hidden
away: you have to actually switch terminals (using select-frame?) in
order to access local variables from other terminals and similar.

Multitty Emacs makes those entities all accessible.  A description of
all the details of the API would certainly be desirable.  If we have a
good overview over who uses what when, it might be possible to make
some of the stuff more automatic and thus provide less user-visible
complexity.  It might also be infeasible to hide away any of the
existing accessors.

Having a good overview over the mechanisms will help deciding this in
the one or other way and will at the very least (even if we still
change things) make a good start for the final Elisp manual
documentation.  Some of the articles Károly posted could already make
material suitable for the Emacs user manual.

-- 
David Kastrup




reply via email to

[Prev in Thread] Current Thread [Next in Thread]