emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eli Zaretskii
Subject: Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls
Date: Mon, 04 Dec 2017 18:12:34 +0200

> From: Stefan Monnier <address@hidden>
> Date: Sun, 03 Dec 2017 16:52:25 -0500
> 
> > 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)?
> 
> We can easily provide a similar functionality with Dmitry's design.
> Dmitry hasn't bothered doing that, because so far it's never been used
> (so it's not even clear whether it's ever needed nor whether it would
> provide the needed info).

What I don't understand is why we are asked to remove
prog-indentation-context.  I don't see how its existence contradicts
the possibility of calling 'widen' directly or leaving the variable at
its default nil value.  What am I missing?

> I think the failure here is to describe clearly the proposal.
> The core of the proposal, AFAIK, is the following:
> 
>     state that indent-line-function can rely on the current narrowing to
>     find all the relevant text, because the caller has already widened
>     when necessary for that.
> 
> To make it true, we need a few changes in the code, mostly we need to
> tweak indent-according-to-mode so that it widens before calling
> indent-line-function.

Why does it need to widen, though?  If the mode's indent-line-function
is not supposed to call 'widen', why do we do that in
indent-according-to-mode?  I don't think this has been explained
anywhere.  When you widen, the text that comes into the view will be
entirely alien syntactically to the sub-mode that is trying to indent,
right?

The existing code calls prog-widen in those cases, but that only
widens to include the current chunk (or whatever else the writer of
prog-indentation-context had in mind), which had this issue under
control, but the proposed changes toss that.

> This change should be harmless because even if the user has narrowed
> the buffer, the indentation should always be done depending on the
> whole buffer's content anyway.

But that's an incompatible change, isn't it?  And I don't see what it
has to do with MMM, where any restriction prior to the call to the
indentation function should be honored.

> > That code is in Emacs for more than 2 years.

> It's been in emacs.git's master, yes, but not in any released version of 
> Emacs.

That matters very little these days, as many people track the
development branches and adapt their packages to the new features
before they are released.

> > It was admitted with Stefan's full support, and at least ANTLR needs
> > it in conjunction with Python.
> 
> These can very easily be adjusted to rely on the new convention.

Why not just leave them alone?  IOW, where do they get in the way of
MMM calling 'widen' directly?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]