Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls

[Eli Zaretskii]

> Date: Sun, 3 Dec 2017 18:59:46 +0000
> Cc: Eli Zaretskii <address@hidden>, address@hidden, address@hidden,
>   address@hidden, address@hidden
> From: Alan Mackenzie <address@hidden>
> 
> > > Convince Alan to do what?
> 
> > To adhere to the current proposal (avoid widening in 
> > indent-line-function and font-lock-keywords, to start with).
> 
> I know Eli has asked to move on from the emotional to the technical
> stuff, but that last paragraph belongs to the former, and I will deal
> with it as such.

And I would _really_ want to move to the technical stuff.  So...  I
actually don't understand all the fuss about widening.  With a chunk
of C code embedded in something that is not C, CC Mode cannot possibly
need to look outside of the chunk, so why would you need to widen
beyond that?

> You mentioned today, I think, that writing an MMM is hard.  Well, CC
> Mode is hard, too.  There are 30 calls to `widen' in CC Mode and 47 to
> `narrow-to-region'.  They are all there for a reason.  It will be
> grinding tedious work to sort out the whys and to remove them.

Is that the only reason for your objections?  The need to tediously go
through a few dozen of calls to 'widen' and 'narrow-to-region', and
take care of each one of them as appropriate?  Or are there more
substantial problems in adapting CC Mode to non-widening MMM?

> so many of the `widen' calls are in low level functions called from
> "everywhere".

This can be taken care of with a more-or-less trivial wrapper and a
variable.  Right?

> Yesterday, Richard Stallman suggested as an alternative to the
> purloining of `widen' and `narrow-to-region' that a new "region" be
> implemented somehow which would be independent of the existing region
> and used solely by MMM super-modes.  How about exploring this
> possibility?

We can do that if needed, but I don't see the need yet.  (And a
proposal to do something along these lines was put forward by Vitalie
some time ago.)

> Last February, I suggested extensions to the syntax code ("syntactic
> islands") which would allow operations such as parse-partial-sexp to
> work essentially without restriction in buffers with several syntax
> tables.

What problems does this solve?  The problem with 'widen' or some other
problem(s)?