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

[Alan Mackenzie <acm@muc.de>]

Hello, Dmitry.

On Sun, Dec 03, 2017 at 16:35:23 +0000, Dmitry Gutov wrote:
> On 12/3/17 3:28 PM, Eli Zaretskii wrote:

> > Because every development environment should first support its own
> > development well.  If it doesn't do that, it's incomplete.

> OK, I see. But!

> This feature is *not* targeted at Emacs development.

> Please don't make me fly out to Scotland and chase Alan down with a 
> broomstick to make this development come through.

Please read my signature, sometime.

> > Indeed; and C-like languages are quite popular among them.

> Not in comparison to JS, CSS and HTML.

> > How will we look if we support JS and Ruby embedded in HTML, but not C
> > code embedded in Yacc grammars nor Awk snippets embedded in shell
> > scripts?  Both are quite frequent out there.  We will be laughed at.

> We'll be fine. And the actual support is still going to reside in 
> third-party packages for now. This change just makes them possible (or 
> their codebases saner, at least).

> Except for antlr-mode. It will be able to use it right away (the version 
> inside Emacs, at least).

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

Maybe I missed it, but I don't recall anybody posting the suggestion
"Hey, we're considering writing an MMM mode which will mean nobody else
can use narrowing and widening, what do people think?".  If somebody had
posted that, there's a good chance that discussions could have sorted
out the technical stuff without provoking bad feelings.

Right now, I am being painted as the bad person for objecting to being
restricted to a subset of Emacs Lisp for CC Mode.  Forgive me for
feeling a bit peeved, but despite being in Emacs development for around
15 years, nobody asked me beforehand what I thought of this.  It is yet
one more thing that is presented as a done thing and foisted on Emacs
developers without them having any say in the matter.

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.  You
categorise the injunction against widening as "only applying to
indent-line-function and "font-lock-keywords" (which isn't a function)".
This is from my point of view non-sensical since so many of the `widen'
calls are in low level functions called from "everywhere".

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?

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.  How about exploring this possibility?

> > Do we even understand well enough what are
> > the problems in CC Mode that get in the way?

> Who do you think is most qualified to study that issue? We'd probably 
> have to convince Alan to do that as well, unfortunately.

Believe it or not, I am in favour of CC Mode working in an MMM mode.

> I have a rough understanding of the issue, but since I haven't reached a 
> working state, I don't know how many pitfalls there are left.

Neither do I.  But RMS's "new region" and my "syntax islands" may be a
more satisfactory way of resolving them.

> > About the only thing spelled out in this discussion was the need not
> > to widen.  Personally, I think this is not a grave issue, just some
> > technical problem that is certainly solvable (you proposed one such
> > solution).

> Indeed.

> > But is that all?

> I imagine the process itself might be trickier than expected. Various 
> primitives use caches that save context information. What is such 
> primitive to do if the cache contains "beginning of nesting" outside of 
> the current restriction, and the logic of said primitive says "go to the 
> beginning of the current function and do such and such"? The answer 
> isn't obvious to me.

Again, looking at RMS's suggested "new region" might help, here.

> But it's going to need to be answered anyway, no matter which MMM 
> approach we choose in the end, I think.

[ .... ]

> Consolidating the 'widen' calls is simply good engineering, even aside 
> from making life easier for MMM packages: it's much better to do that in 
> several well-defined places, instead of having every helper function do 
> it as well, like python-mode CC Mode do.

No, it isn't "simply good engineering" at all.  It's a different
approach with its pros and cons, just as widening at the immediate place
of need is.  And "consolidating" is probably the wrong word.  The number
of `widen's will probably grow, since every conceivable entry point
which could possibly call the pertinent primitve needs a `widen'.

[ .... ]

-- 
Alan Mackenzie (Nuremberg, Germany).