I like to do my builds of almost anything from source under emacs Shell
mode. But emacs Shell mode sets the environment variable EMACS to
"t". This causes the output of autoconf's AC_CHECK_PROG(EMACS, ...)
to set EMACS="t", with the result that in any Makefile generated from
EMACS = @EMACS@ in Ma
<[EMAIL PROTECTED]> writes:
> I like to do my builds of almost anything from source under emacs Shell
> mode. But emacs Shell mode sets the environment variable EMACS to
> "t". This causes the output of autoconf's AC_CHECK_PROG(EMACS, ...)
> to set EMACS="t", with the result that in any Makefile
> For a short-term correction, I think the easiest way is to change
> Autoconf to ignore a value of `t' for this environment variable.
> Autoconf maintainers, what do you think?
>
> For longer term, perhaps the best thing is to change Emacs to use a
> different environment variable. Alas, I don't
> "rms" == Richard Stallman <[EMAIL PROTECTED]> writes:
rms> For a short-term correction, I think the easiest way is to
rms> change Autoconf to ignore a value of `t' for this environment
rms> variable. Autoconf maintainers, what do you think?
rms> For longer term, perhaps th
> "Chet" == Chet Ramey <[EMAIL PROTECTED]> writes:
Chet> Bash does inspect the EMACS environment variable as part of
Chet> checking whether or not to turn off line editing even when
Chet> the shell is interactive. It also checks for TERM==emacs.
Chet> If the shell discovers it
I like to do my builds of almost anything from source under emacs Shell
mode. But emacs Shell mode sets the environment variable EMACS to
"t".
This causes the output of autoconf's AC_CHECK_PROG(EMACS, ...)
to set EMACS="t", with the result that in any Makefile generated from
Your fix is very clever, and I think it is a feature that running configure
scripts in a shell under Emacs uses the same Emacs. So please install
your change, and we can consider the problem fully solved.
> <[EMAIL PROTECTED]> writes:
> >For example, emacs could send the shell something like "shopt
> > -u -o emacs; shopt -u -o vi". Then emacs could leave EMACS alone.
>
> Stuffing input to a subshell like that is in general not something you
> can do reliably.
Yeah, that's dicy, but you don't have
Chet Ramey <[EMAIL PROTECTED]> writes:
>> <[EMAIL PROTECTED]> writes:
>> >For example, emacs could send the shell something like "shopt
>> > -u -o emacs; shopt -u -o vi". Then emacs could leave EMACS alone.
>>
>> Stuffing input to a subshell like that is in general not something you
>> can do re
<[EMAIL PROTECTED]> writes:
>For example, emacs could send the shell something like "shopt
> -u -o emacs; shopt -u -o vi". Then emacs could leave EMACS alone.
Stuffing input to a subshell like that is in general not something you
can do reliably.
-miles
--
We are all lying in the gutter, but s
10 matches
Mail list logo
