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: Fri, 1 Dec 2017 22:35:29 +0000 Message-ID: <20171201223529.GG3840@ACM> 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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1512168081 15467 195.159.176.226 (1 Dec 2017 22:41:21 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 1 Dec 2017 22:41:21 +0000 (UTC) User-Agent: Mutt/1.7.2 (2016-11-26) Cc: Tom Tromey , Stefan Monnier , Vitalie Spinu , emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 01 23:41:16 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 1eKtze-0003dn-Vf for ged-emacs-devel@m.gmane.org; Fri, 01 Dec 2017 23:41:15 +0100 Original-Received: from localhost ([::1]:33358 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eKtzm-0000JT-Ca for ged-emacs-devel@m.gmane.org; Fri, 01 Dec 2017 17:41:22 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55498) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eKtze-0000Dl-QE for emacs-devel@gnu.org; Fri, 01 Dec 2017 17:41:16 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eKtzb-0008Db-LU for emacs-devel@gnu.org; Fri, 01 Dec 2017 17:41:14 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:57777 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1eKtzb-0008A9-Bh for emacs-devel@gnu.org; Fri, 01 Dec 2017 17:41:11 -0500 Original-Received: (qmail 39997 invoked by uid 3782); 1 Dec 2017 22:41:07 -0000 Original-Received: from acm.muc.de (p548C7BEF.dip0.t-ipconnect.de [84.140.123.239]) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 01 Dec 2017 23:41:05 +0100 Original-Received: (qmail 13822 invoked by uid 1000); 1 Dec 2017 22:35:29 -0000 Content-Disposition: inline In-Reply-To: <1e542021-e389-cca4-6acd-349efddb2652@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:220599 Archived-At: Hello, Dmitry. On Fri, Dec 01, 2017 at 19:13:27 +0000, Dmitry Gutov wrote: > On 12/1/17 3:49 PM, Alan Mackenzie wrote: > >> Please give an example. > > A low level function which as an essential part of its functionality > > (for example, to make sure point-min isn't within a comment or string) > > widens. > See Stefan and I's responses. Including an example of a shim that > wouldn't require you to change your code too much. A shim? Yuck! My idea is an MMM that doesn't require any such shims. 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. > But first and foremost, CC Mode probably doesn't need to worry about > complying with this guideline (yet). In my experience, it doesn't work > well in multi-mode context for reasons other than it calling widen. So > worrying about this change in protocol might be premature. You mean, it would be better to wait until this protocol is firmly established before arguing against it? I'm guessing that the main reason CC Mode doesn't work well in MMM is the contention between CC Mode's narrowing and MMM's narrowing. (This is the example you asked for earlier on.) > >> To rephrase, don't widen in indent-line-function or > >> beginning-of-defun-function. > > This is an intolerable restriction. The low level function mentioned > > above cannot, should not, must not know whether it's being called > > (indirectly) from indent-line-function or b-o-d-function. It will have > > to widen in all cases or none. Therefore there will be failures whilst > > being called either from one of the two noted functions or from > > elsewhere. > See that shim in the other email. The shim doesn't help. It's still horribly ugly. > > 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. > > The multi-mode mechanism should be designed to be usable with any major > > mode. There's nothing particularly hard about supporting CC Mode in a > > well designed multi-mode scheme. > It's harder than supporting Ruby, CSS and JS modes, that I can tell you > for sure. For one thing, the extra caches CC Mode uses have given me > multiple "argument out of bounds" errors when used with narrowing. There's your example for contention between major modes' narrowing and MMM's narrowing. If you didn't narrow, CC Mode would behave properly. > 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. > Some of them miss that responsibility (or else I wouldn't get those > kind of errors). It is the multiple-mode code that is responsible for not getting these errors. At least it should be. > That tells me that moving (widen) call to some higher level is > generally a good idea, but you can disagree. > 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. > 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. > > We need better tools. I have already proposed and offered to implement > > such tools. > It was much more complex, nowhere near even a proof of concept, and > doesn't seem to move anywhere, so far. 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". I'm still prepared to implement the "islands" proposal, which would allow a better MMM mode than one based on narrowing, but ONLY if I get some assurance from John, Eli, or even Stefan himself beforehand that the implementation is, in principle, going to be incorporated into Emacs. That the only thing which would stop that would be solid technical reasons. > The change we're discussing is much smaller and pretty much implemented. 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. > And again, there's no reason why they couldn't coexist. The "pollution" mentioned above would make it more difficult. If the new code you're proposing is incorporated into Emacs, it will acquire some momentum, making it difficult to introduce a better solution. -- Alan Mackenzie (Nuremberg, Germany).