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

[Alan Mackenzie <acm@muc.de>]

Hello, Dmitry.

On Fri, Dec 01, 2017 at 19:13:27 +0000, Dmitry Gutov wrote:
> On 12/1/17 3:49 PM, Alan Mackenzie wrote:

> >> Please give an example.

> > A low level function which as an essential part of its functionality
> > (for example, to make sure point-min isn't within a comment or string)
> > widens.

> See Stefan and I's responses. Including an example of a shim that 
> wouldn't require you to change your code too much.

A shim?  Yuck!  My idea is an MMM that doesn't require any such shims.
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.

> But first and foremost, CC Mode probably doesn't need to worry about 
> complying with this guideline (yet). In my experience, it doesn't work 
> well in multi-mode context for reasons other than it calling widen. So 
> worrying about this change in protocol might be premature.

You mean, it would be better to wait until this protocol is firmly
established before arguing against it?  I'm guessing that the main
reason CC Mode doesn't work well in MMM is the contention between CC
Mode's narrowing and MMM's narrowing.  (This is the example you asked
for earlier on.)

> >> To rephrase, don't widen in indent-line-function or
> >> beginning-of-defun-function.

> > This is an intolerable restriction.  The low level function mentioned
> > above cannot, should not, must not know whether it's being called
> > (indirectly) from indent-line-function or b-o-d-function.  It will have
> > to widen in all cases or none.  Therefore there will be failures whilst
> > being called either from one of the two noted functions or from
> > elsewhere.

> See that shim in the other email.

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

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

> > The multi-mode mechanism should be designed to be usable with any major
> > mode.  There's nothing particularly hard about supporting CC Mode in a
> > well designed multi-mode scheme.

> It's harder than supporting Ruby, CSS and JS modes, that I can tell you 
> for sure. For one thing, the extra caches CC Mode uses have given me 
> multiple "argument out of bounds" errors when used with narrowing.

There's your example for contention between major modes' narrowing and
MMM's narrowing.  If you didn't narrow, CC Mode would behave properly.

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

> Some of them miss that responsibility (or else I wouldn't get those
> kind of errors).

It is the multiple-mode code that is responsible for not getting these
errors.  At least it should be.

> That tells me that moving (widen) call to some higher level is
> generally a good idea, but you can disagree.

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

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

> > We need better tools.  I have already proposed and offered to implement
> > such tools.

> It was much more complex, nowhere near even a proof of concept, and 
> doesn't seem to move anywhere, so far.

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

I'm still prepared to implement the "islands" proposal, which would
allow a better MMM mode than one based on narrowing, but ONLY if I get
some assurance from John, Eli, or even Stefan himself beforehand that
the implementation is, in principle, going to be incorporated into
Emacs.  That the only thing which would stop that would be solid
technical reasons.

> The change we're discussing is much smaller and pretty much implemented.

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.

> And again, there's no reason why they couldn't coexist.

The "pollution" mentioned above would make it more difficult.

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

-- 
Alan Mackenzie (Nuremberg, Germany).