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

[Dmitry Gutov]

On 12/3/17 6:59 PM, Alan Mackenzie wrote:

> Please read my signature, sometime.

I sincerely apologize. Fly out to Germany, of course.

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

Erm, mmm-mode is 17 years old, originally written by a graduate student 
to help with literate programming (AFAIK). Did you mean they should have 
asked back then? And in the intervening years, several other packages 
took a similar approach.

And if you mean that I should have asked specifically, I did bring up it 
in a discussion... a year ago or so. And no realistic and complete 
counter-proposal came up, as far as I'm concerned.

> 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've never worked on a mixed-mode package, though. So yes, I 
personally have a reason to assume that I have a better knowledge of the 
problem area.

But I never said that CC Mode must support it.

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

Still, that sounds manageable. And there's no hurry at all, as far as 
I'm concerned.

> You
> categorise the injunction against widening as "only applying to
> indent-line-function and "font-lock-keywords" (which isn't a function)".

I think you know what I meant anyway.

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

Vitalie proposed something like that years ago, and we asked for help 
with the C code. Nobody turned up, including yourself (and I asked 
directly).

Anyway, I don't see how it would be qualitatively better. The problem of 
being able to function in a restricted area of a buffer will still be there.

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

Please go ahead and explore. I've done my part with my proposal (which 
was intentionally small and thus required small changes everywhere but 
CC Mode).

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

You just don't want the protocol we are proposing. Did you participate 
in the prog-indentation-context discussion when it was proposed, by the way?

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

May be, or may not. We'd need to see the code.

By the way, again, you can add a "new region" function exclusively to CC 
Mode, and use it in the indentation function. It's trivial to implement, 
and will look awfully like the shim I proposed.

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

See above.

But no, the problem I imagined (not 100% sure if it's real) won't be 
solved by "hard narrowing".

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

No more than there are interactive functions. A lot of them have to do 
that anyway already. And then, you could also have helpers that aren't 
used in indentation code.

There are several ways to skin that cat.