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 16:35:23 +0000
> 
> This feature is *not* targeted at Emacs development.

It is for me.

> > Indeed; and C-like languages are quite popular among them.
> 
> Not in comparison to JS, CSS and HTML.

Maybe in your world, but not in mine.  So we will have to agree (or
disagree, if you want) that both worlds need to be catered to.

> > How will we look if we support JS and Ruby embedded in HTML, but not C
> > code embedded in Yacc grammars nor Awk snippets embedded in shell
> > scripts?  Both are quite frequent out there.  We will be laughed at.
> 
> We'll be fine.

>From your POV, maybe.  Not from mine.

> > Convince Alan to do what?
> 
> To adhere to the current proposal (avoid widening in 
> indent-line-function and font-lock-keywords, to start with).

We need to understand the full extent of problems, and then we need to
see how to go about them, at least design-wise.  "To start with" is a
start, but it cannot be the middle and the end.

> > Do we even understand well enough what are
> > the problems in CC Mode that get in the way?
> 
> Who do you think is most qualified to study that issue? We'd probably 
> have to convince Alan to do that as well, unfortunately.

If he agrees, that'd be swell.  If not, I see no reason why someone
else couldn't do that and report back, it's not like CC Mode is hard
to activate and see what problems pop up.

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

How about describing what you do know?

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

I don't understand: AFAIU in the use cases supported by MMM there can
be nothing outside of the current restriction that is of interest for
the mode which supports the chunk under the restriction.  So what kind
of "nesting outside of the current restriction" are we talking about,
and how does it come into play?

> The proposal itself is very small, and there's not much to explain. Just 
> look at the changes in the manual, in this branch.

That just removes text, more or less, and what it adds doesn't explain
itself well enough, sorry.  Otherwise I wouldn't have asked these
questions, believe me.

> It simply facilitates what mmm-mode (and other modes, including 
> mhtml-mode) has been doing for years, with varying success.

Sorry, that doesn't help me understand the proposal, as I don't know
mmm-mode well enough.  How hard is it to just describe the idea in a
few sentences?

> > Why do you
> > want to abandon the prog-widen stuff, which you supported just 2 years
> > ago?
> 
> I never actually supported it, just stopped arguing because I didn't 
> have a good alternative idea. Now I do, I think. And there is some 
> agreement from Stefan.

(whose change of hearts is also a mystery for me)

> > 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.  And even if I'm wrong, then
what is the equivalent of what it does address in your proposal?

In any case, we should at least have provisions for supporting that
within the proposed framework, and we should be fairly certain that
supporting that later will not blow things up.

> > All these questions and considerations need
> > to be understood, because you are explicitly proposing an incomplete
> > solution, and asking us to agree with its deficiencies, but without
> > providing a clear picture of what are we going to give up on.
> 
> That's the thing: we're not giving up much

For the modes that are dear to your heart, maybe.  But that's not all
Emacs should support well, IMO.

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

The 'widen' thing is a non-issue; it's the other stuff I'm worried
about, mostly because it is left unsaid, undiscussed, and I fear
uncatered-to by the design.

> > You
> > are still debating its design and implementation, even if we disregard
> > the CC Mode issue.
> 
> Not really. There's a minor issue of whether to make prog-first-column a 
> variable, or a hook right away, but the importance of that choice isn't big.

The fact is, it isn't done yet, let alone well-tested.

> > That code is in Emacs for more than 2 years.  It was admitted with
> > Stefan's full support, and at least ANTLR needs it in conjunction with
> > Python.
> 
> 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.

> So really, it's been here for 2 years, and virtually nobody's using it, 
> or improving it.

It's definitely used by its author, so "nobody uses it" is untrue, and
even unfair: that feature was accepted by Stefan, under the assumption
that it will be used.

> > Removing it without having some alternative again makes no
> > sense to me. 
> 
> You have the alternative, though.

No, we don't.  You are asking to remove the code _before_ the
alternative lands.

> > We should discuss this when the incompatible code lands;
> 
> How about we discuss it now?

The incompatible code didn't land yet.  But feel free to include the
replacement in your branch.

> > at that time, we will see how to remove/replace prog-widen etc. with
> > minimal pain for its users.  For now, there's no incompatibility that
> > requires us to remove the code.  And anyway, making such changes when
> > we are in pretest is against our practices.
> 
> That seems very unwise to me. Not to mention discouraging.

I don't see anything unwise in it, let alone discouraging.  We've
turned down much simpler and safer changes that came too late, and no
one claimed that was unwise or discouraging.

> Take a look at any third-party packages. I'm willing to bet none use 
> prog-indentation-context yet.

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.