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

[David Kastrup]

Dan Nicolaescu <address@hidden> writes:

> David Kastrup <address@hidden> writes:
>
>   > Dan Nicolaescu <address@hidden> writes:
>   > 
>   > > David Kastrup <address@hidden> writes:
>   > >
>   > >   > Andreas Schwab <address@hidden> writes:
>   > >   > 
>   > >   > > David Kastrup <address@hidden> writes:
>   > >   > >
>   > >   > >> Thanks for your input.  But all other applications
>   > >   > >> (including Emacs 22.x) run in this situation using
>   > >   > >> either tty or DISPLAY.
>   > >   > >
>   > >   > > Worksforme.
>   > >   > 
>   > >   > Current checkout of multi-tty from Savannah CVS?
>   > >
>   > > Worksforme too, current checkout of multi-tty from Savannah
>   > > CVS, then ./configure --prefix=..... ; make bootstrap strace
>   > > of src/emacs -Q -nw shows that it's using terminfo not
>   > > termcap. What system are you on?
>   > 
>   > Ubuntu Feisty.
>
> I tried this on a Ubuntu Feisty machine, but that machine does not
> have the X11 headers installed, so I could only compile a terminal
> based emacs.
>
> But this emacs would say "invalid argument framep 1" at startup. I
> set debug-on-error to t and run C-x 5 2. The backtrace showed that
> the error is in `getenv' and it is cause by an env.el change that
> YOU installed on the multi-tty branch without a ChangeLog.

If you tell me where to place the ChangeLog...  There is a CVS log
entry.

> PLEASE REVERT THE CHANGE! It is never a good idea to install changes
> without testing them, and you obviously didn't.

I did in a running session.  Anyway, if you bother to look at the
change, it does nothing except make the getenv actually do what its
DOC string claims to do.

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

The usual behavior for optional FRAME arguments is:

If FRAME is non-nil, return the value that would be normal if FRAME
were the current active frame.  If FRAME is nil, return the value for
the current active frame.

If we want to get at some special FRAME-less variant of the
environment list, one could use a special argument of "t" or something
like that.

But the whole concept of frame-local environment variables seems like
asking for trouble to me.  For example, say I have a *shell* buffer.
I call emacsclient from somewhere to open either a frame or a tty and
say M-x shell RET in that window.  The environment variables of that
shell will remain the old ones.  Now I say exit RET M-x shell RET
again.  Depending on the frame I say this, the behavior will be
different.  Or not.

Much worse: for sentinel processes (which have no dedicated terminal),
the value of PATH that gets used will be more or less randomly
decided.

Then Emacs already has the concept of a "terminal"
(info "(elisp) Multiple Displays").  There exist things like
terminal-local variables.  But we also have:

       A single X server can handle more than one screen.  A display
    name `HOST:SERVER.SCREEN' has three parts; the last part specifies
    the screen number for a given server.  When you use two screens
    belonging to one server, Emacs knows by the similarity in their
    names that they share a single keyboard, and it treats them as a
    single terminal.

So when frames get opened on the same X screen, from an Emacs session
and later from an emacsclient session, Emacs treats them as _one_
_terminal_.

It does not make sense to have disparate sets of environment variables
for them: if I subsequently use M-x setenv RET in one frame, I would
be surprised if that setting does not propagate to the other frame.

So what I would propose is that we don't touch the environment
variables at all.  At startup of either emacsclient or emacs itself,
we read out all relevant environment variables describing the current
terminal (and no other) and place them into terminal-local variables,
and that's it.  We don't look afterwards at them for dealing with the
terminal: if the user messes with them inside of Emacs, they only
affect processes started within Emacs.

That way we don't get to worry about just what set of frames might or
might not be affected by setting environment variables.

But the current treatment of process-environment and frame-local
environment variables is just fragile and asking for trouble.  Since
we can't actually use Emacs simultaneously from two ttys, it makes no
sense to give it two identities with regard to the environment.
Dealing with two ttys does not really require this amount of
complication.

So while I agree with Dan that my change should probably be reverted
(making getenv's FRAME argument be ignored completely, in contrast to
its current DOC string), it appears to me like we'd be better off if
pretty much all of the env.el changes (and callers) were reverted as
well, and we instead replaced the calls of (getenv "TERMCAP") and
similar with references to terminal-local variables filled in at the
start of Emacs and/or emacsclient.

What do you think?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum