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

[Eli Zaretskii]

On December 5, 2017 7:08:14 AM GMT+02:00, Eli Zaretskii <address@hidden> wrote:
> On December 4, 2017 11:52:26 PM GMT+02:00, Dmitry Gutov
> <address@hidden> wrote:
> > On 12/4/17 7:28 PM, Eli Zaretskii wrote:
> > 
> > >> The widening is done in indent-according-to-mode and brings into
> > view
> > >> the whole multi-mode buffer, indeed.  Then MMM's
> > indent-line-function is
> > >> called, which narrows the buffer to the relevant chunk and then
> > calls
> > >> the submode's indent-line-function which hence only sees the part
> > of the
> > >> buffer it needs.
> > > 
> > > Ah, so this assumes that MMM is active in the buffer?  If so, can
> we
> > > widen only if MMM is indeed active?  Doing so will I believe
> > minimize
> > > (or even eliminate) the effects on existing behaviors when MMM is
> > not
> > > used.
> > 
> > That widening is for correctness when working during an interactive 
> > narrowing. MMM mode being enabled or not is irrelevant (it's not the
> 
> > beneficiary).
> 
> I understand that you and Stefan think so, but doing that
> unconditionally
> means these changes cannot be committed to emacs-26.  I was
> trying to find a way of squeezing them into the release branch, but if
> you think there's no way, it's fine with me to have this on master.

And btw, I'm not really convinced the unconditional widening is a good idea in 
general, even on master.  I could probably agree that in most cases it is TRT, 
but why would we _force_ all modes to indent with restrictions lifted?  No 
exceptions?  Not even a fire escape for some specialized mode with weird needs 
and requirements?  I'm not sure.  It certainly should be discussed, regardless 
of the MMM issues.