emacs-devel
[Top][All Lists]
Advanced

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

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


From: Stefan Monnier
Subject: Re: antlr-mode.el - need some support by python.el
Date: Mon, 08 Jun 2015 09:18:26 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

>>> +PREVIOUS-CHUNKS, if non-nil, provides the indentation engine of
>>> +the sub mode with the virtual context of the code chunk.  Valid
>>> +values are:
>>> +
>>> + - A string containing code which the indentation engine can
>>> +   consider as standing in front of the code chunk.  For example,
>>> +   it can contain a function header to make the code chunk
>>> +   being correctly indented as a function body.
>>> +
>>> + - A function called with the start position of the current
>>> +   chunk.  It will return either the region of the previous chunk
>>> +   as \(PREV-START . PREV-END) or nil if there is no further
>>> +   previous chunk.")
>> This is very unclear, so I'm not sure how an inner-mode could make use
>> of it.

Sorry, I re-read it and thought about it some more and realized that it
actually makes perfect sense and is not unclear.

>>> +(defun prog-widen ()
>>> +  "Remove restrictions (narrowing) from current code chunk or buffer.
>>> +This function should be used instead of `widen' in any function
>>> +used by the indentation engine to make it respect the value
>>> +`prog-indentation-context'.
>> I don't see a need for "should" here.
> What else - a "must" (This function is to be used)?

No, it's perfectly valid for the indentation code to use `widen', or to
manually use narrow-to-region based on prog-indentation-context, if it
feels like it, or to use neither widen nor prog-widen.  So rather than
"should", I'd expect "can" or something like that.

> OK, I didn't know whether I should rely on the behavior (defined in
> src/editfns.c) that narrow-to-region might also `widen'...

I think a lot of existing code relies on it, so I can't imagine changing this.


        Stefan



reply via email to

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