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: Sun, 3 Dec 2017 21:20:40 +0000 Message-ID: <20171203212040.GA3907@ACM> References: <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> <83indnzka2.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1512336456 21243 195.159.176.226 (3 Dec 2017 21:27:36 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 3 Dec 2017 21:27:36 +0000 (UTC) User-Agent: Mutt/1.7.2 (2016-11-26) Cc: tom@tromey.com, dgutov@yandex.ru, monnier@iro.umontreal.ca, spinuvit@gmail.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Dec 03 22:27:31 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 1eLbnH-0004rO-QJ for ged-emacs-devel@m.gmane.org; Sun, 03 Dec 2017 22:27:24 +0100 Original-Received: from localhost ([::1]:40244 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eLbnO-0002z8-U7 for ged-emacs-devel@m.gmane.org; Sun, 03 Dec 2017 16:27:30 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46636) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eLbml-0002z2-VM for emacs-devel@gnu.org; Sun, 03 Dec 2017 16:26:53 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eLbmh-0007Nl-Dr for emacs-devel@gnu.org; Sun, 03 Dec 2017 16:26:51 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:27855 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1eLbmh-0007Lp-3Q for emacs-devel@gnu.org; Sun, 03 Dec 2017 16:26:47 -0500 Original-Received: (qmail 59831 invoked by uid 3782); 3 Dec 2017 21:26:42 -0000 Original-Received: from acm.muc.de (p548C6938.dip0.t-ipconnect.de [84.140.105.56]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 03 Dec 2017 22:26:40 +0100 Original-Received: (qmail 3995 invoked by uid 1000); 3 Dec 2017 21:20:40 -0000 Content-Disposition: inline In-Reply-To: <83indnzka2.fsf@gnu.org> 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:220665 Archived-At: Hello, Eli. On Sun, Dec 03, 2017 at 21:25:09 +0200, Eli Zaretskii wrote: > > 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? There is a style of coding called "literate programming" (I know nothing more about it) where pieces of C code (in C Mode, obviously) alternate with explanatory text (in text mode). If point is at the start of a C defun, C-M-a will have to take it to either the start of the text mode block or the previous C defun. Either way CC Mode needs to access buffer pieces outside the current chunk. > > 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? No, my main reason is philosophical. In Lisp, we're supposed to have the entire language available at read, evaluation, and print time. With this proposal, that notion becomes complicated and ugly, once you qualify how everything but `widen' and `narrow-to-region' are available. Using the region to do this is an abuse. This isn't what point-min and point-max were designed for. Programmers are going to carry on using `widen', and this will lead to possibly difficult to debug bugs. I am sure that this use of the region is going to lead to other nasty problems, even though I can't forsee in any detail what these will be. > > 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? I suppose so, but it will degrade such a function effectively into two, one special purpose function which can only be called from beginning-of-defun-function (etc.) and the other one called from everywhere else. There will be confusion between them. > > 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. Then we won't do it at all. Once all the effort has been put into making MMM work with the region, nobody will bother with putting the (substantial) effort into "new region". We'll lose the opportunity for a possibly better solution. > (And a proposal to do something along these lines was put forward by > Vitalie some time ago.) I didn't know that. Respect, Vitalie! > > 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)? The idea is to render the use of the region by MMM unnecessary, though it will need other code, too. The need to use parse-partial-sexp in any progmode buffer seems obvious, and having to do this in bits (as at the moment) seems an obvious enough inconvenience to make syntactic islands worthwhile. To be honest, I've no exact use case for them at the moment. They would allow, for example, syntax-ppss to work in an entire MMM buffer. -- Alan Mackenzie (Nuremberg, Germany).