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

[Eli Zaretskii]

> Cc: address@hidden, address@hidden, address@hidden, address@hidden,
>  address@hidden
> From: Dmitry Gutov <address@hidden>
> Date: Sun, 3 Dec 2017 19:43:31 +0000
> 
>         This feature is *not* targeted at Emacs development.
> 
>     It is for me.
> 
> You are not working on it. You've expressed no interest in this problem until 
> now. Maybe delegate the basic requirements, at least, to the people who did?

Your work on this is highly appreciated.  But I have certain
responsibilities, and I'm trying to do my job here.

I'm also your fellow developer of the same project and its active
user.  I think it means my opinions should be of some importance, not
something to be ignored solely because I'm not coding this.  Just like
I would never dream of ignoring your opinions about features I'm
implementing.

As for expressing interest: you are mistaken when you judge that by my
silence -- it only means that I had nothing significant to say about
the issue, until I did.

> [C-like major modes] can be catered to, *as soon as* the authors of each 
> individual major mode make the effort to support the feature.

Agreed.  What I'm trying to establish is whether the design supports
those major modes, or does it ignore them.  The latter I would like to
avoid as much as possible.

> Eli, we already have a feature in Emacs (prog-indentation-context) that does 
> not adhere to your (unreasonably high) requirements.

Emacs development is not only about not losing existing features.  It
is mainly about gaining new important features.  Here you are adding a
feature that I think is important enough for us to try make it support
C-like languages.  I don't think this requirement is unreasonably
high, as those languages are still pretty much the mainstay of the
industry, and definitely used by many Emacs users.

> Imagine if the chunk contains only this:
> 
>    <
> 
> And, to fontify it, CC Mode, tried to find out what syntactic element it is, 
> and to do that, calls some function that uses a specialized cache that's 
> contained in a variable that mmm-mode knows nothing about.
> 
> And that cache point to a position outside of the current restriction. 
> Confusion ensues. I've seen errors originating from that (I think), but can't 
> recall the exact sequence of calls.

Thanks, so the caches will have to be sensitive to restrictions as
they are sensitive to deletion of text.

> To fontify (or indent) a chunk, mmm-mode narrows to its bounds, and calls the 
> corresponding indent-line-function (or applies font-lock-keywords). If either 
> of those calls (widen), that causes problems.
> 
> So we want to document a convention that they don't call widen. That's really 
> it.

But given your example with CC Mode's caches, that's not all of it, is
it?  You also need the mode to adapt any such caches to changes in
buffer restrictions, right?

>             How do you address the issues which prog-indentation-context did
>             (e.g., if the embedded chunk of code is incomplete, and perhaps 
> even
>             syntactically invalid)?
> 
>         prog-indentation-context never addressed that issue, and we don't
>         either.
> 
>     I think it does, at least to some extent.
> 
> Not any more than scratch/widen-less.

Maybe I'm missing something, but what's the equivalent of PREV-CHUNK?

> We keep 'prog-first-column' from that proposal

But it was a function, and you made it a variable.  This will get in
the way of compatibility, and also potentially will make future
extensions harder.  Why not keep it a function?

> and instead of allowing MMM to indicate the chunk bounds through 
> prog-indentation-context, we allow MMM to apply narrowing directly, and that 
> modes honor it.

This simplification also took away some of the features, like the
ability to nest restrictions.  I wonder why did you discard that.
It's existing functionality, pretty lightweight, which was in Emacs
for some time, and is reasonably well documented.  And it already
satisfied your requirement of not allowing sub-modes to widen.  Why
not leave it alone?  What am I missing?

>         Transitioning from prog-indentation-context to the new approach is 
> very
>         easy.
> 
>     That's what I thought.  And that's why we should do that
>     simultaneously with landing the new approach.  There's no reason to do
>     that earlier.
> 
> Why confuse the language modes authors?

If they should be confused (I don't think so), they are already
confused, as we've been having this for the last 2 years.

>     We cannot know that.  Once the code is that long with us, we cannot
>     throw it away without a equivalent replacement.  And I see no reason
>     to do that now, since the fact that this code will exist in Emacs 26
>     doesn't hurt anyone, especially since the replacement will be easy, as
>     you say.
> 
> Well... you have a point there. The result will be pretty ugly, though. 
> Adding an API in one version, and removing it in another.

We will have to discuss the "removal" part.  An alternative is to
provide compatibility shims, or even leave (some or all of) the
existing API intact.

> They are incompatible with each other, so it's not like there can be a smooth 
> transition. 

I don't see the incompatibilities.  Basically, you replaced prog-widen
with widen, made prog-first-column a variable instead of a function,
and tossed prog-indentation-context.  We could instead keep the
existing API with minimal changes: prog-widen calls widen internally,
and we could allow direct calls to widen as well.

IOW, the transition could be much smoother than it will be if we
actually remove that stuff, because I don't think there's any
incompatibility here which would disallow direct calls to 'widen'
and/or leaving prog-indentation-context at its default nil value.  Or
maybe I'm missing something again.  But if I'm right, and if we can
make the necessary changes limited only to the documentation, then it
could well make it into Emacs 26.  So I think it is worth our while
to make some effort in that direction, if at all possible.

Thanks.