[Top][All Lists]

[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: Mon, 14 May 2007 23:05:17 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/23.0.51 (gnu/linux)

David Kastrup <address@hidden> 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" 
/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" 
/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
which contains all environment variables relevant for a terminal, and
a terminal-local variable

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

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

reply via email to

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