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

[Arthur Miller <arthur.miller@live.com>]

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

> On 2021-09-19 20:33, Arthur Miller wrote:
>> (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.
>
> Yes, all of the following things from `insert-file-contents' are NOT done
> by `insert-file-contents-literally':
>
>   "This function does code conversion according to the value of
>   ‘coding-system-for-read’ or ‘file-coding-system-alist’, and sets the
>   variable ‘last-coding-system-used’ to the coding system actually used.
>
>   In addition, this function decodes the inserted text from known formats
>   by calling ‘format-decode’, which see.
>
> I don't believe you would typically use *-literally unless you specifically
> wanted to avoid all of those things (or some of the things, and were happy
> to take care of the others in your own code).
>
> I do also think that the docstring for `insert-file-contents-literally' can
> be made clearer, firstly just with a newline so that the context for the
> final sentence does not begin in the middle of a paragraph, and secondly
> so that when users are reading this for the first time it's more obvious
> (before reaching that final sentence) that the list of "modifications" are
> things which do NOT happen if you use this function.
>
> How does this look?
>
>  (defun insert-file-contents-literally (filename &optional visit beg end
>  replace)
>    "Like `insert-file-contents', but only reads in the file literally.
>  See `insert-file-contents' for an explanation of the parameters.
> -A buffer may be modified in several ways after reading into the buffer,
> -due to Emacs features such as format decoding, character code
> -conversion, `find-file-hook', automatic uncompression, etc.
> +
> +In other circumstances a buffer may be modified in several ways after
> +reading into the buffer, due to Emacs features such as format decoding,
> +character code conversion, `find-file-hook', automatic uncompression, etc.
>
>  This function ensures that none of these modifications will take place."
>    (let ((format-alist nil)

Yes I am quite aware of the difference contents-literally and not.

That is why I use it. Actually today when I opened the file to continue the
work on my patch, I saw I used literally and it struck me immidiately what is
going on :). I don't know why I didn't see it the other day. I worked with the C
sources, and there I wanted "literal" version (I still have it in the submitted
patch). I didn't have time to look through the subr.el today, and I am really
not familiar with it so it is really good if you took the time to look through
offending characters and fixed the bug!

Thank you for your kind advices and work, it was very nice that you look through
the bug and tried to help me and fixed it.