emacs-devel
[Top][All Lists]
Advanced

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

Re: Multi-tty design (Re: Reordering etc/NEWS)


From: David Kastrup
Subject: Re: Multi-tty design (Re: Reordering etc/NEWS)
Date: Fri, 18 May 2007 20:18:25 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1.50 (gnu/linux)

Karoly Lorentey <address@hidden> writes:

> You did not react to my observation on how all existing code that
> looks at `window-system' during load time breaks in multi-terminal
> sessions.  `window-system' is frame-local on the multi-tty branch
> and there is *really* a lot of code that relies on it having a
> global binding.  People whose .emacs mentions window-system are
> likely affected as well.  Again, single-terminal sessions continue
> to work fine, but in multi-terminal sessions, these packages break
> with various levels of spectacularity.
>
> I don't think we should even attempt to implement convoluted
> heuristics to have these packages still somehow work fine in
> multi-terminal sessions.  Would you agree?

Yes.  I consider it acceptable if everything relying on a single
terminal will break under multiple terminals.  There is no
alternative.

I consider it a _temporary_ advantage for the trunk merge if code
concerned with terminals will work as before in the single-tty case,
and only break in the multi-tty case: that gives people a single-tty
Emacs to work with while we figure out how to fix the breakage in the
multi-tty case.

What I don't consider acceptable if a considerable amount of stuff
working with environments that is _not_ related to multiple or even
single terminals will break.

I want to see the breakage restricted to those things that actually
have anything to do with terminals and ttys.  Even if we aim for a
long-term goal of having people do things in a particular better way
in future, this needs several Emacs versions and deprecated functions
and variables to shake out for good.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum




reply via email to

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