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
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
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
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
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:
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
[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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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.
___
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
___
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
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
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
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
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:
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
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
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
RET after
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
RET after
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:
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
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
RET after sending the input to
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
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
39 matches
Mail list logo
