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 22:26:50 +0000 Message-ID: <20171203222650.GB3907@ACM> References: <27985594-3bb4-ce88-8928-2ccfeac13eae@yandex.ru> <20171201154913.GB3840@ACM> <1e542021-e389-cca4-6acd-349efddb2652@yandex.ru> <20171201223529.GG3840@ACM> <4a94ec5c-efdd-50f1-ff4d-277f5f45c2df@yandex.ru> <20171202202855.GA22133@ACM> <6a612831-a73f-2223-822f-7d594ebdff30@yandex.ru> <20171203145446.GB5531@ACM> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1512340420 28743 195.159.176.226 (3 Dec 2017 22:33:40 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 3 Dec 2017 22:33:40 +0000 (UTC) User-Agent: Mutt/1.7.2 (2016-11-26) Cc: Tom Tromey , Dmitry Gutov , Vitalie Spinu , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Dec 03 23:33:33 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 1eLcpH-0006xz-Bm for ged-emacs-devel@m.gmane.org; Sun, 03 Dec 2017 23:33:31 +0100 Original-Received: from localhost ([::1]:40398 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eLcpM-0000dZ-Gl for ged-emacs-devel@m.gmane.org; Sun, 03 Dec 2017 17:33:36 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60277) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eLcoi-0000dR-62 for emacs-devel@gnu.org; Sun, 03 Dec 2017 17:32:57 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eLcof-0007yj-0Q for emacs-devel@gnu.org; Sun, 03 Dec 2017 17:32:56 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:62844 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1eLcoe-0007yL-LA for emacs-devel@gnu.org; Sun, 03 Dec 2017 17:32:52 -0500 Original-Received: (qmail 80368 invoked by uid 3782); 3 Dec 2017 22:32:51 -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 23:32:49 +0100 Original-Received: (qmail 4952 invoked by uid 1000); 3 Dec 2017 22:26:50 -0000 Content-Disposition: inline In-Reply-To: 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:220668 Archived-At: Hello, Stefan. On Sun, Dec 03, 2017 at 13:40:22 -0500, Stefan Monnier wrote: [ .... ] > > I don't rate restrictions on the use of Emacs primitives to be minor. > I think there's a fundamental misunderstanding abut Dmitry's suggestion > here: his proposal does not restrict the use of any primitive anywhere. You say there's no restriction happening, then go on to detail the restriction that is to be put in place. ;-) > The only thing it does is to make the calling convention of > indent-line-function a bit more precise: instead of not saying anything > about the kind of narrowing that can be in place when that is called, it > specifies that the caller should arrange the narrowing to expose "all" > the code, and so the callee doesn't need to widen (which is useful since > in an MMM context, the sub-mode usually doesn't know how far it should > widen). Which is why I proposed the "syntactic islands", which would allow code to do parse-partial-sexp (or even syntax-ppss). Typically the code does need to know about "distant" chunks. For example if point is after an embedded AWK Mode script in shell-script-mode, C-M-a will need access to the buffer part before the AWK Mode interlude. > The indent-line-functions can still narrow/widen all it wants. > And the callers of indent-line-function also can still widen/narrow all > they want. Just as is the case now, depending on how they narrow/widen > the result may be incorrect. And the novelty here is to provide > a convention that, if followed, should make it more likely that the > result is correct, without the caller and the callee being aware of each > other, because they only care about the shared convention. > > If those common solution are adequate, yes. But it is also critical to > > have the freedom to depart from things like syntax-propertize when they > > are inadequate, or too awkward. syntax-propertize is inadequate for CC > > Mode: > > E.g., in C++ Mode, with > > foo (a < b, c > d); > > we have a constructor foo with one parameter d, of a templated type. The > > characters "<" and ">" have syntax-table text properties giving them > > paren syntaxes and making them match each other. > > Now, mark the characters ", c > d" and kill them with C-w. What we are > > left with is a function call with an integer argument a < b: > > foo (a < b); > > . Something, somewhere has to remove the syntax-table property from > > "<", since it is no longer a template delimiter. > > The syntax-propertize mechanism won't do this, since the place to > > de-propertise is before BEG. > syntax-propertize is no silver bullet, indeed, so it won't do everything > magically for you. But, it can handle the above situation just fine. I don't see that. > In your very specific above example, it will actually be handled > magically simply by virtue of syntax-propertize-wholelines being > included in the default value of syntax-propertize-extend-region-functions. > Now, of course, if you tweak your example so that the < and the > are > not on the same line any more, that magic won't work. But that doesn't > mean you can't make syntax-propertize handle it right. You could for > example solve it with: > (add-hook 'syntax-propertize-extend-region-functions > #'syntax-propertize-multiline nil t) All constructs in CC Mode languages are "multiline". > in your major mode function and > (put-text-property position-of-left-< position-of-right-> > 'syntax-multiline t) > when you find (and put the syntax-table property on) the <...> pair. Why not just put that property on the entire buffer? Or, if syntax-multiline is intended to flag up just one construct, it won't cope well with nested (or overlapping) constructs. > Of course, it's not the only possible way to do it. It's just the way > I solved similar problems in perl-mode and sh-mode. How is that going to help when a closing template delimiter is deleted? > If you're interested in making CC-mode work reliably with > syntax-propertize I'd be *thrilled* to help you do that. > By design, there should be basically nothing syntax-propertize can't handle > (modulo bugs and within the limits of what we can do with syntax-tables > and syntax-table properties, obviously). One problem is the vagueness in the documentation of syntax-propertize-extend-region-functions. Are these functions called in before-change-functions or a-c-functions? Obviously, in my case above, they would be needed in b-c-f, otherwise they wouldn't notice the ">" being killed. But they need to be called in a-c-f too, in case the change is adding "> >", when the code needs to search back to the earlier two "<"s, which now have become "dirty" when they weren't previously. > I have no doubt that the way CC-mode works right now will occasionally > be more efficient than the way syntax-propertize would do it. But I > also have no doubt that the way syntax-propertize would do it will > occasionally by more efficient than the way CC-mode does it right now. syntax-propertize splats all syntax-table properties after a change point, if I understand correctly. That means they must at some point soon be regenerated[*]. This will be expensive in a large buffer. [*] imagine moving point forward to just before a "<" which (along with its matching ">") needs to have paren s-t. properties to allow paren-matching to happen. I can't see what is putting those properties on it, given the ">" could be an arbitrary distance forward. > I strongly doubt that the difference in performance behavior will ever > matter, tho. Several differences in performance that "hardly matter" can add up to something substantial. I recently celebrated a 3.9% increase in fontification performance after deleting some old duplicate code. > Stefan -- Alan Mackenzie (Nuremberg, Germany).