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

[David Kastrup]

Dan Nicolaescu <address@hidden> writes:

> Jason Rumney <address@hidden> writes:
>
>   > Dan Nicolaescu wrote:
>   > > Yes, intentionally as it is irrelevant here. Before your change people
>   > > were able to test the multi-tty functionality, after it they are
>   > > not. Nobody claimed the code was bug free, but it did do what was
>   > > advertised to do.
>   > >
>   > > This shows a total lack of respect for all the hard work Karoly's put
>   > > in for a few years.
>   > >   
>   > 
>   > Helping to fix bugs does not show a lack of respect.
>
> I agree, that might have been the intention, but that is not what I
>see happening here. This change strictly made the behavior
>worse. Given that for most people this is the first time they have a
>chance to play with multi-tty, this does not reflect well on that
>code.

Reality check: it did not already work here as advertised, partly
because the getenv function ignores its FRAME argument in stark
contrast to the documentation.  This is the first time multi-tty gets
accessible to _developers_, and you clamor for papering over obvious
bugs already by letting functions behave contrary to their design and
documentation.

Papering over bugs, if at all, should be reserved for the _end_ of a
release cycle.  And you want to _start_ with it.

But it would not paper over the bug that got me _started_ looking into
getenv in the first place, namely that emacsclient can't work unless
emacs was started from a tty with the same termcap/terminfo situation.
What do you thing the "multi" in "multi-tty" is supposed to stand for?

That way we'll never get to working code.

Again, I repeat my offer: if that's the consensus among multitty
developers, I'll be glad to revert the change and stop touching the
branch.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum