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

[Alan Mackenzie]

Hello, Dmitry.

On Sun, Jun 12, 2016 at 01:52:42AM +0300, Dmitry Gutov wrote:
> On 06/11/2016 10:50 PM, Alan Mackenzie wrote:

[ .... ]

> I believe hard-widen can be made to work well, and not too hard to 
> reason about.

I can't reason about hard-widen very much, because I haven't read its
specification.

> Although only time could tell. 

No.  A careful consideration of its proposed working before
implementation (let's call it a design ;-) can reveal a lot about how
well it could work.

[ .... ]

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

> What simplicity?

`widen' makes the entire buffer accessible.  `narrow-to-region' makes
the specified region the accessible portion.  And that's it!  What could
be simpler?

That simplicity is a masterstroke in the early design of Emacs.

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

That's the use case, not narrow-to-region itself.  It's actually both a
user command and a Lisp function, deliberately so, masterfully so.

> We end up treating both cases the same, and that causes a lot of
> problems.

I have encountered no such problems in over 15 years of hacking Emacs.
I think you're seeing problems somewhere and blaming
narrow-to-region/widen, when the real problem is somewhere else.

> hard-widen would differentiate those.

And that would cause great problems.  It would likely make
narrow-to-region/widen a pain to work with.

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

By adding the appropriate structures as buffer local variables (or
perhaps as text properties) which would delimit the subregions, then
enhance Font Lock to respect those boundaries.

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

That's rather a lot to take in before breakfast!

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

What????  What major modes shouldn't override is user settings, or
possibly minor mode settings.  The use/non-use of narrowing is NOT a
setting, any more than the use/non-use of cdr is.  They're just general
purpose tools.

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

> There have been several discussions.

They're not coherent, and they're not very useful.

Could you please write this document.  Given the massive change you want
to make in a fundamental Emacs tool, this is not unreasonable to ask.
This is, after all, what I did for the "islands" concept a couple of
months ago.  Your document need only be 50 - 100 lines long at the most.
Writing such doc would certainly help you clear things up for yourself,
too.

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

They are not useful for this purpose.

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

That sounds like something worthwhile sorting out in advance.

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

-- 
Alan Mackenzie (Nuremberg, Germany).