From: Dmitry Gutov <dgutov@yandex.ru>
To: Alan Mackenzie <acm@muc.de>
Cc: emacs-devel@gnu.org, Noam Postavsky <npostavs@users.sourceforge.net>
Subject: Re: font-lock-syntactic-keywords obsolet?
Date: Tue, 21 Jun 2016 19:09:56 +0300 [thread overview]
Message-ID: <2461a96d-d5b0-f2ee-8668-920ddc86f5f5@yandex.ru> (raw)
In-Reply-To: <20160621152653.GC3177@acm.fritz.box>
Hi Alan,
On 06/21/2016 06:26 PM, Alan Mackenzie wrote:
> my insistence that there
> are several strategies which can be adopted for handling syntax-table
> text properties.
This is the kind of vague statement that I've seen a lot, and does not
further the discussion. Yes, there can be lots of approaches to doing
stuff. It's a truism.
> You seem to be of the opposite opinion, that there is
> one single blessed way of doing this handling, and any other way is thus
> the Wrong Thing.
No. Of any statements I've made the only one that sounds close is that
when we're caching syntactic information in a buffer, there must be only
one source of truth, and not multiple. That is from the comment-cache
discussion.
Again, if you insist on continuing using the bare after-change-functions
approach in CC Mode, I'm fine with that, provided you deal with all the
performance-related consequences, and that you don't try to work around
its problems by pushing solutions tailored to CC Mode to the core,
ignoring the needs of the rest of the modes.
> As far as I am aware, there has never been a general discussion on
> emacs-devel about this topic.
Without consultation, meaning nobody asked you? Consider me consulted.
And seeing how well this and related discussions are going, it's quite
likely that the result of that would have been coming up with no new
strategy at all, and giving up in disgust instead.
> One isolated developer developed the
> strategy you like, and he spread it around existing modes as far as he
> could, again, without any consultation that I'm aware of.
The "isolated developer" has been an Emacs maintainer for many years,
and the strategy in question has been in use for many years now, across
many packages. So trying to reduce its current importance to "one
isolated developer" is disingenuous, and rather insulting.
> If that
> discussion had taken place, likely the strategy would be better thought
> out, more widely applicable, and better implemented with less resulting
> bad feeling.
By now, you've had every chance to analyze its current usage, benefits,
drawbacks, and present a decent alternative that does not regress in
important aspects, which I'm sure is possible (everything has space for
improvement).
Instead, we've only seen lots of opinionated statements, complaints
about being forced to switch (this is between you and Stefan, although I
also suspect that it could help deal with a lot of CC Mode's performance
problems, current and future ones), and one flimsy and rather obvious
bug report.
> ...
> You've got a strategy in Ruby Mode which works, and you'll note I've
> never tried to talk you into abandoning that strategy.
That's not true. You've critiqued it a lot (does that not count as
persuading to abandon?), and you've tried to push a new incompatible
facility that would cause problems for syntax-ppss users in the long
run. Or, at least, is very likely to.
next prev parent reply other threads:[~2016-06-21 16:09 UTC|newest]
Thread overview: 95+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-16 10:18 font-lock-syntactic-keywords obsolet? Andreas Röhler
2016-06-17 22:13 ` Stefan Monnier
2016-06-18 7:03 ` Andreas Röhler
2016-06-18 15:07 ` Noam Postavsky
2016-06-18 17:12 ` Alan Mackenzie
2016-06-18 18:13 ` Stefan Monnier
2016-06-18 19:41 ` Noam Postavsky
2016-06-19 7:12 ` Andreas Röhler
2016-06-19 13:21 ` Noam Postavsky
2016-06-19 14:03 ` Andreas Röhler
2016-06-19 14:36 ` Stefan Monnier
2016-06-19 15:12 ` Alan Mackenzie
2016-06-19 15:18 ` Dmitry Gutov
2016-06-19 15:26 ` Alan Mackenzie
2016-06-19 15:52 ` Stefan Monnier
2016-06-19 15:53 ` Dmitry Gutov
2016-06-20 2:58 ` Stefan Monnier
2016-06-20 11:57 ` Alan Mackenzie
2016-06-20 13:37 ` Stefan Monnier
2016-06-20 13:50 ` Dmitry Gutov
2016-06-20 16:00 ` Andreas Röhler
2016-06-20 18:15 ` Dmitry Gutov
2016-06-20 23:33 ` John Wiegley
2016-06-20 18:55 ` Alan Mackenzie
2016-06-20 20:22 ` Andreas Röhler
2016-06-19 15:27 ` Andreas Röhler
2016-06-19 15:51 ` Stefan Monnier
2016-06-19 12:31 ` Dmitry Gutov
2016-06-19 13:31 ` Alan Mackenzie
2016-06-19 13:48 ` Dmitry Gutov
2016-06-19 14:59 ` Alan Mackenzie
2016-06-19 15:07 ` Dmitry Gutov
2016-06-19 15:18 ` Alan Mackenzie
2016-06-19 15:22 ` Dmitry Gutov
2016-06-19 15:34 ` Alan Mackenzie
2016-06-19 15:50 ` Dmitry Gutov
2016-06-19 17:15 ` Alan Mackenzie
2016-06-19 17:55 ` Dmitry Gutov
2016-06-19 22:20 ` Dmitry Gutov
2016-06-20 10:22 ` Alan Mackenzie
2016-06-20 11:50 ` Dmitry Gutov
2016-06-20 14:50 ` Alan Mackenzie
2016-06-20 15:02 ` Dmitry Gutov
2016-06-20 13:39 ` Stefan Monnier
2016-06-20 10:58 ` Alan Mackenzie
2016-06-20 11:12 ` Andreas Röhler
2016-06-20 12:15 ` Dmitry Gutov
2016-06-20 14:52 ` Noam Postavsky
2016-06-20 15:57 ` Dmitry Gutov
2016-06-20 17:23 ` Noam Postavsky
2016-06-20 18:58 ` Dmitry Gutov
2016-06-20 15:25 ` Alan Mackenzie
2016-06-20 16:45 ` Dmitry Gutov
2016-06-20 18:12 ` Alan Mackenzie
2016-06-20 19:15 ` Dmitry Gutov
2016-06-20 20:08 ` Alan Mackenzie
2016-06-20 20:32 ` Dmitry Gutov
2016-06-21 14:40 ` Alan Mackenzie
2016-06-21 21:06 ` Dmitry Gutov
2016-06-21 23:50 ` Dmitry Gutov
2016-06-23 16:30 ` Alan Mackenzie
2016-06-27 11:48 ` Alan Mackenzie
2016-06-29 0:30 ` Dmitry Gutov
2016-06-30 9:52 ` Alan Mackenzie
2016-07-10 2:01 ` Dmitry Gutov
2016-07-10 22:11 ` Alan Mackenzie
2016-07-11 0:06 ` Dmitry Gutov
2016-07-11 17:20 ` Alan Mackenzie
2016-07-11 22:44 ` Dmitry Gutov
2016-06-20 22:45 ` John Wiegley
2016-06-20 23:30 ` Dmitry Gutov
2016-06-20 23:56 ` John Wiegley
2016-06-21 0:26 ` John Wiegley
2016-06-21 15:26 ` Alan Mackenzie
2016-06-21 16:09 ` Dmitry Gutov [this message]
2016-06-21 18:34 ` Andreas Röhler
2016-06-21 18:42 ` John Wiegley
2016-06-21 18:52 ` Eli Zaretskii
2016-06-27 11:50 ` Andreas Röhler
2016-06-21 19:23 ` Andreas Röhler
2016-06-21 18:49 ` Eli Zaretskii
2016-06-21 21:05 ` Alan Mackenzie
2016-06-21 21:17 ` Dmitry Gutov
2016-06-21 16:28 ` Dmitry Gutov
2016-06-20 0:06 ` Stefan Monnier
2016-06-20 11:03 ` Alan Mackenzie
2016-06-20 13:53 ` Stefan Monnier
2016-06-20 4:33 ` Stefan Monnier
2016-06-20 5:05 ` John Wiegley
2016-06-19 23:59 ` Stefan Monnier
2016-06-20 3:14 ` Stefan Monnier
2016-06-20 3:20 ` Dmitry Gutov
2016-06-20 3:47 ` Stefan Monnier
2016-06-20 6:40 ` Andreas Röhler
2016-06-20 3:08 ` Stefan Monnier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2461a96d-d5b0-f2ee-8668-920ddc86f5f5@yandex.ru \
--to=dgutov@yandex.ru \
--cc=acm@muc.de \
--cc=emacs-devel@gnu.org \
--cc=npostavs@users.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).