From: Eli Zaretskii <eliz@gnu.org>
To: David Kastrup <dak@gnu.org>
Cc: stephen@xemacs.org, monnier@IRO.UMontreal.CA, emacs-devel@gnu.org
Subject: Re: Unibyte characters, strings, and buffers
Date: Sat, 29 Mar 2014 14:07:48 +0300 [thread overview]
Message-ID: <83mwg9dzzv.fsf@gnu.org> (raw)
In-Reply-To: <87y4ztp9p8.fsf@fencepost.gnu.org>
> From: David Kastrup <dak@gnu.org>
> Cc: Eli Zaretskii <eliz@gnu.org>, monnier@IRO.UMontreal.CA, emacs-devel@gnu.org
> Date: Sat, 29 Mar 2014 11:42:43 +0100
>
> The current point of contention is about changing the way of
> codepoint-based character operations depending on the unibyte state of
> the current buffer.
The point for which this discussion was started was how to get rid of
this dependency, in those few places where we have them in Emacs.
> I am not necessarily of the same opinion as Stephen regarding whether or
> not abolishing unibyte buffers is a worthwhile goal. But I am pretty
> sure that "unibyte" should not be bleeding over into character and
> string operations.
Indeed, and Emacs tries very hard to contain that distinction, so that
it doesn't leak out of the internals. Mostly, it succeeds, but
sometimes it doesn't.
> A unibyte buffer or unibyte string might error out when trying to insert
> characters out of the range 0..255.
We currently don't do that. Try (insert "xyz") in a unibyte buffer,
where "xyz" is some non-ASCII string, and watch the fun.
> If we want different semantics for case-fold-search in binary buffers,
> then the solution is setting a buffer-local setting of case-fold-search
> when opening a buffer intended to be manipulated in a binary way.
>
> But the unibyte setting of the buffer should not affect normal character
> and string operation semantics. It is a buffer implementation detail
> that should not really have a visible effect apart from making some
> buffer operations impossible.
But if case-fold-search is set to nil in unibyte buffers, and (as we
know) buffer-local value of case-fold-search does affects functions
that compare text, either because they consult case-fold-search
directly or because the consult buffer-local case-table, then the
unibyte setting does affect the semantics, albeit indirectly.
> If something chooses a unibyte buffer representation for some reason, it
> is the responsibility of the same something to switch character
> operations and case-fold-search etc to something making sense in the
> context of its operation. That may well be through some buffer-local
> setting of case-fold-search etc, but it is not tied to the internal
> representation of the buffer contents.
Not that I disagree with you, but why does it matter whether some code
makes a buffer unibyte or sets its case-fold-search, to achieve that
goal? In both cases, that something tells Emacs to ignore case
conversion, it just uses 2 different ways of saying that. If we are
not going to abolish unibyte buffers, how is the difference important?
next prev parent reply other threads:[~2014-03-29 11:07 UTC|newest]
Thread overview: 103+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-26 19:04 Buffer-local variables affect general-purpose functions Eli Zaretskii
2014-03-26 19:32 ` Paul Eggert
2014-03-26 20:03 ` Eli Zaretskii
2014-03-26 21:50 ` Paul Eggert
2014-03-27 17:42 ` Eli Zaretskii
2014-03-27 18:55 ` Paul Eggert
2014-03-27 14:17 ` Stefan Monnier
2014-03-27 17:17 ` Eli Zaretskii
2014-03-27 21:04 ` Stefan Monnier
2014-03-28 7:11 ` Eli Zaretskii
2014-03-28 7:46 ` Paul Eggert
2014-03-28 8:18 ` Unibyte characters, strings and buffers Eli Zaretskii
2014-03-28 18:42 ` Paul Eggert
2014-03-28 18:52 ` Eli Zaretskii
2014-03-28 19:21 ` Paul Eggert
2014-03-29 6:40 ` Eli Zaretskii
2014-03-29 18:57 ` Paul Eggert
2014-03-29 19:46 ` Eli Zaretskii
2014-03-28 20:23 ` Stefan Monnier
2014-03-29 19:34 ` Stefan Monnier
2014-03-28 14:12 ` Buffer-local variables affect general-purpose functions Stefan Monnier
2014-03-28 3:38 ` Stephen J. Turnbull
2014-03-28 8:51 ` Unibyte characters, strings, and buffers Eli Zaretskii
2014-03-28 10:28 ` Stephen J. Turnbull
2014-03-28 10:58 ` David Kastrup
2014-03-28 11:22 ` Andreas Schwab
2014-03-28 11:34 ` David Kastrup
2014-03-28 11:42 ` Stephen J. Turnbull
2014-03-28 17:29 ` Eli Zaretskii
2014-03-28 17:50 ` David Kastrup
2014-03-28 18:31 ` Eli Zaretskii
2014-03-28 19:25 ` David Kastrup
2014-03-29 6:43 ` Eli Zaretskii
2014-03-29 7:23 ` David Kastrup
2014-03-29 8:24 ` Eli Zaretskii
2014-03-29 8:40 ` David Kastrup
2014-03-29 9:25 ` Eli Zaretskii
2014-03-28 20:27 ` Stefan Monnier
2014-03-29 9:23 ` Stephen J. Turnbull
2014-03-29 9:52 ` Andreas Schwab
2014-03-29 10:48 ` Eli Zaretskii
2014-03-29 11:00 ` Andreas Schwab
2014-03-29 11:18 ` Eli Zaretskii
2014-03-29 11:30 ` Andreas Schwab
[not found] ` <83ha6hduzz.fsf@gnu.org>
2014-03-29 14:30 ` Andreas Schwab
2014-03-29 14:47 ` Eli Zaretskii
2014-03-29 10:42 ` David Kastrup
2014-03-29 11:07 ` Eli Zaretskii [this message]
2014-03-29 11:30 ` David Kastrup
2014-03-29 12:58 ` Eli Zaretskii
2014-03-29 13:15 ` David Kastrup
2014-03-29 10:44 ` Eli Zaretskii
2014-03-29 11:06 ` Andreas Schwab
2014-03-29 11:12 ` Eli Zaretskii
2014-03-29 16:11 ` Stephen J. Turnbull
2014-03-29 15:37 ` Stephen J. Turnbull
2014-03-29 15:55 ` David Kastrup
2014-03-29 16:28 ` Stephen J. Turnbull
2014-03-29 17:00 ` David Kastrup
2014-03-30 2:05 ` Stephen J. Turnbull
2014-03-30 9:01 ` David Kastrup
2014-03-30 12:13 ` Stephen J. Turnbull
2014-03-30 14:25 ` Andreas Schwab
2014-03-30 15:05 ` David Kastrup
2014-03-30 15:39 ` Andreas Schwab
2014-03-29 17:08 ` Andreas Schwab
2014-03-30 0:24 ` Richard Stallman
2014-03-30 3:32 ` Stefan Monnier
2014-03-30 15:13 ` Richard Stallman
2014-03-29 15:58 ` Andreas Schwab
2014-03-29 16:35 ` Stephen J. Turnbull
2014-03-29 17:06 ` Andreas Schwab
2014-03-29 17:01 ` Nathan Trapuzzano
2014-03-29 17:08 ` Nathan Trapuzzano
2014-03-29 17:18 ` David Kastrup
2014-03-29 17:33 ` Nathan Trapuzzano
2014-03-30 0:24 ` Richard Stallman
2014-03-30 8:38 ` Andreas Schwab
2014-03-30 15:12 ` Richard Stallman
2014-03-29 17:16 ` David Kastrup
2014-03-28 18:45 ` Daniel Colascione
2014-03-28 19:35 ` Glenn Morris
2014-03-29 11:17 ` Stephen J. Turnbull
2014-03-29 11:22 ` Eli Zaretskii
2014-03-29 16:03 ` Stephen J. Turnbull
2014-03-31 15:22 ` Eli Zaretskii
2014-04-01 3:36 ` Stephen J. Turnbull
2014-04-01 7:42 ` David Kastrup
2014-04-01 9:38 ` Stephen J. Turnbull
2014-04-01 15:19 ` Eli Zaretskii
2014-04-01 15:16 ` Eli Zaretskii
2014-04-02 4:20 ` Stephen J. Turnbull
2014-04-02 17:06 ` Eli Zaretskii
2014-04-03 10:59 ` David Kastrup
2014-04-03 16:07 ` Eli Zaretskii
2014-04-03 16:26 ` David Kastrup
2014-04-03 19:11 ` Eli Zaretskii
2014-04-03 20:03 ` David Kastrup
2014-04-04 0:48 ` Stephen J. Turnbull
2014-04-04 8:08 ` Eli Zaretskii
2014-04-04 7:58 ` Eli Zaretskii
2014-04-04 11:40 ` Richard Stallman
2014-04-03 13:04 ` Stephen J. Turnbull
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=83mwg9dzzv.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=dak@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=monnier@IRO.UMontreal.CA \
--cc=stephen@xemacs.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.