Re: [multi-tty] Emacs port status

[David Kastrup <dak@gnu.org>]

Jason Rumney <jasonr@gnu.org> writes:

> Thanks to some help from Dan Nicolaescu, I think we have reached a
> point with the Windows port where I would be comfortable merging
> into the trunk.

That was pleasantly fast.  Of the other ports, probably the MSDOS port
will provide the most puzzlers.  Carbon hopefully would be simpler.

> There is still much to do - none of the extra functionality is
> working, and -nw support is broken, but I don't think that is a
> showstopper for Windows users. Some more testing while it is still
> on the branch will be most welcome.
>
> Maintainers of other ports may find it useful to look at the
> changelogs, as the changes for other platforms will probably be
> similar.

Personally, I'd find it best if we merged once we have more or less
agreed on the model we want to use: having the trunk as a reference
for less invasive variants (where changes in callers can be reverted
to their old state) might be more convenient than searching the branch
line.  However, this is not cast in stone.

One thing that I personally am concerned about is that it might be
difficult to reach a consensus about what kind of environment model we
should be using and documenting.  There have not actually been many
people involved in the discussion, but it is clear that there are
quite different standpoints from the user experience and the system
architecture point of view.

Resolving them will require either a long test phase with both options
available and people being able to try what fits them best, or a
decision by a responsible maintainer.  Or both: a decision after a
sufficient number of people have tested the behaviors.

Personally, I would prefer the least invasive solution people can come
up with (I tried sketching one myself) for the start of a test phase.
And then one has to see if people actually complain about it when
using them, or if people can feel at home with it well enough.  We
should really aim for the simplest and most logical solution that
still offers tolerable behavior and works with most existing code
(probably in that order of priorities).

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum