From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: [SUSPECTED SPAM] Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls Date: Fri, 1 Dec 2017 16:07:07 +0000 Message-ID: <20171201160707.GC3840@ACM> References: <20171129233237.27462.23351@vcs0.savannah.gnu.org> <20171129233238.504B5204F1@vcs0.savannah.gnu.org> <5d668ce5-1482-a3d4-c01b-7d996a532567@yandex.ru> <20171130214621.GA22157@ACM> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1512149593 25676 195.159.176.226 (1 Dec 2017 17:33:13 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 1 Dec 2017 17:33:13 +0000 (UTC) User-Agent: Mutt/1.7.2 (2016-11-26) Cc: emacs-devel@gnu.org, Tom Tromey , Vitalie Spinu , Dmitry Gutov To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 01 18:33:09 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eKpBN-00065Q-Rb for ged-emacs-devel@m.gmane.org; Fri, 01 Dec 2017 18:33:01 +0100 Original-Received: from localhost ([::1]:59016 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eKpBV-0006WP-3j for ged-emacs-devel@m.gmane.org; Fri, 01 Dec 2017 12:33:09 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56142) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eKnx3-0000cZ-OI for emacs-devel@gnu.org; Fri, 01 Dec 2017 11:15:13 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eKnvj-00018d-RH for emacs-devel@gnu.org; Fri, 01 Dec 2017 11:14:09 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:21291 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1eKnvj-00013P-88 for emacs-devel@gnu.org; Fri, 01 Dec 2017 11:12:47 -0500 Original-Received: (qmail 9674 invoked by uid 3782); 1 Dec 2017 16:12:45 -0000 Original-Received: from acm.muc.de (p548C7BEF.dip0.t-ipconnect.de [84.140.123.239]) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 01 Dec 2017 17:12:44 +0100 Original-Received: (qmail 3963 invoked by uid 1000); 1 Dec 2017 16:07:07 -0000 Content-Disposition: inline In-Reply-To: X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x [fuzzy] X-Received-From: 193.149.48.1 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:220562 Archived-At: Hello, Stefan. On Thu, Nov 30, 2017 at 18:03:05 -0500, Stefan Monnier wrote: > > Using narrowing for marking the bounds of a sub-mode is a bad thing, > > since it is likely to cause contention with other uses of narrowing. > Dmitry's solution to this threat is to say that indent-line-function > should always be called fully-widened, ..... That is a horrible, confusing, restriction, and an incompatibility with older and other Emacsen. > .... so there can be no "other uses of narrowing" that can get in the > way. The indent-line-function will be calling low-level functions which themselves widen, possibly to determine whether point-min is in a literal, or more generally to determine context. These low-level functions will also be called from other contexts, hence the necessity of widening. > > It's not clear what is meant here, but mandating maintainers of major > > modes to use narrowing in a particular way is at best controversial, and > > probably will render many major modes non-functional. > It doesn't mandate that major modes use narrowing. Quite the opposite: > it says "don't touch narrowing inside your indentation function (unless > you know what you're doing), because it's already setup for you". That is mandating the way major modes use (or don't use) narrowing. It's entirely the wrong thing to do, and will lead to trouble. Whatever this abuse of narrowing is trying to achieve can be done in other less damaging ways. > Stefan -- Alan Mackenzie (Nuremberg, Germany).