Re: Bug #25608 and the comment-cache branch

[Alan Mackenzie]

Hello, Dmitry.

On Sun, Feb 12, 2017 at 17:57:24 +0200, Dmitry Gutov wrote:
> 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.

No.  comment-cache and syntax-ppss are independent of each other and
thus not incompatible.

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

I'm not willing to give up narrowing support.  Neither are lots of other
people.  It's a fundamental feature of Emacs, widely used.

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

> Yeah, you really want narrowing to be interpreted the way that is more 
> convenient for your usage habits.

I want it to be handled correctly and consistently.

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

Multiple-major-mode code?  Narrowing is not a good way of doing this,
and I propose a better way.

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

It was big, yes, but reasonably well defined.  What I really meant in my
last paragraph was that the syntax bits of "islands" should be used in
place of what is now done with narrowing.  This would introduce two new
syntax classes "open island" and "close island".  "Open island" would
stack the current syntactic state and start anew, with a new syntax
table.  "Close island" would pop this stack, restoring the previous
state and syntax table.

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

It's not complicated.  It's just big.  It's intention is to be the
simplest possible natural implementation of multiple-buffer-modes which
doesn't need nasty workarounds.

> Maybe I'm too unimaginative and lazy, though, so please go ahead and
> work on a prototype if you're confident.

I'm confident it could work, but there's much more work involved than
I'm capable of doing on my own in a reasonable time.  It would need a
team to work on it.  That's not really the way Emacs gets developed.

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

See above.

-- 
Alan Mackenzie (Nuremberg, Germany).