From: David Kastrup <dak@gnu.org>
To: Eli Zaretskii <eliz@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 12:30:21 +0100 [thread overview]
Message-ID: <87txahp7hu.fsf@fencepost.gnu.org> (raw)
In-Reply-To: <83mwg9dzzv.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 29 Mar 2014 14:07:48 +0300")
Eli Zaretskii <eliz@gnu.org> writes:
>> From: David Kastrup <dak@gnu.org>
>
>> 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.
No, it doesn't. Correlation is not causation. Just because some
operations will create a unibyte buffer as well as set a
case-fold-search variable does not mean that the unibyte setting of the
buffer is the cause of the case-fold-search setting in any meaningful
way.
>> 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?
Because it makes things predictable. I can take a look at the setting
of case-fold-search in order to figure out what will happen regarding
the case folding of searches. If I want them to occur, I can set the
variable, and if I don't want them to occur, I can clear that variable.
I can perfectly well do that with a let-binding, and it will work
throughout the let-binding without having some buffer properties
interfere.
--
David Kastrup
next prev parent reply other threads:[~2014-03-29 11:30 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
2014-03-29 11:30 ` David Kastrup [this message]
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=87txahp7hu.fsf@fencepost.gnu.org \
--to=dak@gnu.org \
--cc=eliz@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.