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

[Dmitry Gutov <dgutov@yandex.ru>]

On 12/1/17 10:35 PM, Alan Mackenzie wrote:

> A shim?  Yuck!  My idea is an MMM that doesn't require any such shims.M

Ideas have the tendency to be more ideal than their eventual 
implementations.

> Major modes should not be "polluted" to adapt to one particular MMM.  It
> solidifies that MMM, making it difficult to change to a better one.

It's not "one particular MMM". All existing MMM packages use narrowing.

And it's not just to adapt. Calling `widen' in fewer places just makes 
sense from engineering point of view.

> You mean, it would be better to wait until this protocol is firmly
> established before arguing against it? 

The proposal isn't going to hurt you in any significant way. That's what 
I mean.

> The shim doesn't help.  It's still horribly ugly.

Calling widen from dozens of functions in a package is ugly. A shim just 
helps you avoid rearchitecting it.

>>> Indeed it can, and it must.  A super-mode thus may not "reserve"
>>> narrowing for its own purposes to the exclusion of other uses.
> 
>> Right.
> 
> Glad we agree upon this.  However that contradicts your proposal that
> anything a beginning-of-defun-function calls can't use narrowing and
> widening.

Nope.

> There's your example for contention between major modes' narrowing and
> MMM's narrowing. 

Not sure what you mean by that. It's already apparent that some major 
modes will have to change to adapt to this proposal. Isn't it?

> If you didn't narrow, CC Mode would behave properly.

Without narrowing it gives us wrong syntax highlighting and indentation.

>> So these are my takeaways:
> 
>> 1) The "low-level primitives" in CC Mode do not widen consistently.
> 
> They widen when they need to, which is not always.

I don't think I'd get this error if they did.

But hmm, I think this error was in fontification code, actually. 
mmm-mode, of course, narrows to each individual hunk before using the 
corresponding mode's font-lock-keywords.

>> 2) The other errors should be solvable, but they require a separate
>> investigation, which nobody has found the time and energy to do so far,
>> over many years. So maybe it's not so necessary.
> 
> I would like AWK Mode to work inside shell-script-mode, since short AWK
> scripts are so often embedded in scripts.

When we're talking about short snippets, sometimes it's easier to use 
e.g. js-mode instead. That's what I've been advising for C code, too.

But if complex syntax in AWK happens often, and CC Mode has good support 
for it, maybe supporting it is a worthy endeavor.

>> 3) The solution to the other problems is most likely orthogonal to the
>> current discussion. Allowing multi-mode packages to use narrowing
>> certainly shouldn't hurt.
> 
> Of course not.  It's prohibiting major modes from using
> narrowing/widening that is objectionable.

Sometimes code has to follow certain protocols. That's nothing new.

> Investing the time and energy on an implementation was too risky.  In
> practice, Stefan has veto power over what goes into the syntax area, and
> I've been at the sharp end of that veto once too often (the rejection of
> my "comment-cache" code which solved the problem of open parens at
> column zero in comments).  In the last exchange about the "syntactic
> islands" concept, Stefan showed little enthusiasm for it: there was no
> "OK, implement it and we'll see what we can do with it", no
> encouragement whatsoever.  There was no discussion of major topics, such
> as the possibilities it would open up, or any plans to use it.  Mainly,
> the talk was about minor aspects of the proposal, at one point
> degenerating into a squabble about the use of the word "island".

No discussion, really? I've pointed out the major difficulties I could 
think of, which is normally the area that should get the most attention 
during the discussion of a technical proposal.

The fact that few people seemed interested... well, that happens. 
There's no use complaining that a proposal is unpopular. I've had a few 
over the years myself. Please feel free to push for it, of course.

> But it has negative implications.  It will only work with major modes
> specially adapted for it, and it imposes severe restrictions on those
> major modes.  I think it needs those modes to be "polluted" with MMM
> code.

We already have several major modes adhering to it, and for them the 
change was trivial. As far as major modes are concerned, web programming 
is the most important area, so CC Mode support is less urgent anyway.

> If the new code you're proposing is incorporated into Emacs, it will
> acquire some momentum, making it difficult to introduce a better
> solution.

Like mentioned, for most major mode the changes are trivial, if at all 
needed.