From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: phillip.lord@russet.org.uk (Phillip Lord) Newsgroups: gmane.emacs.devel Subject: Re: Considered Harmful 73d213: "Comint, term, and compile new set Emacs" Date: Tue, 05 Apr 2016 23:08:23 +0100 Message-ID: <8737qzso88.fsf@russet.org.uk> References: <87oa9otixb.fsf@russet.org.uk> <5703E15B.7080601@cs.ucla.edu> <87k2kcovt8.fsf@russet.org.uk> <5704233B.4020103@cs.ucla.edu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1459894129 9030 80.91.229.3 (5 Apr 2016 22:08:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 5 Apr 2016 22:08:49 +0000 (UTC) Cc: eggert@penguin.cs.ucla.edu, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Apr 06 00:08:39 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1anZ9I-0003iX-7U for ged-emacs-devel@m.gmane.org; Wed, 06 Apr 2016 00:08:36 +0200 Original-Received: from localhost ([::1]:39550 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1anZ9H-0003Og-G0 for ged-emacs-devel@m.gmane.org; Tue, 05 Apr 2016 18:08:35 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58657) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1anZ9D-0003Oa-O0 for emacs-devel@gnu.org; Tue, 05 Apr 2016 18:08:32 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1anZ98-0004xJ-SU for emacs-devel@gnu.org; Tue, 05 Apr 2016 18:08:31 -0400 Original-Received: from cloud103.planethippo.com ([31.216.48.48]:60425) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1anZ98-0004w9-HS for emacs-devel@gnu.org; Tue, 05 Apr 2016 18:08:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=russet.org.uk; s=default; h=Content-Type:MIME-Version:Message-ID: In-Reply-To:Date:References:Subject:Cc:To:From; bh=0salj+onf01w9e4NFJGRr11/M0UVOzpVfYHr37lZWV0=; b=x40V1EN8qoEa1Pjh33wuBz2xh1 YRCpdrT1mOQyU3Dyo8geIy0/vvaFn8eHu72gSjiPhmF82yqCx2mo7iTX6vRV+R9o8TNDair90A/nj 30jNi0PdBL47BurLlBKN+8sFN+DZYIzVu+gokgdR9VTLO6OCVVKOLGj+JnxAysVEN1d5OhN3q2ZET 8Xs9xrTbOWM5efdB5A+6/v2WV0QXyRv1rjR4hS/AQtZjvII7opwYDVNj8lzvd5xwL248ejbDDP+EV a0Tdlv/1t41luw9lo41VBnntOhnBqP/bEK/Ih3dq29YMdRN3JhiTKxJbibAsC/7XZieSTAo5488Gz JIlfVqaw==; Original-Received: from cpc1-benw10-2-0-cust373.gate.cable.virginm.net ([77.98.219.118]:43197 helo=russet.org.uk) by cloud103.planethippo.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.86_1) (envelope-from ) id 1anZ96-001kp6-VF; Tue, 05 Apr 2016 23:08:25 +0100 In-Reply-To: <5704233B.4020103@cs.ucla.edu> (Paul Eggert's message of "Tue, 5 Apr 2016 13:42:35 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cloud103.planethippo.com X-AntiAbuse: Original Domain - gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - russet.org.uk X-Get-Message-Sender-Via: cloud103.planethippo.com: authenticated_id: phillip.lord@russet.org.uk X-Authenticated-Sender: cloud103.planethippo.com: phillip.lord@russet.org.uk X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 31.216.48.48 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:202757 Archived-At: Paul Eggert 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