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

[David Kastrup <dak@gnu.org>]

Dan Nicolaescu <dann@ics.uci.edu> writes:

> David Kastrup <dak@gnu.org> writes:

>   > So reverting the change is not the right solution.  Personally,
>   > I think the arguments of getenv and setenv are completely messed
>   > up.

[You deleted the whole discussion and proposal for making a more
stable solution]

> It is at this point. You changed the code from working into
> non-working,

Wrong.  I changed code from _not_ working as advertised to _working_
as advertised.  Which means that a bug in a _caller_ now gets exposed.
You think that the right solution for the problem is hiding the bug in
the caller again, making the function do something different from what
the documentation claims it does.

> and it's already stopping other people from testing it. There was
> already a but report about this.
>
> You can improve it later if you want it, but now it does not work,
> and that reflects badly on the all the effort that was put into
> multi-tty.

I don't think that papering over bugs is what is required now.  If the
design does not hold up to the functions actually doing what the
documentation claims they do, it is broken.

Randomly making functions do something different from their
documentation until the stuff happens not to break immediately in
obvious ways is _not_ the right solution.

The right solution is to find the caller that passes a non-nil value
for FRAME into getenv with the wrong expectations, and _fix_ the
_caller_ rather than _break_ getenv's intended behavior and _ignore_
its FRAME parameter in order to hide the bug.

Either that, or decide that the whole idea of having getenv/setenv
with a FRAME parameter is broken.

I'd lean towards the latter.  But in either case, we need to be
consistent about it and follow through in both documentation and
implementation.

If the design is unsound, we need to rip it out completely, not just
sabotage it at the points where the problems show.

I'll try to see whether I can find the problematic caller.  But I
certainly hope that this "paper over it and hope nobody notices it"
stance does not pervade multi-tty, and that the _bug_ which I fixed
was not intentional but an oversight.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum