GNU bug report logs - #50646
28.0.50; narrow-to-defun sometimes narrows to wrong defun

Previous Next

Full log

Message #25 received at 50646 <at> debbugs.gnu.org (full text, mbox):

From: Arthur Miller <arthur.miller <at> live.com>
To: Phil Sainty <psainty <at> orcon.net.nz>
Cc: 50646 <at> debbugs.gnu.org
Subject: Re: bug#50646: 28.0.50; narrow-to-defun sometimes narrows to wrong
 defun
Date: Sun, 19 Sep 2021 10:33:40 +0200

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

> On 2021-09-18 05:06, arthur.miller <at> 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")
>
>
> '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.
>
> 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 (which to me seems like a
> 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 <at> 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
>
>
> -Phil

I have found what was the problem, but I don't know if it is a bug or not:


(with-temp-buffer
  (insert-file-contents-literally (expand-file-name file source-directory))

It is the utf-8. When I use `insert-file-contents' instead, it works as
intended.

I guess insert-file-contents-literally does not preserve same coding as what I
have in the temp-buffer by deafault, so things get messed-up. I don't know if I
explain it well, but that seems to be the problem.

I don't know if that is a bug, or just me not being used to how encodings in
Emacs work. Probably not a bug.

I appologize for the inconvenience.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.