unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Phil Sainty <psainty@orcon.net.nz>
To: Arthur Miller <arthur.miller@live.com>
Cc: 50646@debbugs.gnu.org
Subject: bug#50646: 28.0.50; narrow-to-defun sometimes narrows to wrong defun
Date: Sun, 19 Sep 2021 22:04:13 +1200	[thread overview]
Message-ID: <bb37eda93a8dec7cca443dbbe309b2be@webmail.orcon.net.nz> (raw)
In-Reply-To: <AM9PR09MB49776BF0C4FA77BB29CB1C0696DF9@AM9PR09MB4977.eurprd09.prod.outlook.com>

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)






  reply	other threads:[~2021-09-19 10:04 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-17 17:06 bug#50646: 28.0.50; narrow-to-defun sometimes narrows to wrong defun arthur.miller
2021-09-18 14:09 ` Lars Ingebrigtsen
2021-09-18 17:27   ` Arthur Miller
2021-09-18 18:34     ` Arthur Miller
2021-09-19  8:34   ` Arthur Miller
2021-09-19  3:41 ` Phil Sainty
2021-09-19  6:36   ` Arthur Miller
2021-09-19 10:56     ` Phil Sainty
2021-09-19 20:02       ` Arthur Miller
2021-09-19  8:33   ` Arthur Miller
2021-09-19 10:04     ` Phil Sainty [this message]
2021-09-19 12:01       ` Eli Zaretskii
2021-09-19 12:06         ` Phil Sainty
2021-09-19 12:17           ` Eli Zaretskii
2021-09-19 12:53             ` Phil Sainty
2021-09-19 13:43               ` Eli Zaretskii
2021-09-19 14:21                 ` Phil Sainty
2021-09-19 15:22                   ` Eli Zaretskii
2021-09-19 15:25             ` bug#50646: [External] : " Drew Adams
2021-09-19 19:57       ` Arthur Miller
2021-09-20  6:02         ` Lars Ingebrigtsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bb37eda93a8dec7cca443dbbe309b2be@webmail.orcon.net.nz \
    --to=psainty@orcon.net.nz \
    --cc=50646@debbugs.gnu.org \
    --cc=arthur.miller@live.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).