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 [email protected] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
