[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#50646: 28.0.50; narrow-to-defun sometimes narrows to wrong defun
From: |
Phil Sainty |
Subject: |
bug#50646: 28.0.50; narrow-to-defun sometimes narrows to wrong defun |
Date: |
Sun, 19 Sep 2021 22:04:13 +1200 |
User-agent: |
Orcon Webmail |
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)
- bug#50646: 28.0.50; narrow-to-defun sometimes narrows to wrong defun, arthur . miller, 2021/09/17
- bug#50646: 28.0.50; narrow-to-defun sometimes narrows to wrong defun, Lars Ingebrigtsen, 2021/09/18
- bug#50646: 28.0.50; narrow-to-defun sometimes narrows to wrong defun, Phil Sainty, 2021/09/18
- bug#50646: 28.0.50; narrow-to-defun sometimes narrows to wrong defun, Arthur Miller, 2021/09/19
- bug#50646: 28.0.50; narrow-to-defun sometimes narrows to wrong defun,
Phil Sainty <=
- bug#50646: 28.0.50; narrow-to-defun sometimes narrows to wrong defun, Eli Zaretskii, 2021/09/19
- bug#50646: 28.0.50; narrow-to-defun sometimes narrows to wrong defun, Phil Sainty, 2021/09/19
- bug#50646: 28.0.50; narrow-to-defun sometimes narrows to wrong defun, Eli Zaretskii, 2021/09/19
- bug#50646: 28.0.50; narrow-to-defun sometimes narrows to wrong defun, Phil Sainty, 2021/09/19
- bug#50646: 28.0.50; narrow-to-defun sometimes narrows to wrong defun, Eli Zaretskii, 2021/09/19
- bug#50646: 28.0.50; narrow-to-defun sometimes narrows to wrong defun, Phil Sainty, 2021/09/19
- bug#50646: 28.0.50; narrow-to-defun sometimes narrows to wrong defun, Eli Zaretskii, 2021/09/19
- bug#50646: [External] : bug#50646: 28.0.50; narrow-to-defun sometimes narrows to wrong defun, Drew Adams, 2021/09/19
- bug#50646: 28.0.50; narrow-to-defun sometimes narrows to wrong defun, Arthur Miller, 2021/09/19
- bug#50646: 28.0.50; narrow-to-defun sometimes narrows to wrong defun, Lars Ingebrigtsen, 2021/09/20