From: Eli Zaretskii <eliz@gnu.org>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: thievol@posteo.net, larsi@gnus.org, schwab@linux-m68k.org,
44486@debbugs.gnu.org
Subject: bug#44486: 27.1; C-@ chars corrupt elisp buffer
Date: Sun, 15 Nov 2020 17:08:17 +0200 [thread overview]
Message-ID: <83mtziu07y.fsf@gnu.org> (raw)
In-Reply-To: <jwvo8jzpnl2.fsf-monnier+emacs@gnu.org> (message from Stefan Monnier on Sat, 14 Nov 2020 17:53:57 -0500)
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: larsi@gnus.org, thievol@posteo.net, handa@gnu.org,
> schwab@linux-m68k.org, 44486@debbugs.gnu.org
> Date: Sat, 14 Nov 2020 17:53:57 -0500
>
> >> If `utf-8` is preferable over `prefer-utf-8` for this usage I think
> >> the problem is in `prefer-utf-8` since it was introduced
> >> specifically for that.
> > The implementation doesn't support your POV.
>
> Then I think the implementation is in error.
But that ship has sailed 7 years ago.
> > We are not talking about .el files, we are talking about _any_ file
> > read using prefer-utf-8.
>
> `prefer-utf-8` was not introduced because it seemed like a good idea and
> then we hoped someone would find it useful. It was introduced to solve
> a concrete need, which is that of `.el` files. It's quite possible that
> there are other situations that have the same needs as `.el` files, but
> from where I stand it looks like "the needs of .el files (and similar
> cases)" should determine the intended behavior of `prefer-utf-8` rather
> than its current implementation.
>
> > For .el files, we can always bind inhibit-null-byte-detection to t
> > when we load or visit such files.
>
> We could, but I'm having trouble imagining a situation where we'd want
> to use `prefer-utf-8` and not inhibit "NUL means binary".
>
> The "NUL mean binarys" heuristic fundamentally says that `binary` is the
> first coding system we try and only if this one fails (for lack of NUL
> bytes) we consider others. But for `prefer-utf-8` we should first
> consider utf-8 and only if this fails should we consider others
> (potentially including `binary` if you want, my opinion is not as strong
> there).
>
> > I'm not talking about .el files. The coding-system's applicability is
> > wider than that.
>
> Could be. But it's its "raison d'être" (and AFAIK currently still the
> sole application), so it should handle this case as best it can.
We should have been having this discussion 7 years ago. And guess
what? we did. In that discussion, you said, in response to a question
from Kenichi:
> * What to do with null byte detection. Previously, if a
> *.el file contains a null byte and
> inhibit-null-byte-detection is nil (the default), it's
> detected as a binary file. Now utf-8 is forced regardless
> of inhibit-null-byte-detection.
I like the utf-8 better, but I don't know of any concrete case where it
makes a significant difference, so either way is OK.
^^^^^^^^^^^^^^^^
Note that what actually got implemented ignored
inhibit-null-byte-detection altogether, and _always_ considered the
file binary if any null byte was found. My change, which prompted
this present discussion, made prefer-utf-8 heed the variable's value,
which is mid-way between what we had for 7 years and what you thought
we should have. So, a small step forward ;-)
next prev parent reply other threads:[~2020-11-15 15:08 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-06 15:11 bug#44486: 27.1; C-@ chars corrupt elisp buffer Thierry Volpiatto
2020-11-06 15:33 ` Andreas Schwab
2020-11-06 15:40 ` Eli Zaretskii
2020-11-06 16:17 ` Eli Zaretskii
2020-11-06 20:07 ` Eli Zaretskii
2020-11-09 15:44 ` Lars Ingebrigtsen
2020-11-09 16:14 ` Eli Zaretskii
2020-11-09 16:27 ` Lars Ingebrigtsen
2020-11-09 16:57 ` Eli Zaretskii
2020-11-10 14:29 ` Lars Ingebrigtsen
2020-11-10 16:04 ` Eli Zaretskii
2020-11-14 14:02 ` Stefan Monnier
2020-11-14 15:09 ` Eli Zaretskii
2020-11-14 15:19 ` Stefan Monnier
2020-11-14 16:13 ` Eli Zaretskii
2020-11-14 17:55 ` Stefan Monnier
2020-11-14 18:08 ` Eli Zaretskii
2020-11-14 18:14 ` Eli Zaretskii
2020-11-14 22:56 ` Stefan Monnier
2020-11-15 15:14 ` Eli Zaretskii
2020-11-14 22:53 ` Stefan Monnier
2020-11-15 15:08 ` Eli Zaretskii [this message]
2020-11-15 18:31 ` Stefan Monnier
2020-11-14 12:43 ` Eli Zaretskii
2020-11-06 19:18 ` Thierry Volpiatto
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83mtziu07y.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=44486@debbugs.gnu.org \
--cc=larsi@gnus.org \
--cc=monnier@iro.umontreal.ca \
--cc=schwab@linux-m68k.org \
--cc=thievol@posteo.net \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.