emacs-devel
[Top][All Lists]
Advanced

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

Re: Bug #25608 and the comment-cache branch


From: Dmitry Gutov
Subject: Re: Bug #25608 and the comment-cache branch
Date: Tue, 7 Feb 2017 03:42:50 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.0

Hey Alan,

On 06.02.2017 21:24, Alan Mackenzie wrote:

The essence of comment-cache is scanning comments only in the forward
direction.  This is impractical without a good cache.  The syntax-ppss
cache is wholly inadequate here (and would be even if it worked in the
general case).

How come the "alternative patch" works well, then? The only bugs you've outlined so far are related to narrowing and syntax table change, but not any static complex syntactic situations, which is where I would expect scanning direction to have an impact.

There's no sign of syntax-ppss being fixed.  Bug #22983 has been open
for almost a year, and despite repeated requests from me, there has been
no movement on it.

You didn't show any enthusiasm about the initial proposed fix, which was rather simple. Now we've had more discussions, and the bar for a solution has been raised. I'm thinking about it again. Let's not give up.

Anyways, there are other problems with the "alternative patch".  It
doesn't clear it's caches when syntax-table properties are applied to or
removed from a buffer.  It doesn't clear its caches when a "literal
relevant" change is made to the current syntax table, or a different
syntax-table is made current.

Tracking changes inside a syntax table is possible (at the expense of some performance, as usual), but kinda pointless, I think. Most issues related to that, if they ever come up, could be answered with "don't do that".

Tracking the used syntax table is also a problem which we need to solve for syntax-ppss. A good design could handle it and narrowing together.

comment-cache handles these situations
correctly - that's where its perceived complexity scores.

And it does that in a pretty inflexible way.

comment-cache has rewriten backward_comment entirely, hence the
troublesome merge.  It's no more difficult for maintainers than the
current version of Emacs.

But surely it is more complex, with cache handling logic.

They shouldn't drift apart at all.  But drifting apart is no worse a
problem than a single cache being wrong.

Yes, it is worse. You have more code to debug. And comment-cache adds quite a bit of code.

Arguing for complete abandonment is not constructive criticism.

When an alternative approach is recommended, yes, it is.

I'm not saying the "alternative patch" couldn't be enhanced to do these
things properly, but it would then no longer be a 20-line patch.

I think it would be. The enhancements you're referring to will most likely be implemented on the Lisp level, and they are needed anyway.

So the "speed up forward-comment" patch would still come out to 20 lines.

It would also likely be much slower.
I wouldn't be so sure. A syntax table comparison, for instance, would be pretty cheap compared to what syntax-ppss does already.



reply via email to

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