From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls Date: Sun, 03 Dec 2017 21:25:09 +0200 Message-ID: <83indnzka2.fsf@gnu.org> References: <20171201223529.GG3840@ACM> <4a94ec5c-efdd-50f1-ff4d-277f5f45c2df@yandex.ru> <83lgil1qme.fsf@gnu.org> <83d13x1j2s.fsf@gnu.org> <34abea95-c7f7-e8fa-8407-8c2fd2a4cfe1@yandex.ru> <83y3mkzw1n.fsf@gnu.org> <83mv2zzv7z.fsf@gnu.org> <643908a3-bec8-3ac1-38f7-4e73611478ef@yandex.ru> <20171203185946.GC5531@ACM> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1512329147 12087 195.159.176.226 (3 Dec 2017 19:25:47 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 3 Dec 2017 19:25:47 +0000 (UTC) Cc: tom@tromey.com, emacs-devel@gnu.org, monnier@iro.umontreal.ca, spinuvit@gmail.com, dgutov@yandex.ru To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Dec 03 20:25:43 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 1eLZtU-0002oN-V7 for ged-emacs-devel@m.gmane.org; Sun, 03 Dec 2017 20:25:41 +0100 Original-Received: from localhost ([::1]:39946 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eLZtc-0002Ky-CW for ged-emacs-devel@m.gmane.org; Sun, 03 Dec 2017 14:25:48 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48796) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eLZtT-0002Kp-0N for emacs-devel@gnu.org; Sun, 03 Dec 2017 14:25:39 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eLZtP-0002zq-Rg for emacs-devel@gnu.org; Sun, 03 Dec 2017 14:25:38 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:41233) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eLZtP-0002zU-Hb; Sun, 03 Dec 2017 14:25:35 -0500 Original-Received: from [176.228.60.248] (port=3741 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1eLZtN-0001It-Nw; Sun, 03 Dec 2017 14:25:35 -0500 In-reply-to: <20171203185946.GC5531@ACM> (message from Alan Mackenzie on Sun, 3 Dec 2017 18:59:46 +0000) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:220659 Archived-At: > Date: Sun, 3 Dec 2017 18:59:46 +0000 > Cc: Eli Zaretskii , tom@tromey.com, monnier@iro.umontreal.ca, > spinuvit@gmail.com, emacs-devel@gnu.org > From: Alan Mackenzie > > > > Convince Alan to do what? > > > To adhere to the current proposal (avoid widening in > > indent-line-function and font-lock-keywords, to start with). > > I know Eli has asked to move on from the emotional to the technical > stuff, but that last paragraph belongs to the former, and I will deal > with it as such. And I would _really_ want to move to the technical stuff. So... I actually don't understand all the fuss about widening. With a chunk of C code embedded in something that is not C, CC Mode cannot possibly need to look outside of the chunk, so why would you need to widen beyond that? > You mentioned today, I think, that writing an MMM is hard. Well, CC > Mode is hard, too. There are 30 calls to `widen' in CC Mode and 47 to > `narrow-to-region'. They are all there for a reason. It will be > grinding tedious work to sort out the whys and to remove them. Is that the only reason for your objections? The need to tediously go through a few dozen of calls to 'widen' and 'narrow-to-region', and take care of each one of them as appropriate? Or are there more substantial problems in adapting CC Mode to non-widening MMM? > so many of the `widen' calls are in low level functions called from > "everywhere". This can be taken care of with a more-or-less trivial wrapper and a variable. Right? > Yesterday, Richard Stallman suggested as an alternative to the > purloining of `widen' and `narrow-to-region' that a new "region" be > implemented somehow which would be independent of the existing region > and used solely by MMM super-modes. How about exploring this > possibility? We can do that if needed, but I don't see the need yet. (And a proposal to do something along these lines was put forward by Vitalie some time ago.) > Last February, I suggested extensions to the syntax code ("syntactic > islands") which would allow operations such as parse-partial-sexp to > work essentially without restriction in buffers with several syntax > tables. What problems does this solve? The problem with 'widen' or some other problem(s)?