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: Mon, 6 Feb 2017 04:09:42 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.0

On 04.02.2017 12:24, Alan Mackenzie wrote:

You want comment-cache to be wholly abandoned.

At least the part that maintains a separate cache. I'm not sure if there's anything else there.

It's not because I enjoy disagreeing with you, though.

And then we should seek the simplest solution that satisfies all of our
requirements.

As simple as possible, but definitely not simpler.  The "solution" you
favour is too simple.  It doesn't work all the time.

I concede it's not ideal. However, I strongly believe "fixing" the narrowing problem in syntax-ppss with take care of this example, *and* will result in lower overall complexity and maintenance burden.

Consider the problems you've had merging master into the comment-cache branch. If there were conflicts, that means the new code touches a changing area, and it will need to be considered and taken care of by the maintainers, probably on an ongoing basis. The AP, on the other hand, still applies cleanly.

"It introduces a second source of truth" seems like a concise summary.

So what?  There are any number of "sources of truth" in Emacs.  If one
of them turns out to be a "source of untruth" we call that a bug, and we
fix it.

One normally adds an alternative source of truth (i.e. a "cache") to fix a significant performance problem, when one really can't do so otherwise.

It seems we agree now that comment-cache's existence can't be justified by performance considerations.

Cache invalidation is a known hard problem in CS, so we generally don't want to have extra caches.

At best, it'll use more memory than it has to.

The thing to do here is measure this extra memory.  I did this back in
spring last year, and the number of extra conses used for the cache was
not inordinately high.  Especially not for a 64-bit machine with several
gigabytes of RAM.

Maybe it's not bad, without a direct link it's hard for me to comment on that now. But "no extra memory usage" would be a better outcome anyway.

I think you're seeing something that's not there.  You're picturing some
imagined process where two alternative ways of storing information have
great difficulty staying together, and somehow, over time, are destined
to drift apart.  Sort of like two national currencies trying to stay
pegged to eachother, or something like that.

I'm picturing weird syntax highlighting/defun navigation/etc behavior that comes and goes seemingly randomly, and which forces us to debug both cache mechanisms to see which one is getting something wrong.

They don't even have to drift far apart functionality-wise, as long as their implementations are largely independent.

That's not how computer programs work.  If those two ways end up
differing, we have a bug, which can be fixed like any other bug.  Heck,
even a single "source of truth" can be buggy, with just as severe
consequences.  We get bugs, we fix them.

And the more sources of truth we have, we more places we might end up having to fix.

Note, in this context, that syntax-ppss is broken (bug #22983) and
doesn't look like getting fixed any time soon, yet the world hasn't come
to an end.

A consistently "wrong" behavior is better than having some standard library functions work "correctly", and some otherwise.

Consider this again: as long as syntax-ppss continues to have problems in the cases you imagine, the caches _will_ diverge in those cases.

Honestly, my head hurts when I start thinking up problem examples, but I'm sure the users and authors of modes that define syntax-propertize-function and/or use syntax-ppss won't like them.

Note that there has been NO constructive criticism of comment-cache.

That's insulting, Alan.

It might be, but I think it's true.  You want comment-cache to be wholly
abandoned.  You are not suggesting ways to make it better.  You haven't
tried it, that I'm aware of.  You haven't looked for flaws, with the
intention of getting them fixed.

You seem to argue that a high-level criticism can't be constructive, and that any good one has to discuss lower-level implementation details.

> Instead you are putting forward
> reasons, not all of them good, for abandoning comment-cache.

Aside from "two sources of truth", the other reason is that we have a much-simpler patch that gives us (or will eventually give) the same benefits.



reply via email to

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