[Top][All Lists]

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

Re: Bug #25608 and the comment-cache branch

From: Alan Mackenzie
Subject: Re: Bug #25608 and the comment-cache branch
Date: Sat, 4 Feb 2017 10:24:10 +0000
User-agent: Mutt/1.7.2 (2016-11-26)

Hello, Dmitry.

On Sat, Feb 04, 2017 at 00:08:41 +0200, Dmitry Gutov wrote:
> On 03.02.2017 19:29, Alan Mackenzie wrote:

> > The objectors do not seem to want compromise - they want comment-cache
> > to be wholly abandoned.

> It's silly to seek a compromise between implementations. Rather, we 
> should discuss hard requirements (with some test cases).

You want comment-cache to be wholly abandoned.

The requirements are simple.  First, and foremost, (forward-comment -1)
must work.  Secondly, it should do so fast, preferably at least as fast
as the current (buggy) implementation.

Here is a test case from months gone by.  Put point-min at the indicated
position, put point at EOL, then do M-: (forward-comment -1).

    char foo[] = "asdf asdf" "asdf"; /* "asdf" */ /*  */  /*   '"'"  */

This test works in comment-cache.

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

> > They object to it for reasons I don't
> > understand, despite the fact that it elegantly solves a long standing
> > problem that continues to cause pain on a frequent basis.

> Elegance is in the eye of the beholder. It certainly doesn't seem 
> elegant to me, design-wise.

> > If you (or anybody else) could summarize what these objections are, I'd
> > be very grateful.

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

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

> At worst, we risk divergence in the information contained in those
> sources (so functions depending on one or the other will behave in
> incompatible fashion). That means nasty bugs that aren't easy to track
> down.

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.

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.

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.

> > 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.  Instead you are putting forward
reasons, not all of them good, for abandoning comment-cache.

Alan Mackenzie (Nuremberg, Germany).

reply via email to

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