comint.el: EMACS environment variable
The change installed with CVS version 1.347 of comint.el breaks interaction with SWI Prolog in modes using comint-mode (e.g., shell and prolog-mode). SWI Prolog is an interactive program using the GNU readline library. The change has the same effect as an additional after sending the input to the inferior process (using ). Example Prolog program, "t.pl": t(a). t(b). t(c). t(d). Example invocation and interaction on a regular terminal: $ pl -s t.pl -q ?- t(X). X = a ; <-- user presses ";" X = b ; X = c ; X = d ; No In M-x shell: ?- t(X). X = a ; <-- ";" followed by ; X = b Yes SWI Prolog version: 5.6.22. In GNU Emacs 22.0.50.1 (i486-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of 2006-09-19 on rothera, modified by Debian (Debian emacs-snapshot package, version 1:20060915-1) X server distributor `The X.Org Foundation', version 11.0.70101000 configured using `configure '--build' 'i486-linux-gnu' '--host' 'i486-linux-gnu' '--prefix=/usr' '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib' '--localstatedir=/var' '--infodir=/usr/share/info' '--mandir=/usr/share/man' '--with-pop=yes' '--enable-locallisppath=/etc/emacs-snapshot:/etc/emacs:/usr/local/share/emacs/22.0.50/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/22.0.50/site-lisp:/usr/share/emacs/site-lisp:/usr/share/emacs/22.0.50/leim' '--with-x=yes' '--with-x-toolkit=athena' '--with-toolkit-scroll-bars' 'build_alias=i486-linux-gnu' 'host_alias=i486-linux-gnu' 'CFLAGS=-DDEBIAN -DSITELOAD_PURESIZE_EXTRA=5000 -g -O2'' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: en_US.UTF-8 locale-coding-system: utf-8 default-enable-multibyte-characters: t Minor modes in effect: show-paren-mode: t shell-dirtrack-mode: t tooltip-mode: t mouse-wheel-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t line-number-mode: t transient-mark-mode: t Thank you, and best wishes! -- Markus Triska ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: comint.el: EMACS environment variable
Markus Triska <[EMAIL PROTECTED]> writes: > The change installed with CVS version 1.347 of comint.el breaks > interaction with SWI Prolog in modes using comint-mode (e.g., shell > and prolog-mode). SWI Prolog is an interactive program using the GNU > readline library. The change has the same effect as an additional > after sending the input to the inferior process (using ). The change in question was 2006-09-12 Paul Eggert <[EMAIL PROTECTED]> * comint.el (comint-exec-1): Set EMACS to the full name of Emacs, not to "t". Do you remember what the rationale for this change was? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: comint.el: EMACS environment variable
Markus Triska writes: > > The change installed with CVS version 1.347 of comint.el breaks > interaction with SWI Prolog in modes using comint-mode (e.g., shell > and prolog-mode) Can you please post the log associated with 1.347 (and diff if not too long)? -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: comint.el: EMACS environment variable
Chong Yidong <[EMAIL PROTECTED]> writes: > Do you remember what the rationale for this change was? http://lists.gnu.org/archive/html/bug-gnu-emacs/2006-09/msg00014.html -- Romain Francoise <[EMAIL PROTECTED]> | The sea! the sea! the open it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the | ever free! --Bryan W. Procter ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: comint.el: EMACS environment variable
Yidong Chong <[EMAIL PROTECTED]> writes: > 2006-09-12 Paul Eggert <[EMAIL PROTECTED]> > > * comint.el (comint-exec-1): Set EMACS to the full name of Emacs, > not to "t". > > Do you remember what the rationale for this change was? You can find the change here: http://lists.gnu.org/archive/html/bug-gnu-emacs/2006-09/msg00020.html and look in the related thread for discussion. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: comint.el: EMACS environment variable
> > > The change installed with CVS version 1.347 of comint.el breaks > > > interaction with SWI Prolog in modes using comint-mode (e.g., shell > > > and prolog-mode). SWI Prolog is an interactive program using the GNU > > > readline library. The change has the same effect as an additional > > > after sending the input to the inferior process (using ). > >> 2006-09-12 Paul Eggert <[EMAIL PROTECTED]> >> >> * comint.el (comint-exec-1): Set EMACS to the full name of Emacs, >> not to "t". >> >> Do you remember what the rationale for this change was? > > You can find the change here: > > http://lists.gnu.org/archive/html/bug-gnu-emacs/2006-09/msg00020.html > > and look in the related thread for discussion. I guess with this change, either third-party programs that inspect the EMACS envvar will simply have to handle the new Emacs 22 behavior, or be incompatible. Ugh. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: comint.el: EMACS environment variable
> > > The change installed with CVS version 1.347 of comint.el breaks > > > interaction with SWI Prolog in modes using comint-mode (e.g., shell > > > and prolog-mode). SWI Prolog is an interactive program using the GNU > > > readline library. The change has the same effect as an additional > > > after sending the input to the inferior process (using ). > >> 2006-09-12 Paul Eggert <[EMAIL PROTECTED]> >> >> * comint.el (comint-exec-1): Set EMACS to the full name of Emacs, >> not to "t". >> >> Do you remember what the rationale for this change was? > > You can find the change here: > > http://lists.gnu.org/archive/html/bug-gnu-emacs/2006-09/msg00020.html > > and look in the related thread for discussion. I guess with this change, either third-party programs that inspect the EMACS envvar will simply have to handle the new Emacs 22 behavior, or be incompatible. Ugh. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: comint.el: EMACS environment variable
Yidong Chong <[EMAIL PROTECTED]> writes: > I guess with this change, either third-party programs that inspect the > EMACS envvar will simply have to handle the new Emacs 22 behavior, or > be incompatible. Ugh. Why would they care what it's value is though? I suspect it's just as common to simply check for the variable's existance, not its value. -Miles -- "1971 pickup truck; will trade for guns" ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: comint.el: EMACS environment variable
Miles Bader writes: > Why would they care what it's value is though? I suspect it's just as > common to simply check for the variable's existance, not its value. Yes, that's also common (at least those programs aren't broken by the change). Other programs checking for "t": tcsh, Maude, zsh. For easy optional backwards compatibility, what do you think about making the new behaviour depend on a variable like "emacs-environment-variable" with possible values 'path (use path; default) and t (old behaviour)? Best wishes! -- Markus Triska ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: comint.el: EMACS environment variable
Markus Triska <[EMAIL PROTECTED]> writes: >> Why would they care what it's value is though? I suspect it's just as >> common to simply check for the variable's existance, not its value. > > Yes, that's also common (at least those programs aren't broken by the > change). Other programs checking for "t": tcsh, Maude, zsh. For easy > optional backwards compatibility, what do you think about making the > new behaviour depend on a variable like "emacs-environment-variable" > with possible values 'path (use path; default) and t (old behaviour)? I agree with this proposal. Should the default be 'path or t? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: comint.el: EMACS environment variable
Chong Yidong wrote: Markus Triska <[EMAIL PROTECTED]> writes: Why would they care what it's value is though? I suspect it's just as common to simply check for the variable's existance, not its value. Yes, that's also common (at least those programs aren't broken by the change). Other programs checking for "t": tcsh, Maude, zsh. For easy optional backwards compatibility, what do you think about making the new behaviour depend on a variable like "emacs-environment-variable" with possible values 'path (use path; default) and t (old behaviour)? I agree with this proposal. Should the default be 'path or t? If the proposal is adopted, the default should be 'path. That will encourage 3rd-party programs that rely on the current value to change, yet allow the Emacs interface to those programs to work in the meantime by let-binding the new variable to t. BTW, wouldn't emacs-envvar-type be a better name for the variable? That would be consistent with the read-envvar-name function name. And perhaps its value should be an actual customize type, e.g. either (const t) or (file :mustmatch t). -- Kevin ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: comint.el: EMACS environment variable
Markus Triska <[EMAIL PROTECTED]> writes: > Miles Bader writes: > >> Why would they care what it's value is though? I suspect it's just as >> common to simply check for the variable's existance, not its value. > > Yes, that's also common (at least those programs aren't broken by the > change). Other programs checking for "t": tcsh, Maude, zsh. For easy > optional backwards compatibility, what do you think about making the > new behaviour depend on a variable like "emacs-environment-variable" > with possible values 'path (use path; default) and t (old behaviour)? This patch implements this (modulo the requisite documentation changes). *** emacs/lisp/comint.el.~1.348.~ 2006-09-28 16:31:39.0 -0400 --- emacs/lisp/comint.el2006-11-07 13:26:49.0 -0500 *** *** 363,368 --- 363,376 This is a good thing to set in mode hooks.") + ;;;###autoload + (defvar comint-subshell-envvar 'path + "Default value of the EMACS environment variable in subshells. + Any existing value for the EMACS environment variable overrides this. + A value of `path' means the absolute file name of the Emacs executable. + Otherwise, this should be a string that specifies the value of the + environment variable.") + (defvar comint-input-filter (function (lambda (str) (not (string-match "\\`\\s *\\'" str "Predicate for filtering additions to input history. *** *** 769,775 (list "TERM=emacs" (format "TERMCAP=emacs:co#%d:tc=unknown:" (window-width (unless (getenv "EMACS") ! (list (concat "EMACS=" invocation-directory invocation-name))) process-environment)) (default-directory (if (file-accessible-directory-p default-directory) --- 777,789 (list "TERM=emacs" (format "TERMCAP=emacs:co#%d:tc=unknown:" (window-width (unless (getenv "EMACS") ! (list (concat "EMACS=" ! (cond ((eq comint-subshell-envvar 'path) !(concat invocation-directory !invocation-name)) ! ((stringp comint-subshell-envvar) !comint-subshell-envvar) ! (t (error "Invalid subshell envvar")) process-environment)) (default-directory (if (file-accessible-directory-p default-directory) *** emacs/lisp/progmodes/compile.el.~1.409.~2006-09-24 17:59:32.0 -0400 --- emacs/lisp/progmodes/compile.el 2006-11-07 13:26:54.0 -0500 *** *** 1069,1075 ;; Set the EMACS variable, but ;; don't override users' setting of $EMACS. (unless (getenv "EMACS") ! (list (concat "EMACS=" invocation-directory invocation-name))) (copy-sequence process-environment (set (make-local-variable 'compilation-arguments) (list command mode name-function highlight-regexp)) --- 1069,1081 ;; Set the EMACS variable, but ;; don't override users' setting of $EMACS. (unless (getenv "EMACS") ! (list (concat "EMACS=" ! (cond ((eq comint-subshell-envvar 'path) !(concat invocation-directory !invocation-name)) ! ((stringp comint-subshell-envvar) !comint-subshell-envvar) ! (t (error "Invalid subshell envvar")) (copy-sequence process-environment (set (make-local-variable 'compilation-arguments) (list command mode name-function highlight-regexp)) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: comint.el: EMACS environment variable
> From: Chong Yidong <[EMAIL PROTECTED]> > Date: Tue, 07 Nov 2006 11:01:45 -0500 > > I agree with this proposal. Should the default be 'path or t? Whatever we do, please make sure to update the NEWS entry accordingly, including mention the new option. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: comint.el: EMACS environment variable
We changed the value of the EMACS envvar so as to fix a bug. That bug was real and needed to be fixed, but the fix causes another problem. Making that fix an option is not a solution, since it just means people choose between one bug or another bug. If people want to reopen this issue, the way to do it is to restudy the original bug together with the new problems, and find the solution that is best overall. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: comint.el: EMACS environment variable
Chong Yidong writes: > This patch implements this (modulo the requisite documentation > changes). Since e.g. compile.el and term.el also set EMACS, I suggest "emacs-environment-variable" instead of "comint-subshell-envvar". Best wishes! -- Markus ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: comint.el: EMACS environment variable
Richard Stallman <[EMAIL PROTECTED]> writes: > We changed the value of the EMACS envvar so as to fix a bug. That bug > was real and needed to be fixed, but the fix causes another problem. > > Making that fix an option is not a solution, since it just means > people choose between one bug or another bug. > > If people want to reopen this issue, the way to do it is to restudy > the original bug together with the new problems, and find the solution > that is best overall. The issue is pretty simple: whether to EMACS to "t", or change it. IIUC, the original complaint is that Makefile.in in some projects use the EMACS variable to refer to the emacs executable, and setting the EMACS envvar to "t" confuses such build scripts. On the other hand, changing the EMACS envvar to something else confuses projects that expect "t". It's clearly one or the other. Personally, I think we should revert the changes, and get whichever projects use EMACS in their build scripts to use some other variable name instead. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: comint.el: EMACS environment variable
This patch implements this (modulo the requisite documentation changes). Please do not go ahead with this solution. Adding an option to choose between two broken behaviors is not a good solution. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: comint.el: EMACS environment variable
It's clearly one or the other. Personally, I think we should revert the changes, and get whichever projects use EMACS in their build scripts to use some other variable name instead. I don't like that approach because it conflicts with a general convention for makefiles. I think that Emacs ought to that convention. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: comint.el: EMACS environment variable
Richard Stallman <[EMAIL PROTECTED]> writes: > It's clearly one or the other. Personally, I think we should revert > the changes, and get whichever projects use EMACS in their build > scripts to use some other variable name instead. > > I don't like that approach because it conflicts with a general > convention for makefiles. I think that Emacs ought to that > convention. So we should simply tell whichever programs look for EMACS=t to change? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: comint.el: EMACS environment variable
>> It's clearly one or the other. Personally, I think we should revert >> the changes, and get whichever projects use EMACS in their build >> scripts to use some other variable name instead. >> >> I don't like that approach because it conflicts with a general >> convention for makefiles. I think that Emacs ought to that >> convention. > So we should simply tell whichever programs look for EMACS=t to change? I guess rather than change the value of $EMACS, we should use another variable, like INSIDE_EMACS or FROM_EMACS. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: comint.el: EMACS environment variable
So we should simply tell whichever programs look for EMACS=t to change? I think that is the right thing to do. Another possibility is to switch to a different envvar name, but I think that would make an even bigger transient. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: comint.el: EMACS environment variable
Richard Stallman <[EMAIL PROTECTED]> writes: > So we should simply tell whichever programs look for EMACS=t to change? > > I think that is the right thing to do. > > Another possibility is to switch to a different envvar name, but I > think that would make an even bigger transient. OK. I'll email the SWI Prolog people to get them to make that change, and remove this item from FOR-RELEASE. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: comint.el: EMACS environment variable
> So we should simply tell whichever programs look for EMACS=t to change? > I think that is the right thing to do. > Another possibility is to switch to a different envvar name, but I > think that would make an even bigger transient. I don't think it'll be much bigger. And it has the benefit of being cleaner. Otherwise you get problem that when SWI-Prolog is run from a Makefile that sets EMACS to "emacs" (or somesuch) it'll think it's running inside Emacs. So since we're going to break the "test if $EMACS == t", it's a good opportunity to fix it right, rather than fix it by half only. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: comint.el: EMACS environment variable
Stefan Monnier <[EMAIL PROTECTED]> writes: > Otherwise you get problem that when SWI-Prolog is run from a > Makefile that sets EMACS to "emacs" (or somesuch) it'll think it's > running inside Emacs. Such circumstances are probably negligibly rare: interactive programs (which should be the only ones that care about the EMACS envvar) are generally not run from Makefiles. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: comint.el: EMACS environment variable
>> Otherwise you get problem that when SWI-Prolog is run from a >> Makefile that sets EMACS to "emacs" (or somesuch) it'll think it's >> running inside Emacs. > Such circumstances are probably negligibly rare: interactive programs > (which should be the only ones that care about the EMACS envvar) are > generally not run from Makefiles. Could be. I also thought that the conflict between Makefile's use of $EMACS and comint's use of it would be negligibly rare, but obviously, it's been found important enough. I just think that if we're going to break compatibility, we may as well do it "once and forall". Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: comint.el: EMACS environment variable
OK. I'll email the SWI Prolog people to get them to make that change, and remove this item from FOR-RELEASE. Could you please add an item about this in etc/PROBLEMS? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: comint.el: EMACS environment variable
> Another possibility is to switch to a different envvar name, but I > think that would make an even bigger transient. I don't think it'll be much bigger. And it has the benefit of being cleaner. Let's set another envvar now, and suggest that other programs switch to it gradually. It could be called INSIDE_EMACS. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: comint.el: EMACS environment variable
Richard Stallman <[EMAIL PROTECTED]> writes: > > Another possibility is to switch to a different envvar name, but I > > think that would make an even bigger transient. > > I don't think it'll be much bigger. And it has the benefit of being > cleaner. > > Let's set another envvar now, and suggest that other programs switch > to it gradually. > > It could be called INSIDE_EMACS. So, in the meantime, Emacs will set *two* envvars, EMACS and INSIDE_EMACS? That's really ugly. The transient *is* bigger for this suggestion. And its benefit would be to fix a bug that doesn't even exist! Is there even a single interactive program using the EMACS envvar that is run from a Makefile??? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: comint.el: EMACS environment variable
Richard Stallman <[EMAIL PROTECTED]> writes: > > Another possibility is to switch to a different envvar name, but I > > think that would make an even bigger transient. > > I don't think it'll be much bigger. And it has the benefit of being > cleaner. > > Let's set another envvar now, and suggest that other programs switch > to it gradually. > > It could be called INSIDE_EMACS. I think this is a bad idea. IIUC, the problem that triggered the change from EMACS=t to EMACS=/where/is/emacs was that some configure scripts (unrelated to Emacs) assumed that the environment variable EMACS -- if set -- contains the full directory file name of the Emacs executable. But we have _for many years_ had the convention that Emacs sets EMACS=t in inferior shells. And this is not a secret convention, as several programs have adapted to that convention to adapt themselves to work properly in that environment... So why change the convention now (I know we already changed the code)? Why is that a problem for Emacs? I would claim that it is a problem for the configure scripts which _incorrectly_ assumes that $EMACS is a file name. The change that was installed recently breaks several programs which have been explicitly modified to play nicely with Emacs -- to please some configure scripts which makes false assumptions about the contents of the EMACS environment variable. In fact, why would anyone _blindly assume_ that $EMACS is a file name? If it is makeconf which assumes that, it is broken IMO (but I don't know)... I'm strongly in favour of reverting those changes, and just add something to etc/PROBLEMS to warn about known packages which have "broken" configure scripts. Introducing another environment variable like INSIDE_EMACS=t to replace EMACS=t doesn't cure the breakage to the "nice programs". I'd hate to release Emacs 22 which works worse than Emacs 21 with the "nice programs", just to make it work better in the rare cases where someone build a specific package inside Emacs. Again, I suggest that we revert the changes for now, and reconsider the whole issue again after the release. -- Kim F. Storm <[EMAIL PROTECTED]> http://www.cua.dk ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: comint.el: EMACS environment variable
So, in the meantime, Emacs will set *two* envvars, EMACS and INSIDE_EMACS? That's really ugly. It's not ugly. That's the way to do a transition. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: comint.el: EMACS environment variable
> Introducing another environment variable like INSIDE_EMACS=t to replace > EMACS=t doesn't cure the breakage to the "nice programs". > I'd hate to release Emacs 22 which works worse than Emacs 21 with the > "nice programs", just to make it work better in the rare cases where > someone build a specific package inside Emacs. > Again, I suggest that we revert the changes for now, and reconsider the whole > issue again after the release. Agreed. And setting both EMACS and INSIDE_EMACS is the worst of all proposed solutions. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: comint.el: EMACS environment variable
Can we get this discussion moving again? There seems to be only three viable possibilities: 0. Keep EMACS=/path/to/emacs 1. Revert to EMACS="t" 2. Revert to EMACS="t" and set INSIDE_EMACS="t" Let's just pick one and be done with it. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: comint.el: EMACS environment variable
IIUC, the problem that triggered the change from EMACS=t to
EMACS=/where/is/emacs was that some configure scripts (unrelated
to Emacs) assumed that the environment variable EMACS -- if set --
contains the full directory file name of the Emacs executable.
I think that these configure scripts are following a general
convention for configuration files. The convention is not stated
explicitly, but it is implicit in this part of standards.texi:
Specifying variables as arguments to @code{configure}, like this:
@example
./configure CC=gcc
@end example
is preferable to setting them in environment variables:
@example
CC=gcc ./configure
@end example
as it helps to recreate the same configuration later with
@file{config.status}.
@end table
We cannot criticize them for using EMACS to specify where to find
Emacs after we suggested using CC to specify where to find cc.
So I think the only correct solution in the long term is to move to a
different variable (such as INSIDE_EMACS) to say "you're inside
Emacs". This means we should start setting the other envvar now.
There are two ways to do the transition: with EMACS=t or with
EMACS=<>. When we changed it to <>, we
thought that would be upward compatible. Since it is not,
it means that for the short term we have to choose between one
set of bugs and another.
I think we will have fewer bugs if we put EMACS back to t.
So let's set both EMACS and INSIDE_EMACS to t.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: comint.el: EMACS environment variable
Richard Stallman <[EMAIL PROTECTED]> writes: > So let's set both EMACS and INSIDE_EMACS to t. Fine with me! Then all current users of EMACS=t will have time to adapt to the change ... before Emacs 23 is out. -- Kim F. Storm <[EMAIL PROTECTED]> http://www.cua.dk ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: comint.el: EMACS environment variable
Richard Stallman <[EMAIL PROTECTED]> writes:
> I think we will have fewer bugs if we put EMACS back to t.
>
> So let's set both EMACS and INSIDE_EMACS to t.
Here is a patch:
*** comint.el 29 Sep 2006 10:48:53 +0200 1.348
--- comint.el 17 Nov 2006 16:43:23 +0100
***
*** 769,775
(list "TERM=emacs"
(format "TERMCAP=emacs:co#%d:tc=unknown:" (window-width
(unless (getenv "EMACS")
! (list (concat "EMACS=" invocation-directory invocation-name)))
process-environment))
(default-directory
(if (file-accessible-directory-p default-directory)
--- 769,778
(list "TERM=emacs"
(format "TERMCAP=emacs:co#%d:tc=unknown:" (window-width
(unless (getenv "EMACS")
! ;; This is for Emacs 23:
! ;; (list (concat "EMACS=" invocation-directory invocation-name))
! (list "EMACS=t"))
! (list "INSIDE_EMACS=t")
process-environment))
(default-directory
(if (file-accessible-directory-p default-directory)
*** compile.el 11 Nov 2006 23:17:37 +0100 1.411
--- compile.el 17 Nov 2006 15:52:53 +0100
***
*** 1069,1075
;; Set the EMACS variable, but
;; don't override users' setting of $EMACS.
(unless (getenv "EMACS")
! (list (concat "EMACS=" invocation-directory invocation-name)))
(copy-sequence process-environment
(set (make-local-variable 'compilation-arguments)
(list command mode name-function highlight-regexp))
--- 1069,1078
;; Set the EMACS variable, but
;; don't override users' setting of $EMACS.
(unless (getenv "EMACS")
! ;; This is for Emacs 23:
! ;; (list (concat "EMACS=" invocation-directory invocation-name))
! '("EMACS=t"))
! '("INSIDE_EMACS=t")
(copy-sequence process-environment
(set (make-local-variable 'compilation-arguments)
(list command mode name-function highlight-regexp))
*** misc.texi 12 Sep 2006 23:49:59 +0200 1.93
--- misc.texi 17 Nov 2006 17:16:03 +0100
***
*** 486,497
@kbd{C-x @key{RET} p} in the shell buffer. @xref{Communication
Coding}.
@cindex @env{EMACS} environment variable
Unless the environment variable @env{EMACS} is already defined,
! Emacs defines it in the subshell, with value equal to Emacs's absolute
! file name. A shell script
! can check this variable to determine whether it has been run from an
! Emacs subshell.
@node Shell Mode
@subsection Shell Mode
--- 486,507
@kbd{C-x @key{RET} p} in the shell buffer. @xref{Communication
Coding}.
+ @cindex @env{INSIDE_EMACS} environment variable
+ Emacs unconditionally defines the environment variable
+ @env{INSIDE_EMACS} in the subshell, with value @code{t}. A shell
+ script can check this variable to determine whether it has been run
+ from an Emacs subshell. This variable is new in Emacs 22, and
+ supersedes the @env{EMACS} environment variable.
+
@cindex @env{EMACS} environment variable
Unless the environment variable @env{EMACS} is already defined,
! Emacs defines it in the subshell, with value @code{t}.
!
! @strong{Warning:} Checking this variable to test whether a shell
! script is being run inside Emacs is deprecated, and from Emacs 23 its
! value will change to be equal to Emacs's absolute file name. New and
! existing programs should be changed to check @env{INSIDE_EMACS} before
! @env{EMACS}.
@node Shell Mode
@subsection Shell Mode
*** NEWS15 Nov 2006 13:44:34 +0100 1.1405
--- NEWS17 Nov 2006 17:21:19 +0100
***
*** 1455,1462
but declared obsolete.
+++
! *** The EMACS environment variable now defaults to Emacs's absolute
! file name, instead of to "t".
** M-x Compile changes:
--- 1455,1466
but declared obsolete.
+++
! *** The new INSIDE_EMACS environment variable is set unconditionally
! to the value "t". It supersedes the EMACS environment variable, which
! is planned to change value to Emacs's absolute file name in Emacs 23.
!
! Programs that need to know whether they are started inside Emacs,
! should check INSIDE_EMACS before checking EMACS.
** M-x Compile changes:
--
Kim F. Storm <[EMAIL PROTECTED]> http://www.cua.dk
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: comint.el: EMACS environment variable
Looks fine to me, except
> ! ;; This is for Emacs 23:
> ! ;; (list (concat "EMACS=" invocation-directory invocation-name))
> ! '("EMACS=t"))
> ! '("INSIDE_EMACS=t")
The comment is incorrect, and should simply be removed: we won't be
changing EMACS to the filename of Emacs if we introduce an
INSIDE_EMACS variable.
Everyone else looks OK.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: comint.el: EMACS environment variable
What about the EMACS variable in term mode (the one invoked by M-x term RET)? Currently, the variable is set to the emacs version, like $ echo $EMACS 22.0.90.1 (term:0.96) Jae-hyeon ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: comint.el: EMACS environment variable
What about the EMACS variable in term mode (the one invoked by M-x term RET)? Currently, the variable is set to the emacs version, like $ echo $EMACS 22.0.90.1 (term:0.96) term should set INSIDE_EMACS as well. The idea of using the Emacs version as the value is a good one; let's do that in comint as well. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: comint.el: EMACS environment variable
[EMAIL PROTECTED] (Kim F. Storm) writes: > Richard Stallman <[EMAIL PROTECTED]> writes: > >> I think we will have fewer bugs if we put EMACS back to t. >> >> So let's set both EMACS and INSIDE_EMACS to t. > > Here is a patch: I've checked in a similar patch. Thanks. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: comint.el: EMACS environment variable
> What about the EMACS variable in term mode (the one invoked by M-x > term RET)? Currently, the variable is set to the emacs version, like > $ echo $EMACS > 22.0.90.1 (term:0.96) > term should set INSIDE_EMACS as well. I believe it's important to distinguish term from comint: the reason why external programs sometimes want to check is EMACS=t (or now INSIDE_EMACS=t) is because they need to adjust to the peculiar way comint interacts with its inferior process: on the one side it's interactive, but on the other it sends whole commands at a time (the inferior process doesn't get to see keystrokes). OTOH term.el interacts with its inferior processes pretty much like xterm or any other terminal emulator would. So I think setting EMACS to t in comint and to something different (namely ) in term was no mistake. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: comint.el: EMACS environment variable
Well, it's simple enough for Emacs to generate, but if it's a constant strings, it's easier for the other process to recognize it. It is easy to recognize "(comint". Please don't exaggerate these minor problems. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: comint.el: EMACS environment variable
Richard Stallman <[EMAIL PROTECTED]> writes: > Well, it's simple enough for Emacs to generate, but if it's a constant > strings, it's easier for the other process to recognize it. > > It is easy to recognize "(comint". > Please don't exaggerate these minor problems. It would be even easier for a shell script to recongize without the parentheses I don't see their purpose (except making the value look like Lisp), so let's leave them out. -- Kim F. Storm <[EMAIL PROTECTED]> http://www.cua.dk ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: comint.el: EMACS environment variable
> Well, it's simple enough for Emacs to generate, but if it's a constant > strings, it's easier for the other process to recognize it. > It is easy to recognize "(comint". > Please don't exaggerate these minor problems. I'm not saying it's hard. Just that it is easier for people to adapt to the new scheme if we only change the name of the variable but not its value and if we keep the value constant where it was constant (in some languages (e.g. in a /.bashrc file), changing an exact string match to a substring/prefix match may require more than just changing `equal' to `string-match'). I personally don't see *any* benefit to including the revision information there. So even if the inconvenience is small, it's still an inconvenience and I don't see any justification for it. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: comint.el: EMACS environment variable
It would be even easier for a shell script to recongize without the parentheses I don't see their purpose (except making the value look like Lisp), so let's leave them out. Ok. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
