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 18:59:46 +0000 Message-ID: <20171203185946.GC5531@ACM> 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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1512327955 4836 195.159.176.226 (3 Dec 2017 19:05:55 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 3 Dec 2017 19:05:55 +0000 (UTC) User-Agent: Mutt/1.7.2 (2016-11-26) Cc: Eli Zaretskii , tom@tromey.com, monnier@iro.umontreal.ca, spinuvit@gmail.com, emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Dec 03 20:05:49 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 1eLZaF-0000rw-Q3 for ged-emacs-devel@m.gmane.org; Sun, 03 Dec 2017 20:05:48 +0100 Original-Received: from localhost ([::1]:39885 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eLZaN-0001tc-7N for ged-emacs-devel@m.gmane.org; Sun, 03 Dec 2017 14:05:55 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43886) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eLZaD-0001tJ-Hx for emacs-devel@gnu.org; Sun, 03 Dec 2017 14:05:46 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eLZaA-0006Qm-DH for emacs-devel@gnu.org; Sun, 03 Dec 2017 14:05:45 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:15717 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1eLZaA-0006PW-2E for emacs-devel@gnu.org; Sun, 03 Dec 2017 14:05:42 -0500 Original-Received: (qmail 19279 invoked by uid 3782); 3 Dec 2017 19:05:39 -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 20:05:37 +0100 Original-Received: (qmail 9615 invoked by uid 1000); 3 Dec 2017 18:59:46 -0000 Content-Disposition: inline In-Reply-To: <643908a3-bec8-3ac1-38f7-4e73611478ef@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:220658 Archived-At: Hello, Dmitry. On Sun, Dec 03, 2017 at 16:35:23 +0000, Dmitry Gutov wrote: > On 12/3/17 3:28 PM, Eli Zaretskii wrote: > > Because every development environment should first support its own > > development well. If it doesn't do that, it's incomplete. > OK, I see. But! > This feature is *not* targeted at Emacs development. > Please don't make me fly out to Scotland and chase Alan down with a > broomstick to make this development come through. Please read my signature, sometime. > > Indeed; and C-like languages are quite popular among them. > Not in comparison to JS, CSS and HTML. > > How will we look if we support JS and Ruby embedded in HTML, but not C > > code embedded in Yacc grammars nor Awk snippets embedded in shell > > scripts? Both are quite frequent out there. We will be laughed at. > We'll be fine. And the actual support is still going to reside in > third-party packages for now. This change just makes them possible (or > their codebases saner, at least). > Except for antlr-mode. It will be able to use it right away (the version > inside Emacs, at least). > > 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. Maybe I missed it, but I don't recall anybody posting the suggestion "Hey, we're considering writing an MMM mode which will mean nobody else can use narrowing and widening, what do people think?". If somebody had posted that, there's a good chance that discussions could have sorted out the technical stuff without provoking bad feelings. Right now, I am being painted as the bad person for objecting to being restricted to a subset of Emacs Lisp for CC Mode. Forgive me for feeling a bit peeved, but despite being in Emacs development for around 15 years, nobody asked me beforehand what I thought of this. It is yet one more thing that is presented as a done thing and foisted on Emacs developers without them having any say in the matter. 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. You categorise the injunction against widening as "only applying to indent-line-function and "font-lock-keywords" (which isn't a function)". This is from my point of view non-sensical since so many of the `widen' calls are in low level functions called from "everywhere". 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? 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. How about exploring this possibility? > > Do we even understand well enough what are > > the problems in CC Mode that get in the way? > Who do you think is most qualified to study that issue? We'd probably > have to convince Alan to do that as well, unfortunately. Believe it or not, I am in favour of CC Mode working in an MMM mode. > I have a rough understanding of the issue, but since I haven't reached a > working state, I don't know how many pitfalls there are left. Neither do I. But RMS's "new region" and my "syntax islands" may be a more satisfactory way of resolving them. > > About the only thing spelled out in this discussion was the need not > > to widen. Personally, I think this is not a grave issue, just some > > technical problem that is certainly solvable (you proposed one such > > solution). > Indeed. > > But is that all? > I imagine the process itself might be trickier than expected. Various > primitives use caches that save context information. What is such > primitive to do if the cache contains "beginning of nesting" outside of > the current restriction, and the logic of said primitive says "go to the > beginning of the current function and do such and such"? The answer > isn't obvious to me. Again, looking at RMS's suggested "new region" might help, here. > But it's going to need to be answered anyway, no matter which MMM > approach we choose in the end, I think. [ .... ] > Consolidating the 'widen' calls is simply good engineering, even aside > from making life easier for MMM packages: it's much better to do that in > several well-defined places, instead of having every helper function do > it as well, like python-mode CC Mode do. No, it isn't "simply good engineering" at all. It's a different approach with its pros and cons, just as widening at the immediate place of need is. And "consolidating" is probably the wrong word. The number of `widen's will probably grow, since every conceivable entry point which could possibly call the pertinent primitve needs a `widen'. [ .... ] -- Alan Mackenzie (Nuremberg, Germany).