Re: comint.el: EMACS environment variable

[Kim F. Storm]

Richard Stallman <address@hidden> 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 <address@hidden> http://www.cua.dk