emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: font-lock-syntactic-keywords obsolet?


From: Alan Mackenzie
Subject: Re: font-lock-syntactic-keywords obsolet?
Date: Tue, 21 Jun 2016 21:05:17 +0000
User-agent: Mutt/1.5.24 (2015-08-30)

Hello, Dmitry.

On Tue, Jun 21, 2016 at 07:09:56PM +0300, Dmitry Gutov wrote:
> 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.

And each of these ways is equally valid.  Some will be better in some
situations, others in other situations.  What I object to is you trying
to dictate to the Emacs community that they are only to be allowed to
handle syntax-table text properties in your favoured manner.

> > 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.

This isn't true.  One such statement you've made is this:

> ....., 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.

There is, at the very least an implication there, that you consider
"syntax-ppss users" in some way privileged, in that other Emacs
developers must constrain their development strategies to fit in with
the desires and defficiencies of these "syntax-ppss users".

I say that it is up to the "syntax-ppss users" to keep their software
compatible with Emacs, not the other way around.  They have no right to
impose constraints on other developers, certainly not on how they will
manipulate syntax-table text properties.

[ .... ]

> 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, ...

There are none.  The performance problems in CC Mode arise from its
insistence on highly accurate fontification.

> ..., 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.

Other bits of Emacs are welcome to use solutions developed in CC Mode
where appropriate.  I'm not sure how you imagine that implementing
something in CC Mode somehow "ignores the needs of the rest of the
modes".  They're separate modes.

[ .... ]

>  > ...
> > 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?), ....

No, it doesn't.  It's technical discussion leading to greater
understanding on both sides.

-- 
Alan Mackenzie (Nuremberg, Germany).



reply via email to

[Prev in Thread] Current Thread [Next in Thread]