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

[Dmitry Gutov <dgutov@yandex.ru>]

On 12/9/17 12:47 PM, Eli Zaretskii wrote:

> I think we are failing to communicate.  "Not supported anywhere" is
> not a reason good enough in my book to remove something.

Allow me to clarify:

"Not supported anywhere" is, in my mind, a reason to disregard the "2 
years" qualifier. It's important to keep around code that's likely to be 
already used by someone, and it's barely the case here.

And the reasons to remove are different ones, and more technical, most 
of which have been mentioned in this thread already. And we discussed 
PREVIOUS-CHUNKS before, e.g. in the older thread I just linked to in a 
reply to John's email.

In addition to that, "not supported anywhere" can be a reason to remove 
PREVIOUS-CHUNKS in particular, because in the original discussion where 
they've been added, it was understood that the author will follow up 
with corresponding support for them (to prove the design), which he 
never did.

> We have
> there a feature that is a super-set of what you need for the MMM
> related support,

Not really, no.

> Arguing that there's a good reason for removing
> prog-indentation-context would need to show how keeping it _precludes_
> some of what you are trying to do, or at least makes it unreasonably
> hard.

Yes, it precludes us from removing prog-widen and widen calls from 
indentation code.

> And please keep in mind that 2 years without any additional users is
> not long enough to prove that this feature is useless.  Let's also
> keep in mind that this feature was reviewed at the time and admitted
> into Emacs, which means Stefan did think at least back then that it
> could be useful in practice.

It was predicated on some support coming later. Which, again, never did.

 > We should give people a chance before
 > deciding it is completely useless and worthy of removal.

What kind of chance? The support for it needed to be added *inside* Emacs.

It's not "completely" useless. prog-first-column was a good idea, but we 
have a better idea about the other parts.

> Whether we should unconditionally call 'widen' there is now a subject
> of a separate discussion. 

And why is that "separate discussion" not considered finished and 
concluded yet? I think the result is a fairly solid "yes, we can".

> For the purposes of this discussion, the
> only issue that should matter is whether using 'prog-widen' instead of
> 'widen' in those places will get in the way of the MMM support.

Unfortunately, that's not how the issue stands. Not calling widen in 
indentation functions matters.

>> No, they are not. The calls to prog-widen (or widen) made in indentation
>> related code are removed.
> 
> I don't think this distinction is important.  I presumed that you are
> removing those widen calls because you added similar calls on higher
> levels, and didn't mention those removals.  If that's not so, please
> point to specific parts of the patch where the widen calls are removed
> without that assumption.

Sorry, didn't mention where?

Indeed, widen calls are moved to a higher level above the 
indent-line-function funcall. That's a design which 
prog-indentation-context cannot support because prog-indentation-context 
is supposed to be bound inside MMM-specific indentation function.

> And I'm proposing to leave that prog-widen call intact, because by
> default it's the same as calling 'widen' in the first place.

Which means you're actively arguing against the core change proposed in 
the scratch/widen-less branch.

>>>     2) some calls to widen are added
>>
>> In code that later either calls indent-line-function or
>> beginning-of-defun-function.
> 
> This is about widening unconditionally, so it's now unrelated to the
> current discussion.

If those 'widen' calls are not added, interactive narrowing by the user 
will affect indentation results in the usual case. Which is probably not 
what we want to do.

>>>     3) prog-indentation-context is removed
>>
>> Yup.
> 
> And I see no reason for removing it, because if not set to any non-nil
> value, it is harmless.  If you can explain why leaving it contradicts
> support for MMM, please do.

Using prog-widen contradicts it. And if we can't promise that it will be 
used in all indentation functions (or at least those that purport to 
support MMM), prog-indentation-context, as documented, will be confusing 
and fairly useless.

>>>     4) prog-first-column the function is removed, and its calls replaced
>>>        with accessing the (existing) name-sake variable
>>
>> Yes. It's not a hard requirement, but there doesn't seem much benefit in
>> keeping it a function. And if it's a function, what will it return?
> 
> I don't think it matters what it will return.

If matters for me, because I want to know exactly what to write to make 
you happy on this issue. prog-first-column can be a function, but the 
choice of its backing needs to be made, and as I could see, my train of 
thought on that issue has not arrived at an any particular conclusion.

 > What matters is that
 > (a) keeping a function doesn't interfere with the MMM support in any
 > way I could see; (b) keeping a function makes the changes fully
 > backward-compatible; and (c) keeping a function will allow future
 > extensions where the value returned is not trivially taken from a
 > variable.

I concede points a and c.

>> If we keep it a function, do we also have a variable prog-first-column?
> 
> > But if there are good reason to keep the function, while
> renaming the variable, I will probably agree to renaming the variable
> much easier than I'd agree to removing the function.

It won't be just a rename, though, right? The prog-first-column will 
store only the first element of what was prog-indentation-context.

>> And as long as all the calls to that function are inside Emacs, we're
>> free to change it however, including turning it into a variable.
> 
> These all are very weak reasons in my eyes.  Keeping the documented
> interfaces stable and backward-compatible is a much stronger argument,
> and IMO in this case it easily overcomes the above considerations.

Even the last one? I though it was pretty solid. But no matter, see above.