[Top][All Lists]

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

Re: antlr-mode.el - need some support by python.el

From: Dmitry Gutov
Subject: Re: antlr-mode.el - need some support by python.el
Date: Thu, 05 Mar 2015 14:29:01 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Thunderbird/36.0

On 03/05/2015 11:46 AM, Wedler, Christoph wrote:

narrow-to-region: for indentation code, this is probably only multi-mode

Yeah, maybe. The old indentation engine uses it in one place, but that's probably just a bad decision.

widen: If you grep for `widen' in EMACS/lisp/progmodes, you find quite a
few matches.  Probably half of them are in indentation functions or
functions which are used by indentation functions.

True. But I'd expect this to change, after either of the proposed schemes is implemented.

Even if the major mode indentation function does the widening itself, that should happen in one place, right? Or otherwise centralized, as you suggest below.

If we do the START/END boundaries only via narrowing, only the outer
indentation command should use widen (which the multi-mode code won't
call), all called function are not allowed to use widen anymore.  In
other words, the widen calls must be moved to the outer commands.

Right. In this case, indent-according-to-mode (for instance) could call `widen'. It's a rather straightforward change.

If we do the START/END boundaries via the dynamically scoped variable,
the major modes just have to replace their (widen) call by (prog-widen),
a widen function which respects prog-indentation-context.

That sounds good to me too, but then we should call it something like `prog-submode-widen', right? And then maybe introduce `prog-submode-narrow-to-region' and `prog-submode-save-restriction'.

Et voilĂ , we now have a "new kind of narrowing", an approach Stefan, AFAICT, is still on the fence about.

The above is also a bit less flexible than having a `widen-function'.

If the multi-mode indentation function additionally narrows to
START/END, our approach also works for sub modes which do not call widen.

Yes, that's a nice bonus either way.

Yes, relying on dynamically scoped variable is not completely nice, but
there had been no programming guideline that indentation code should
only call widen only once directly at the beginning (as I said before:
inside save-restriction, of course).
I would not introduce such a guideline after decades...

I believe it's totally fine to introduce. It's not like the currently written modes will suddenly break. Only if they don't follow the guideline, they'll work worse in a multi-mode context.

Note that your `prog-widen' suggestion (as well as `prog-indentation-context') also requires changes in those modes' implementations.

reply via email to

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