Re: Considered Harmful 73d213: "Comint, term, and compile new set Emacs"

[phillip.lord@russet.org.uk (Phillip Lord)]

Paul Eggert <eggert@cs.ucla.edu> writes:

> On 04/05/2016 09:38 AM, Phillip Lord wrote:
>> I don't
>> have a workaround, I have limited the scope of the existing workaround
>> to Emacs-24.
>
> Would something like the following be an adequate workaround? The idea is to
> have code that works with both Emacs 25 and Emacs 24 (and Emacs 23 etc., for
> that matter):
>
>     def get_emacs_from_env():
>         emacs = ENVB.get(b'CASK_EMACS')
>         if emacs:
>             return emacs
>         emacs = ENVB.get(b'EMACS')
>         if emacs != 't':
>             return emacs
>         return None

Maybe. Given that I spent several weeks working on the last pull
request, it may take a while for me to get up the energy to try.

The main problem is that use of cask tends to weave in and out of
different Emacs and also Makefiles. So, I use this:

EMACS ?= emacs
CASK ?= cask

-include makefile-local

all: install test

install:
	EMACS=$(EMACS) cask install

Which (did) work fine on Emacs-25 but now fails because EMACS the
invocation ends up as the entirely useless EMACS=t cask install

So, the problem isn't one just for cask, but also make. As other people
have said, the only safe solution is to not use the EMACS variable. This
was suggested for cask, and I have added that also. But, ultimately,
EMACS is the obvious name and CASK_EMACS is not.

Still, all of this has been said before.

>> Is there not a different solution to the bash problem? Passing
>> --noediting as an option would work, I think, and it should work with
>> both the old and new $EMACS handling of bash.
>>
>
> Part of the worry here is that programs other than Bash will be affected, and
> that we need to give people some time to adjust to the changed behavior of
> Emacs, by announcing the planned change in Emacs 25 and then actually making
> the change in a later Emacs release.

Emacs doesn't really have a formal deprecation policy, I think. So, even
if the change is announced in Emacs-25, there will still be breakage in
Emacs-26. As Stefan said "if we wait, nothing is ever going to move".

http://lists.gnu.org/archive/html/emacs-devel/2015-03/msg01034.html

I'm also not convinced that a bug report should be enough to revert a
change during pre-test. Reverting a breaking change that has been applied
deliberately is, effectively a breaking change all of its own.

Anyway, I guess bug #20202 needs re-opening.

Phil