From: Eli Zaretskii <eliz@gnu.org>
To: Paul Eggert <eggert@cs.ucla.edu>
Cc: p.stephani2@gmail.com, johnw@gnu.org, schwab@linux-m68k.org,
nicolas@petton.fr, 24206@debbugs.gnu.org
Subject: bug#24206: 25.1; Curly quotes generate invalid strings, leading to a segfault
Date: Mon, 15 Aug 2016 22:04:18 +0300 [thread overview]
Message-ID: <83k2fhg8gd.fsf@gnu.org> (raw)
In-Reply-To: <c823f988-3d49-0aed-3361-d14608a5fb03@cs.ucla.edu> (message from Paul Eggert on Mon, 15 Aug 2016 11:43:16 -0700)
> Cc: p.stephani2@gmail.com, johnw@gnu.org, nicolas@petton.fr,
> 24206@debbugs.gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Mon, 15 Aug 2016 11:43:16 -0700
>
> Yes. This is in the Elisp manual, which says "We recommend that
> you never use unibyte buffers and strings except for manipulating
> encoded text or binary non-text data."
That advice is for Lisp programmers, so it's only tangentially
relevant in this case.
> Eli Zaretskii wrote:
> > as the original string is
> > unibyte, the output of "\200≠", which is multibyte, might not be what
> > the users expect. They might expect "\200\342\211\240" instead.
>
> No, as per Andreas's comment and the Elisp reference manual, users should not
> expect substitute-command-keys to do that.
We still want them to be as little surprised as possible, do we?
> As long as it doesn't crash on non-ASCII unibyte data we needn't
> sweat the details about whether it returns unibyte or multibyte
> strings for such data.
I explained why this cannot be 100% true. So I'd like to avoid
converting unibyte strings to multibyte as much as reasonably
possible.
next prev parent reply other threads:[~2016-08-15 19:04 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-11 18:55 bug#24206: 25.1; Curly quotes generate invalid strings, leading to a segfault Phil
2016-08-11 20:05 ` Eli Zaretskii
2016-08-11 23:51 ` Philipp Stephani
2016-08-13 8:32 ` Eli Zaretskii
2016-08-13 12:25 ` Nicolas Petton
2016-08-14 6:33 ` John Wiegley
2016-08-14 4:54 ` Paul Eggert
2016-08-14 14:27 ` Eli Zaretskii
2016-08-14 14:51 ` Paul Eggert
2016-08-14 17:18 ` Eli Zaretskii
2016-08-15 2:04 ` Paul Eggert
2016-08-15 16:09 ` Eli Zaretskii
2016-08-15 16:46 ` Andreas Schwab
2016-08-15 18:43 ` Paul Eggert
2016-08-15 19:04 ` Eli Zaretskii [this message]
2016-08-15 18:51 ` Eli Zaretskii
2016-08-15 19:05 ` John Wiegley
2016-08-15 20:41 ` Paul Eggert
2016-08-16 14:38 ` Eli Zaretskii
2016-08-16 15:25 ` John Wiegley
2016-08-16 16:09 ` Nicolas Petton
2016-08-18 16:30 ` Nicolas Petton
2016-08-18 16:41 ` John Wiegley
2016-08-18 17:35 ` Eli Zaretskii
2016-08-16 17:37 ` Paul Eggert
2016-08-16 17:45 ` John Wiegley
2016-08-16 17:55 ` Paul Eggert
2016-08-16 17:57 ` John Wiegley
2016-08-16 18:44 ` Dmitry Gutov
2016-08-16 18:31 ` Eli Zaretskii
2016-08-16 14:52 ` Eli Zaretskii
2016-08-16 21:07 ` Paul Eggert
2016-08-17 15:12 ` Eli Zaretskii
2016-08-17 17:41 ` Paul Eggert
2016-08-17 18:06 ` Eli Zaretskii
2016-08-17 20:52 ` Paul Eggert
2016-08-18 14:30 ` Eli Zaretskii
2016-08-18 18:33 ` Paul Eggert
2016-08-18 18:58 ` Eli Zaretskii
2016-08-17 17:50 ` Dmitry Gutov
2016-08-14 15:21 ` Dmitry Gutov
2016-08-15 1:53 ` Paul Eggert
2016-08-15 1:57 ` Dmitry Gutov
2016-08-15 2:05 ` Paul Eggert
2016-08-14 17:21 ` Eli Zaretskii
2016-08-14 20:16 ` Paul Eggert
2016-08-15 1:12 ` Paul Eggert
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=83k2fhg8gd.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=24206@debbugs.gnu.org \
--cc=eggert@cs.ucla.edu \
--cc=johnw@gnu.org \
--cc=nicolas@petton.fr \
--cc=p.stephani2@gmail.com \
--cc=schwab@linux-m68k.org \
/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.