bug#50646: 28.0.50; narrow-to-defun sometimes narrows to wrong defun

[Arthur Miller]

Phil Sainty <psainty@orcon.net.nz> writes:

> On 2021-09-18 05:06, arthur.miller@live.com wrote:
>> 1. run Emacs -Q -l /path/to/attached/help-mode.el
>> 2. type C-x f
>
> C-h f
>
>> 3. in minibuffer type: when RET
>> The help-mode buffer that opens should show help for 'when' form, but it
>> shows the source code for the 'pop' macro which precedes the 'when' in
>> subr.el.
>
>> The docs for 'narrow-to-defun' says the "current-defun" is one that
>> contains the point or follows the point.
>
> I can reproduce the issue using your code, but I'm not sure whether the
> reason for it is a misunderstanding of what 'point' is, some vagueness
> in the 'narrow-to-defun' docstring, or an actual regression.
>
> To eliminate the first:
>
>    "Like other positions, point designates a place between two characters
> (or before the first character, or after the last character), rather
> than a particular character.  Usually terminals display the cursor over
> the character that immediately follows point; point is actually before
> the character on which the cursor sits."
>
> -- quoted from (info "(elisp)Point")
Yes, I am aware that point is between two characters. I also use the bar for the
cursor, and it is displayed before the first character; I think.

> 'narrow-to-defun' says "The current defun is the one that contains point
> or follows point." and if you place the cursor over the opening "(" of
> "(defmacro when" then that defmacro form "follows point", and indeed
> narrow-to-defun works as intended.
Than it is probably my understanding of "follows" the point. In my understanding
it was the "one that comes after" the point :). Notice that I tried to move the
point one character forward (or I think even two, but I don't remember any
more), but it didn't helped.

When I moved few characters, like with forward-word helps, which is also what
you say.

> The issue is what happens when point is somewhere earlier than that
> position, but still *after* the previous form.  In that instance
> narrow-to-defun narrows to the previous form, which is surely what is
> happening in your code.
>
> If so, all you need for reproducing this is to experiment with
> narrow-to-defun at the various positions between two forms.
>
> That is a consequence of 'beginning-of-defun' jumping to the beginning
> of the previous defun in that situation
That sounds like a plausible explanation. I haven't looked into the code for
narrow-to-defun.

My question is though, why it happens only with 'when'? I haven't found any
other form to show same behaviour. There probably are some, I just haven't found
them by manually testing.

> reasonable behaviour for that function); but for 'narrow-to-defun'
> the effect does seem contrary to its docstring.
>
> I think we just want to change the docstring of 'narrow-to-defun' --
> the last relevant commit looks like:
>
>
> commit 050cc68b402f5998193a6026d0eeeecb9d2cb9c4
> Author: Lennart Borgman <lennart.borgman@gmail.com>
> Date:   Wed Apr 11 04:12:20 2012 +0200
>
>     `narrow-to-defun' fixup
>
>     * emacs-lisp/lisp.el (narrow-to-defun): `beginning-of-defun' goes
>     to previous function when point is on the first character of a
>     function. Take care of that in `narrow-to-defun'.
>
>     Fixes: debbugs:6157
>
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=6157
>

Anyway, thank you for the explanation and for the time and for the updated docs.