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: Fri, 1 Dec 2017 23:24:28 +0000 Message-ID: <4a94ec5c-efdd-50f1-ff4d-277f5f45c2df@yandex.ru> References: <20171129233237.27462.23351@vcs0.savannah.gnu.org> <20171129233238.504B5204F1@vcs0.savannah.gnu.org> <5d668ce5-1482-a3d4-c01b-7d996a532567@yandex.ru> <20171130214621.GA22157@ACM> <27985594-3bb4-ce88-8928-2ccfeac13eae@yandex.ru> <20171201154913.GB3840@ACM> <1e542021-e389-cca4-6acd-349efddb2652@yandex.ru> <20171201223529.GG3840@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 1512170692 14626 195.159.176.226 (1 Dec 2017 23:24:52 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 1 Dec 2017 23:24:52 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101 Thunderbird/57.0 Cc: Tom Tromey , Stefan Monnier , Vitalie Spinu , emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Dec 02 00:24: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 1eKufn-0003Um-SO for ged-emacs-devel@m.gmane.org; Sat, 02 Dec 2017 00:24:48 +0100 Original-Received: from localhost ([::1]:33455 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eKufu-0007Hv-VD for ged-emacs-devel@m.gmane.org; Fri, 01 Dec 2017 18:24:54 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44377) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eKufd-0007Hn-Gd for emacs-devel@gnu.org; Fri, 01 Dec 2017 18:24:39 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eKufa-00042A-8y for emacs-devel@gnu.org; Fri, 01 Dec 2017 18:24:37 -0500 Original-Received: from mail-wr0-x241.google.com ([2a00:1450:400c:c0c::241]:43407) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eKufZ-00041k-Uh for emacs-devel@gnu.org; Fri, 01 Dec 2017 18:24:34 -0500 Original-Received: by mail-wr0-x241.google.com with SMTP id z34so11663200wrz.10 for ; Fri, 01 Dec 2017 15:24:33 -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=OSc93MghFofzDf/TuETK1a+p+514hh3sqsLxI1HidQg=; b=DWmGmDOYCkeNqZ3qmYkM6Qia+doJvlVw/J6pKog3ADDqIKrOJO9XxQGqr4JdyudcpS WqjS70rjd2xcrp0UYR97mKjDNDbcczygp6wMnci4+AUTb6FxxC5cfWNrjEBeM3Y1qMaI 6ANDm559hFeZuuMTGZJGMUMBABKfexv54WdkxQ4qK19UzlBzHjwXQHAjT4eTrqNkt3x8 qI9shTjmlTk6+V575i/MbRWuHmGDA5V2zkVz3Be4nxYEU73kS5ttmK3wIY8TzQuxCK1t +WC9XV+jTr2dv0ipgNIgPrZoYDZDQBJHqRKVx5BThaoOk+jiSRwsdpRLdA/EErNwpYyK CVxw== 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=OSc93MghFofzDf/TuETK1a+p+514hh3sqsLxI1HidQg=; b=MnTzKFiikQ8JwnEqYq9ekT9zwgwdfKfY2+iRveFQFlc8H4u7CLdaPEJv1wNtR9D7sp rodQs9UrUWHBoY7X/f7u9wB3fiBXotUw3hW1k1c/5qhfjrueD78vIFlWcnSBgcYPoxD+ Io8OX0UTVTrPEzqWzLK423udAGEIvQ80Dr99VrNGFFBGwxmPb4THq0HUoQ0CuQnRbmZj MzSSbp2K9zIJ4aD+1cyG0ag+GliwOBkq14WT8ANmitdMKdWHVkWMB/n5fUW+9NoaN40n F5Fce37umoAB+Ti3SkuOicMd7n/l/eoFKtgqIAhGXs9ehbHE4mGSyE0bAj+XQMvEEUXv 4SZQ== X-Gm-Message-State: AJaThX60+mXzAugnCOLtZE14AMAAx3waQYdB2217VGV8dRqwHip1sWoX dlxsQ8xj9IoQA1KW4nKrQKw= X-Google-Smtp-Source: AGs4zMZnMAxNjgyY2k2pQJxI0xaijmrHQBdplo9cA5OyYM+XjFAFMX/xId1ReqihjqgNTyAo5/QMeQ== X-Received: by 10.223.150.68 with SMTP id c4mr6556128wra.255.1512170672708; Fri, 01 Dec 2017 15:24:32 -0800 (PST) Original-Received: from [192.168.1.38] (89-160-235-67.du.xdsl.is. [89.160.235.67]) by smtp.googlemail.com with ESMTPSA id r71sm2250837wmd.20.2017.12.01.15.24.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Dec 2017 15:24:31 -0800 (PST) In-Reply-To: <20171201223529.GG3840@ACM> Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:400c:c0c::241 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:220601 Archived-At: On 12/1/17 10:35 PM, Alan Mackenzie wrote: > A shim? Yuck! My idea is an MMM that doesn't require any such shims.M Ideas have the tendency to be more ideal than their eventual implementations. > Major modes should not be "polluted" to adapt to one particular MMM. It > solidifies that MMM, making it difficult to change to a better one. It's not "one particular MMM". All existing MMM packages use narrowing. And it's not just to adapt. Calling `widen' in fewer places just makes sense from engineering point of view. > You mean, it would be better to wait until this protocol is firmly > established before arguing against it? The proposal isn't going to hurt you in any significant way. That's what I mean. > The shim doesn't help. It's still horribly ugly. Calling widen from dozens of functions in a package is ugly. A shim just helps you avoid rearchitecting it. >>> Indeed it can, and it must. A super-mode thus may not "reserve" >>> narrowing for its own purposes to the exclusion of other uses. > >> Right. > > Glad we agree upon this. However that contradicts your proposal that > anything a beginning-of-defun-function calls can't use narrowing and > widening. Nope. > There's your example for contention between major modes' narrowing and > MMM's narrowing. Not sure what you mean by that. It's already apparent that some major modes will have to change to adapt to this proposal. Isn't it? > If you didn't narrow, CC Mode would behave properly. Without narrowing it gives us wrong syntax highlighting and indentation. >> So these are my takeaways: > >> 1) The "low-level primitives" in CC Mode do not widen consistently. > > They widen when they need to, which is not always. I don't think I'd get this error if they did. But hmm, I think this error was in fontification code, actually. mmm-mode, of course, narrows to each individual hunk before using the corresponding mode's font-lock-keywords. >> 2) The other errors should be solvable, but they require a separate >> investigation, which nobody has found the time and energy to do so far, >> over many years. So maybe it's not so necessary. > > I would like AWK Mode to work inside shell-script-mode, since short AWK > scripts are so often embedded in scripts. When we're talking about short snippets, sometimes it's easier to use e.g. js-mode instead. That's what I've been advising for C code, too. But if complex syntax in AWK happens often, and CC Mode has good support for it, maybe supporting it is a worthy endeavor. >> 3) The solution to the other problems is most likely orthogonal to the >> current discussion. Allowing multi-mode packages to use narrowing >> certainly shouldn't hurt. > > Of course not. It's prohibiting major modes from using > narrowing/widening that is objectionable. Sometimes code has to follow certain protocols. That's nothing new. > Investing the time and energy on an implementation was too risky. In > practice, Stefan has veto power over what goes into the syntax area, and > I've been at the sharp end of that veto once too often (the rejection of > my "comment-cache" code which solved the problem of open parens at > column zero in comments). In the last exchange about the "syntactic > islands" concept, Stefan showed little enthusiasm for it: there was no > "OK, implement it and we'll see what we can do with it", no > encouragement whatsoever. There was no discussion of major topics, such > as the possibilities it would open up, or any plans to use it. Mainly, > the talk was about minor aspects of the proposal, at one point > degenerating into a squabble about the use of the word "island". No discussion, really? I've pointed out the major difficulties I could think of, which is normally the area that should get the most attention during the discussion of a technical proposal. The fact that few people seemed interested... well, that happens. There's no use complaining that a proposal is unpopular. I've had a few over the years myself. Please feel free to push for it, of course. > But it has negative implications. It will only work with major modes > specially adapted for it, and it imposes severe restrictions on those > major modes. I think it needs those modes to be "polluted" with MMM > code. We already have several major modes adhering to it, and for them the change was trivial. As far as major modes are concerned, web programming is the most important area, so CC Mode support is less urgent anyway. > If the new code you're proposing is incorporated into Emacs, it will > acquire some momentum, making it difficult to introduce a better > solution. Like mentioned, for most major mode the changes are trivial, if at all needed.