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: Thu, 30 Nov 2017 21:46:21 +0000 Message-ID: <20171130214621.GA22157@ACM> References: <20171129233237.27462.23351@vcs0.savannah.gnu.org> <20171129233238.504B5204F1@vcs0.savannah.gnu.org> <5d668ce5-1482-a3d4-c01b-7d996a532567@yandex.ru> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1512151215 7747 195.159.176.226 (1 Dec 2017 18:00:15 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 1 Dec 2017 18:00:15 +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 19:00:11 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 1eKpbc-0001Y8-Al for ged-emacs-devel@m.gmane.org; Fri, 01 Dec 2017 19:00:08 +0100 Original-Received: from localhost ([::1]:59263 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eKpbh-00051R-Vt for ged-emacs-devel@m.gmane.org; Fri, 01 Dec 2017 13:00:14 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56807) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eKoKh-0006Om-79 for emacs-devel@gnu.org; Fri, 01 Dec 2017 11:38:38 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eKoKc-0004bU-7b for emacs-devel@gnu.org; Fri, 01 Dec 2017 11:38:35 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:20246 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1eKoKb-0004ar-Sa for emacs-devel@gnu.org; Fri, 01 Dec 2017 11:38:30 -0500 Original-Received: (qmail 98745 invoked by uid 3782); 30 Nov 2017 21:51:47 -0000 Original-Received: from acm.muc.de (p548C728E.dip0.t-ipconnect.de [84.140.114.142]) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 30 Nov 2017 22:51:46 +0100 Original-Received: (qmail 22993 invoked by uid 1000); 30 Nov 2017 21:46:21 -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:220566 Archived-At: Hello, Dmitry. On Thu, Nov 30, 2017 at 10:58:47 +0000, Dmitry Gutov wrote: > On 11/30/17 8:59 AM, Dmitry Gutov wrote: > > On 11/30/17 1:53 AM, Stefan Monnier wrote: > >>>      Replace prog-widen with consolidating widen calls > >> So, IIUC the idea is that the multi-major-mode framework will *have* to > >> use narrowing to indicate to the sub-modes the boundaries of the current > >> chunk, right? 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. There are better ways. > > Yes. Just like it would *have* to bind prog-indentation-context to a > > complex-ish value in the previous proposal. > And while the difference isn't night and day, allow me to elaborate why > I think this is a move in a good direction: > - Major mode authors have been forgetting to widen in all the cases they > actually have to. Or they would do that in indent-line-function, but > forget in beginning-of-defun-function, etc. Now, they are *mandated* to > obey the current narrowing 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. > (deleting code is easy, and some won't have delete anything at all). > The indentation code might fail to work inside narrowing (like all of > CC Mode, probably), but that's an orthogonal issue. Narrowing belongs to users and major modes. I am lacking the context of your post, which appears to start deep down in some mail thread which I don't have, so I can't follow the details of your proposal. But I would appreciate you confirming that these proposals won't place any constraints whatsoever on how users and major modes can use narrowing. You can also understand me being a bit concerned at the reference to CC Mode. ;-) > - 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. > And, it's kind of funny, mhtml-indent-line which we've reviewed and > added recently, uses narrow-to-region too. :-) While disregarding the > second element of prog-indentation-context (which it set to the value > "widen all you want"). Which works well enough because SMIE doesn't > widen, and I've removed the `widen' call from js-mode indentation code > 3.5 years ago. > I'm adding Tom and Vitalie to Cc. Maybe they have something to add. -- Alan Mackenzie (Nuremberg, Germany).