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: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls Date: Fri, 1 Dec 2017 15:49:13 +0000 Message-ID: <20171201154913.GB3840@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> <27985594-3bb4-ce88-8928-2ccfeac13eae@yandex.ru> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1512145997 26492 195.159.176.226 (1 Dec 2017 16:33:17 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 1 Dec 2017 16:33:17 +0000 (UTC) User-Agent: Mutt/1.7.2 (2016-11-26) Cc: Tom Tromey , Stefan Monnier , Vitalie Spinu , emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 01 17:33:13 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 1eKoFT-0006W4-AV for ged-emacs-devel@m.gmane.org; Fri, 01 Dec 2017 17:33:11 +0100 Original-Received: from localhost ([::1]:58570 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eKoFa-00017b-FA for ged-emacs-devel@m.gmane.org; Fri, 01 Dec 2017 11:33:18 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33097) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eKnfD-0000D3-R9 for emacs-devel@gnu.org; Fri, 01 Dec 2017 10:56:25 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eKneS-0000xq-31 for emacs-devel@gnu.org; Fri, 01 Dec 2017 10:55:43 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:45035 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1eKneR-0000v8-1D for emacs-devel@gnu.org; Fri, 01 Dec 2017 10:54:55 -0500 Original-Received: (qmail 3244 invoked by uid 3782); 1 Dec 2017 15:54:51 -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 16:54:49 +0100 Original-Received: (qmail 3910 invoked by uid 1000); 1 Dec 2017 15:49:13 -0000 Content-Disposition: inline In-Reply-To: <27985594-3bb4-ce88-8928-2ccfeac13eae@yandex.ru> 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:220559 Archived-At: Hello, Dmitry. Just to be clear, in the following, by "narrowing" I mean all operations of narrowing and widening regarded generically. On Thu, Nov 30, 2017 at 23:09:00 +0000, Dmitry Gutov wrote: > Hi Alan, > On 11/30/17 9:46 PM, Alan Mackenzie 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. > Please give an example. A low level function which as an essential part of its functionality (for example, to make sure point-min isn't within a comment or string) widens. > > It's not clear what is meant here, > To rephrase, don't widen in indent-line-function or > beginning-of-defun-function. This is an intolerable restriction. The low level function mentioned above cannot, should not, must not know whether it's being called (indirectly) from indent-line-function or b-o-d-function. It will have to widen in all cases or none. Therefore there will be failures whilst being called either from one of the two noted functions or from elsewhere. > > 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. > I don't see a reason why. Even more, it should be compatible with all > uses of narrowing that I know about. See above. > > Narrowing belongs to users and major modes. > It can serve all. Indeed it can, and it must. A super-mode thus may not "reserve" narrowing for its own purposes to the exclusion of other uses. [ .... ] > > You can also understand me being a bit concerned at the reference to CC > > Mode. ;-) > You shouldn't be: CC Mode can just ignore this new rule, as long as it's > too hard to support embedding it in multi-mode buffers. The multi-mode mechanism should be designed to be usable with any major mode. There's nothing particularly hard about supporting CC Mode in a well designed multi-mode scheme. > >> - Multi-mode packages have been using narrowing for this purpose for > >> years, so they won't have to change much. > > They have used narrowing because that is the only tool they have had. > The only other tool we have is also narrowing, semantically. We need better tools. I have already proposed and offered to implement such tools. -- Alan Mackenzie (Nuremberg, Germany).