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

[David Kastrup <dak@gnu.org>]

David Kastrup <dak@gnu.org> writes:

> 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.

Ok, here are the Lisp callers which pass a third argument into getenv.

/home/tmp/emacs/lisp/international/mule-cmds.el:2512:	  (setq locale (getenv (pop vars) display)))))
/home/tmp/emacs/lisp/international/mule-cmds.el:2639:		 (equal (getenv "TERM_PROGRAM" display) "Apple_Terminal"))
/home/tmp/emacs/lisp/international/mule-cmds.el:2657:	      (setq locale (getenv (pop vars) display))))
/home/tmp/emacs/lisp/term/rxvt.el:287:  (let ((fgbg (getenv "COLORFGBG" (terminal-id)))
/home/tmp/emacs/lisp/term/x-win.el:2439:			 (setq x-display-name (or (getenv "DISPLAY" (terminal-id))
/home/tmp/emacs/lisp/term/xterm.el:330:  (if (and (getenv "COLORTERM" (terminal-id))
/home/tmp/emacs/lisp/term/xterm.el:331:	   (string-match "\\`rxvt" (getenv "COLORTERM" (terminal-id))))

Most of these appear _not_ to pass a FRAME parameter (as claimed by
getenv's DOC string and its code) but a terminal id.

This is completely messed up, and ignoring the FRAME parameter is
_not_ the right solution.

The c callers are somewhat harder to find: basically, they would be
the ones calling getenv_internal with a non-nil fifth argument.

Then the rest of the code is a mixture of calling getenv (the system
call) and egetenv (which goes through a frame list presumably).

All of this is a mess.

I propose that we split this whole mess apart cleanly.  We create one
read-only variable called
terminal-environment-list
which contains all environment variables relevant for a terminal, and
a terminal-local variable
terminal-environment

When a new terminal gets opened, all environment variables in
terminal-environment-list get transferred to terminal-environment.  We
also provide a convenience routine
getenv-terminal
to read from the current terminal-environment.  Changing it is not
supported.

For debugging purposes (before the next release), we can add code to
getenv that complains when it gets asked about a variable in
terminal-environment-list: this is most likely a bug.

That way, getenv and setenv will continue to work exclusively on a
single process-environment.

Does this sound reasonable?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum