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 18:12:18 +0000 Message-ID: <20160620181218.GC2192@acm.fritz.box> References: <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> <20160620152535.GB2192@acm.fritz.box> <076b7311-ad16-4913-b0ec-fc73ea4550a1@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1466446364 16263 80.91.229.3 (20 Jun 2016 18:12:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 20 Jun 2016 18:12:44 +0000 (UTC) Cc: emacs-devel@gnu.org, Noam Postavsky To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jun 20 20:12:35 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 1bF3gK-00072K-4B for ged-emacs-devel@m.gmane.org; Mon, 20 Jun 2016 20:12:20 +0200 Original-Received: from localhost ([::1]:45486 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bF3gJ-000202-BQ for ged-emacs-devel@m.gmane.org; Mon, 20 Jun 2016 14:12:19 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36090) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bF3gC-0001zi-TW for emacs-devel@gnu.org; Mon, 20 Jun 2016 14:12:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bF3g8-0001uj-LS for emacs-devel@gnu.org; Mon, 20 Jun 2016 14:12:11 -0400 Original-Received: from mail.muc.de ([193.149.48.3]:23757) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bF3g8-0001uU-9W for emacs-devel@gnu.org; Mon, 20 Jun 2016 14:12:08 -0400 Original-Received: (qmail 5216 invoked by uid 3782); 20 Jun 2016 18:12:05 -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 20:12:04 +0200 Original-Received: (qmail 12730 invoked by uid 1000); 20 Jun 2016 18:12:18 -0000 Content-Disposition: inline In-Reply-To: <076b7311-ad16-4913-b0ec-fc73ea4550a1@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:204602 Archived-At: Hello, Dmitry. On Mon, Jun 20, 2016 at 07:45:06PM +0300, Dmitry Gutov wrote: > On 06/20/2016 06:25 PM, Alan Mackenzie wrote: [ .... ] > > 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. > Emacs low-level code runs quite a few hooks already, which are > implemented in Lisp. You'll also note that the whole Lisp runtime is > called from low-level code. You're evading the point. There's a difference between a well designed interface from low to high (of which there are many in Emacs) and "oh, in this circumstance we might not have syntax table properties current. Tell you what, we'll bung a call to syntax-propertize into the lowest level of the syntax routines, that will surely work most of the time". > > 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. > I wouldn't be in that discussion (or the ones like it) if you just > stayed inside CC Mode and didn't try to push new abstractions, poorly > designed and duplicating what syntax.el already does, into Emacs core. Don't be so cheeky. I'm part of the Emacs team and pushing abstractions, new or otherwise, is one of the things I do. Pointing out that syntax.el is just one of several ways of doing what it does is also something I do; somebody's got to do it, after all. [ .... ] > >> 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. > I believe I explained the problem quite clearly. But if you're asking > for a test case for CC Mode, I don't care for it. It's worth noting you labour under some misconceptions as to what CC Mode does and how it does it. > This discussion is about general facilities, after all. Yes. > >> 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. > ruby-mode, for instance. And, like already pointed out, any language > where (these requirements are sufficient, but not all necessary): > - Double-quoted strings are allowed to span multiple lines. > - Syntax is complex enough that we need to use the syntax-table property. > - Whether a character gets a syntax-property applied, depends on whether > it's inside a string or comment, among other things. All of these 3 criteria apply to C++ Mode, yet there's no need for lazy syntax-table propertification there. Another question for you. Under the aforementioned laziness, how and when do syntax-table properties get modified after a buffer change when these s-t properties are _above_ the position of the change in the buffer? > >> 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. > Why don't you do us all a favor and educate yourself about other > languages and language modes before arguing that > before/after-change-functions can be a general solution as-is? I can argue that because they're clean, well understood abstractions. And I do argue that b/a-c-f are a good way of manipulating s-t properties when these properties are "local". > > The point here is that, mostly, strings don't require s-t text > > properties. > Some don't, some do. Heredoc strings do. > But text outside of strings often does need text properties. And their > application depends on whether given text is inside a string. Yes. > >>> 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? > On syntax-ppss. Participating in discussions about a subject is usually > a good reason to educate themselves about it. For most people, at least. Oh, I'm pretty "educated" about syntax-ppss, thank you very much - educated enough to submit bug reports about it. But I was hoping you could tell me something more about non-"local" s-t 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. > Non-locality is one of the obvious reasons for syntax-propertize's > design, the way that syntax-table application is performed lazily. And it's a good reason not to use syntax-propertize when all s-t properties are, in fact "local", and it is desirable for these properties to be amended instantly on buffer changes. [ .... ] -- Alan Mackenzie (Nuremberg, Germany).