From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: font-lock-syntactic-keywords obsolet? Date: Mon, 20 Jun 2016 15:25:36 +0000 Message-ID: <20160620152535.GB2192@acm.fritz.box> References: <20160619145934.GC5875@acm.fritz.box> <6bc7b3bc-ddb7-c041-9f68-f8b5faeca63b@yandex.ru> <20160619151836.GE5875@acm.fritz.box> <1d4c62e6-905b-4a51-28b8-e68169fb3269@yandex.ru> <20160619153455.GG5875@acm.fritz.box> <11c988f0-94c0-40dd-b9cd-5a5e27028b63@yandex.ru> <20160619171531.GH5875@acm.fritz.box> <751427e7-f305-7790-99f5-dea230d8e6c4@yandex.ru> <20160620105850.GB3166@acm.fritz.box> <23d7473e-50da-b6dc-17a7-1fec4aad6bfa@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1466436973 23618 80.91.229.3 (20 Jun 2016 15:36:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 20 Jun 2016 15:36:13 +0000 (UTC) Cc: Noam Postavsky , emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jun 20 17:36:05 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1bF1F6-0003Cq-7l for ged-emacs-devel@m.gmane.org; Mon, 20 Jun 2016 17:36:04 +0200 Original-Received: from localhost ([::1]:44415 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bF1F5-0006BO-6f for ged-emacs-devel@m.gmane.org; Mon, 20 Jun 2016 11:36:03 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42966) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bF14r-0002mW-61 for emacs-devel@gnu.org; Mon, 20 Jun 2016 11:25:31 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bF14o-0007EK-Gi for emacs-devel@gnu.org; Mon, 20 Jun 2016 11:25:29 -0400 Original-Received: from mail.muc.de ([193.149.48.3]:57383) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bF14o-0007E1-6N for emacs-devel@gnu.org; Mon, 20 Jun 2016 11:25:26 -0400 Original-Received: (qmail 64297 invoked by uid 3782); 20 Jun 2016 15:25:24 -0000 Original-Received: from acm.muc.de (p548C7218.dip0.t-ipconnect.de [84.140.114.24]) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 20 Jun 2016 17:25:22 +0200 Original-Received: (qmail 2413 invoked by uid 1000); 20 Jun 2016 15:25:36 -0000 Content-Disposition: inline In-Reply-To: <23d7473e-50da-b6dc-17a7-1fec4aad6bfa@yandex.ru> User-Agent: Mutt/1.5.24 (2015-08-30) 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 X-Received-From: 193.149.48.3 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:204595 Archived-At: Hello, Dmitry. On Mon, Jun 20, 2016 at 03:15:34PM +0300, Dmitry Gutov wrote: > Hi Alan, > On 06/20/2016 01:58 PM, Alan Mackenzie wrote: > > You seem to be advocating that CC Mode should lose its deterministic text > > property handling and replace it by a "hope it's OK" non-deterministic > > handling. You can understand me not wanting to do this. > You seem to be unable to understand any determinism semantics that are > slightly more complex than the ones you are working with now. I hold simplicity to be an admirable thing to aim for. KISS. > >> b) In addition to that, scan_lists now applies syntax-table properties > >> by calling syntax-propertize-function > > Yuck! That's the sort of ugly workaround that becomes needed when things > > aren't properly thought through from the beginning. In a proper design, > > the low level routines in syntax.c wouldn't even know about s-p-function, > > and nor should they. > The way you choose to refer to this simple and sensible design as "ugly > workaround" is incredibly annoying. Please keep that in mind when I stop > replying. Since when has ad hoc calling of high level code from primitives been "simple and sensible design"? You'll note that the CC Mode way simply doesn't need this. And I say to you quite openly, the continual niggling and nagging I've been getting over the past months and years to adapt CC Mode to an way of dealing with text properties I hold to be inferior has got tiring and draining. I'd be most obliged if you would stop doing this. > >> The only way we could, without adding additional abstraction, is by > >> agreeing that all buffers must be syntax-propertized in their entirety > >> after before/after-change-functions run. And that is just too damn wasteful. > > How is it wasteful? > Imagine a big file. You open it and start editing near the beginning. > With s-p-f, Emacs only has to syntax-propertize it in a limited area > near the beginning, the rest of the file is completely ignored. > If you jump to the end, the whole file is syntax-propertized once, and > then, again, as you keep working, only a small area gets re-propertized > as long as you don't jump far away. > Without s-p-f, you have to keep the whole file up-to-date at all times, .... True, > and that means going over its entirety when the user edits something > near the file's beginning that affects the parse state of the rest of > the file, e.g. opening or closing a string, or a block comment. But that's false. The text properties get applied on the entire buffer when it is first opened, and from then on all manipulations are "local". A change of a s-t property near BOB, say deleting a template opening delimiter has no effect on the text beyond the next semicolon. If things had been as you suggest, quite likely I would have come up with something a bit like syntax-propertize-function, though maybe not very much like it. > You could try adding kludges to that, but ultimately, if you want the > file to always be up-to-date in its entirety, eagerly, you're forced to > make many operations slower than they have to be. If you still think this is true, and can demonstrate this with a test case, I will have a look at it and attempt to fix it. > > If the syntax-table properties are all "local", it's > > actually an efficient way to do things. > In CC Mode you have it easier: strings are limited to one line, or their > extents are obvious by escaped newlines, and an unclosed block comment > will get closed at the end of the next block comment. > Even so, you have raw strings now, and with them you're forced to make a > choice between being fast and being correct. We'll see. > The shortcuts available to CC Mode aren't something all language modes > can use, so syntax-propertization through before/after-change-functions > cannot become the standard. s-p-f can, on the other hand, and already is. I'd be interested to hear of some Mode where such shortcuts, as you call them, aren't available. syntax-propertize-function is just one way of handling syntax-table text properties, and it probably uses before/after-change-functions. If it doesn't, then there will be arbitrary periods of time in which the state of the s-t properties is undefined. This isn't simple, and I hold it to be non-good. > > You simply have to extend the (beg end) region to that which might > > contain pertinent characters, remove s-t properties in a > > before-change function, and apply them in an after-change function. > Imagine a language with multiline strings (you can call it "Ruby", or, > maybe, "Emacs Lisp"), and a big file that contains at least one string > per every ten lines. The user goes to the first string and removes its > closing delimiter. > What's your after-change-function going to do? Whatever is needed. Sorry, but the question is too vague. Emacs Lisp Mode, as far as I know doesn't have its own a-c-f, so the answer would be "nothing". I don't know Ruby Mode. The point here is that, mostly, strings don't require s-t text properties. > > If the s-t props aren't "local", then maybe the > > syntax-propertize-function approach is a good one. I haven't had any > > reason to think this through. > The zillion email messages on the subject still haven't encouraged you? On non-"local" syntax table text properties? I don't recall seeing any discussion of this, except for the one we're now having. If I've forgotten it, or missed it, you could perhaps point it out to me. > > Somebody (either you or Stefan) opined > > that ALL s-t properties are, in practice, "local". > You're misremembering. It must have been somebody else, then. Are you aware of any non-"local" use of syntax table text properties? -- Alan Mackenzie (Nuremberg, Germany).