From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls Date: Mon, 4 Dec 2017 00:37:51 +0000 Message-ID: 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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1512347925 16690 195.159.176.226 (4 Dec 2017 00:38:45 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 4 Dec 2017 00:38:45 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101 Thunderbird/57.0 Cc: Eli Zaretskii , tom@tromey.com, monnier@iro.umontreal.ca, spinuvit@gmail.com, emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Dec 04 01:38:39 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 1eLemM-0003xP-W4 for ged-emacs-devel@m.gmane.org; Mon, 04 Dec 2017 01:38:39 +0100 Original-Received: from localhost ([::1]:40648 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eLemR-0007Vk-3F for ged-emacs-devel@m.gmane.org; Sun, 03 Dec 2017 19:38:43 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58696) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eLelg-0007Vd-Va for emacs-devel@gnu.org; Sun, 03 Dec 2017 19:37:58 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eLelf-00017x-Nc for emacs-devel@gnu.org; Sun, 03 Dec 2017 19:37:56 -0500 Original-Received: from mail-lf0-x242.google.com ([2a00:1450:4010:c07::242]:36999) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eLelf-00017f-AY; Sun, 03 Dec 2017 19:37:55 -0500 Original-Received: by mail-lf0-x242.google.com with SMTP id a12so17266262lfe.4; Sun, 03 Dec 2017 16:37:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=1PR5ZyU7RLY5vZvrRGGuEicDrtdfRlsbcCshE/c/Skc=; b=ZSnxo22FlJcfOwg9L1HBTtX+udK3XrrzPVfyMoiLOA/lCmO8xR26saOZLtF8ZJ+bxy 7Aqfgk/pnfgPzLLDOAOsx3UTP8gHvCaCj8whoyz76G/MZn1ZvI3pHqZfEdwG1UR1rYw1 DvLHOPO7xyiJXLB/TaI97BcRP9RgVUDFrYjpsblHtyvHAPVUe7lU2RREQp/9A9IW00S+ 9Voee5iE8ieRjtWY2CYcHr7tEhnnxDiLPmk5zoh7wsw5URAHyDFWSLHgeOvyOKiYwVPF 86yOSxfggyA2ZPuFKJOtGD/T92NqLMd16aHsO1SoydC2fCDwVBTHj7+OYX8f8h9JfAZj +eug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=1PR5ZyU7RLY5vZvrRGGuEicDrtdfRlsbcCshE/c/Skc=; b=sa7anGT4D9cRpe8tjCVdaKy+WzCfwYtrBkw+W9o9NlkUqhrkxIK+Usdzk4V+T8EfiI rHjwixpMAarNaM5l8vvzGCntXpYSH2+qbTDKaTU6gHL9Ri5JxcGxaMVEId/sToHXKi1K /2HsJ2WMOv2sFjlMEB8WCMhbISvvpuJ54BptAcW+Vc5WgCG2gZOst9kHvgOpqNAgPDNA iADQb3+2iPzoIXfc9FUyx0laaf/yUsHEd/0WFQ30ACQR4EDrajuj31vDdp42ybY5FJYd WtQ/KYkXRr5XhaG9isANfBldH/Pv9RAgj971+ykVXrAHaPSXuO93oH18rvzDZEugyBmO Mo3Q== X-Gm-Message-State: AJaThX63e/oTJtorfwWMMpoOun5yVtEDRAqpbJQEiBFzH5VT8mMEypF5 TI92CW8PeQWa+TTWbPyDf60UhqCD X-Google-Smtp-Source: AGs4zMbZ1sCjghNSgwosMNiKnLa4NTtX+WfYdj+v8CPVnfJqHHdZe/B23yIEZmlqzs/RUNINlNzqFQ== X-Received: by 10.46.85.208 with SMTP id g77mr7860764lje.114.1512347873341; Sun, 03 Dec 2017 16:37:53 -0800 (PST) Original-Received: from ?IPv6:2a02:a311:413e:e480::4? ([2a02:a311:413e:e480::4]) by smtp.googlemail.com with ESMTPSA id k188sm140469lfg.79.2017.12.03.16.37.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 03 Dec 2017 16:37:52 -0800 (PST) In-Reply-To: <20171203185946.GC5531@ACM> Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4010:c07::242 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:220674 Archived-At: On 12/3/17 6:59 PM, Alan Mackenzie wrote: > Please read my signature, sometime. I sincerely apologize. Fly out to Germany, of course. > 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. Erm, mmm-mode is 17 years old, originally written by a graduate student to help with literate programming (AFAIK). Did you mean they should have asked back then? And in the intervening years, several other packages took a similar approach. And if you mean that I should have asked specifically, I did bring up it in a discussion... a year ago or so. And no realistic and complete counter-proposal came up, as far as I'm concerned. > 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've never worked on a mixed-mode package, though. So yes, I personally have a reason to assume that I have a better knowledge of the problem area. But I never said that CC Mode must support it. > 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. Still, that sounds manageable. And there's no hurry at all, as far as I'm concerned. > You > categorise the injunction against widening as "only applying to > indent-line-function and "font-lock-keywords" (which isn't a function)". I think you know what I meant anyway. > 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? Vitalie proposed something like that years ago, and we asked for help with the C code. Nobody turned up, including yourself (and I asked directly). Anyway, I don't see how it would be qualitatively better. The problem of being able to function in a restricted area of a buffer will still be there. > 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? Please go ahead and explore. I've done my part with my proposal (which was intentionally small and thus required small changes everywhere but CC Mode). > Believe it or not, I am in favour of CC Mode working in an MMM mode. You just don't want the protocol we are proposing. Did you participate in the prog-indentation-context discussion when it was proposed, by the way? >> 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. May be, or may not. We'd need to see the code. By the way, again, you can add a "new region" function exclusively to CC Mode, and use it in the indentation function. It's trivial to implement, and will look awfully like the shim I proposed. >> 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. See above. But no, the problem I imagined (not 100% sure if it's real) won't be solved by "hard narrowing". >> 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'. No more than there are interactive functions. A lot of them have to do that anyway already. And then, you could also have helpers that aren't used in indentation code. There are several ways to skin that cat.