Re: Bug #22983 (syntax-ppss returns wrong result) is still open. Could we fix it before the release, please.

[Dmitry Gutov <dgutov@yandex.ru>]

On 06/11/2016 10:50 PM, Alan Mackenzie wrote:

>> I'm still not even clear which branch 25.2 will come from, and that's an
>> important concern.
>
> My guess is it'll will come from the master branch.  Otherwise, there'll
> be too much work in cherry picking commits back to the emacs-25 branch.
> That's just a guess, though.

That sounds like we shouldn't commmit any significant changes to master, 
doesn't it?

>> Hadn't you yourself proposed a far more invasive solution, not too long
>> ago?
>
> Intrusive it is, but an ugly hack it certainly isn't.  It's aim is to
> bring Emacs to the state it would have been in if it had been designed
> for multiple major modes per buffer right from the start.  As such it
> will be free from ugly workarounds.

An ugly workaround is in the eye of a beholder. And it also depends on 
the context.

I believe hard-widen can be made to work well, and not too hard to 
reason about. Although only time could tell.

> The main problem with it is the amount of work to implement it is huge.
> So much so, that I might well never finish it myself.  There was not a
> great deal of enthusiasm expressed for it all these weeks ago, apart from
> from Eli and yourself, and even then, Eli was unhappy about a fairly
> important part of it.

Yes, the idea was big/complex, and the design is unprecedented among 
text editors, AFAIK. These two characteristics, taken together, make it 
it very risky, at least.

> hard-widen seems to destroy the simplicity evident in narrow-to-region
> and widen.

What simplicity? narrow-to-region seemingly can't decide whether it's a 
command for users to invoke, or it's something for Lisp code to use. We 
end up treating both cases the same, and that causes a lot of problems. 
hard-widen would differentiate those.

> Why does (presumably) a super mode want to do anything with narrowing
> anyway?

How else would you apply each major mode's fontifications only within 
its subregions?

See 
https://github.com/purcell/mmm-mode/blob/c9a857a638701482931ffaaee262b61ce53489f3/mmm-region.el#L789-L816

> Narrowing is needed by users and by major modes, and its use by
> a super mode might well clash.

super modes are currently implemented as minor modes. major modes 
shouldn't override the choices made by minor modes, if at all possible.

> Is this hard-widen proposal at all
> documented in any coherent fashion?

These have been several discussions.

> I'm not convinced.  But then, I don't know how the proposal will work in
> any great detail.

I've linked to the patch and the previous discussion not too long ago.

> That paragraph worries me greatly.  OF COURSE CC Mode uses
> narrow-to-region and widen freely, there being code which can scarcely
> work without it.  I and other major mode maintainers will expect to
> continue to be able to do so.

The main thing CC Mode would have to worry about from then on, is that 
it won't always be able to goto-char to positions beyond the hard 
narrowing, even if they exist in the buffer (and are pointed to by some 
buffer-local data structure maintained by CC Mode's parser).

There may be some alternative approaches to this, but a super mode has 
to be able to *somehow* limit CC Mode's activity if we want to be able 
to use it for syntax highlighting and indentation inside e.g. Noweb's 
code chunks.