[Top][All Lists]

[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: Sun, 12 Feb 2017 17:57:24 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.0

On 12.02.2017 14:05, Alan Mackenzie wrote:

That's incoherent.  comment-cache was never intended to help those other
uses, though it appears it could do so for most of them.  That
particular flaw we're talking about doesn't appear in comment cache, so
there's nothing to fix there.

You're changing a low-level primitive to adhere to a non-flexible view of the world that is incompatible with syntax-ppss.

Maybe sometime.  In the meantime, the bug with open parens in column
zero in comments should be fixed.

If you're willing to give up narrowing support, that bug can be fixed in no time, with the 20-line patch we all know about.

The question of "widening" is not difficult.  Narrowing a buffer should
not change the syntax of the characters in it.  Doing so leads to

Yeah, you really want narrowing to be interpreted the way that is more convenient for your usage habits. I want it to be interpreted that's more convenient for the code I've written and ended up maintaining. Resolving this conflict requires some thought.

If I understand correctly, the problem is that multiple-major-mode modes
are trying to use narrowing to get a null syntactic context.  They are
trying this because we don't provide anything better.  We should provide
something better.  I suggested such a something last spring ("islands").

You suggested implementing a big, ambiguously defined feature.

We basically have no way to determine whether it would work out. I've spent some time on that discussion helping you narrow down the specs, but my personal takeaway is that it's too complex. Maybe I'm too unimaginative and lazy, though, so please go ahead and work on a prototype if you're confident.

In the meantime, however, we need to keep Emacs compatible with multiple-major-mode modes some other way.

reply via email to

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