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

[Dmitry Gutov]

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

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

> 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.
So these are my takeaways:

1) The "low-level primitives" in CC Mode do not widen consistently. Some 
of them miss that responsibility (or else I wouldn't get those kind of 
errors). 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.
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.
> 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.
The change we're discussing is much smaller and pretty much implemented.

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