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:56:02 +0200

> From: Stefan Monnier <address@hidden>
> Cc: Dmitry Gutov <address@hidden>,  address@hidden,  address@hidden,  
> address@hidden,  address@hidden
> Date: Mon, 04 Dec 2017 11:35:53 -0500
> 
> > 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.
> 
> His proposal is reworking prog-indentation-context.
> CC-mode doesn't support prog-indentation-context, so it's no surprise
> that it doesn't support this replacement= and I don't see why suddenly
> we should first get CC-mode to support it before the replacement can
> be installed.

Not "first", "together with", or at least "soon enough after".

> Apparently, this has not been enough motivation for the last decade, so
> I'm not holding my breath.

Well, Alan just said he will try to make that happen, so I _am_
holding my breath.

> > Maybe I'm missing something, but what's the equivalent of PREV-CHUNK?
> 
> There isn't any.  PREV-CHUNK is probably a good idea somewhere in some
> cases, but we haven't found those cases yet.

But it's already in Emacs.  So the question IMO is "is it such a bad
idea that we need to get rid of it right away?"

> >> 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?
> 
> Agreed, it should be a function (which can internally just lookup
> a variable, in its current implementation, but API exposed to major
> modes should be the function).

That's what it is: a function that looks up a variable internally.

> >> 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 do not know what you're referring to.

AFAIU, prog-indentation-context could support a way to nest
restrictions, because prev-chunk could be a function.

> You mean we should provide patches for those codes using
> prog-indentation-context?  Doesn't Dmitry's branch already do that?

Not for ANTLR whose latest versions are maintained outside Emacs,
AFAIU.

> > I don't see the incompatibilities.  Basically, you replaced prog-widen
> > with widen,
> 
> Actually, no.

Again, I might be missing something, but "git diff" says I'm right.

> Then let's focus on the doc plus adding a few calls to widen in places
> like indent-according-to-mode.

I'd still like to understand why those additional calls to 'widen' are
needed.  Doing that seems to contradict what we want to ask major
modes not to do in their indentation code.



reply via email to

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