all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: "Stephen J. Turnbull" <turnbull@sk.tsukuba.ac.jp>
Cc: emacs-devel@gnu.org
Subject: Re: utf-16le vs utf-16-le
Date: Tue, 15 Apr 2008 23:09:32 +0300	[thread overview]
Message-ID: <uk5iyribn.fsf@gnu.org> (raw)
In-Reply-To: <87wsmzdpsp.fsf@uwakimon.sk.tsukuba.ac.jp>

> From: "Stephen J. Turnbull" <turnbull@sk.tsukuba.ac.jp>
> Cc: emacs-devel@gnu.org
> Date: Wed, 16 Apr 2008 01:51:50 +0900
> 
> Eli Zaretskii writes:
> 
>  > > BOM-{prohibited,auto,required}.
>  > 
>  > But we don't have these in Emacs, do we?
> 
> Huh?  We don't have the full suite, but we do have -signature variants.

Bot for UTF-8, we don't, at least not in GNU Emacs 23.  When I type
"C-x RET c utf-8 TAB TAB TAB", I see this in the completions buffer:

    Click <mouse-2> on a completion to select it.
    In this buffer, type RET to select the completion near point.

    Possible completions are:
    utf-8            utf-8-dos         utf-8-emacs  utf-8-emacs-dos
    utf-8-emacs-mac  utf-8-emacs-unix  utf-8-mac    utf-8-unix

No -signature variants.

>  > >  > Don't forget that en/decoding is used on strings as well, not only on
>  > >  > buffers.  Buffer-local variables won't cut it, I think.
>  > > 
>  > > Strings don't have encoding signatures or newline variants
>  > 
>  > ??? Of course, they do.
> 
> Indeed?  Suppose I have a string as the value of the symbol `s'
> containing the octets "\r\n".  Please explain to me how to compute
> whether that is the value 0x0D0A from a network stream prepared using
> htons(3), or a line ending suitable for appending to a Windows file.

The Lisp code that created the string knows what it is and how to deal
with it.  But you already know that, so I probably simply fail to
follow your reasoning.

>  > A string can be sent to a process, for example, so we must have some
>  > way of generating an external representation for it.
> 
> Well, of course we must.  But the right generalization of "buffer file
> coding system" is not to apply en/decoding to strings, but rather to
> give processes and sockets, etc, coding system properties equivalent
> to my proposed buffer-local variables.

I'm afraid that this will be very hard to implement in Emacs, since
the internals are very much exposed and we are used to copy strings to
and fro freely.  I think we also don't have sockets and other similar
interfaces as Lisp object to which we could give properties.




  reply	other threads:[~2008-04-15 20:09 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-13 14:54 utf-16le vs utf-16-le Eli Zaretskii
2008-04-13 19:32 ` Stefan Monnier
2008-04-14  5:17   ` Kenichi Handa
2008-04-14  6:10     ` David Kastrup
2008-04-14 18:54       ` Eli Zaretskii
2008-04-14 19:04         ` David Kastrup
2008-04-14 17:38     ` Eli Zaretskii
2008-04-14 18:57     ` Eli Zaretskii
2008-04-13 22:23 ` Stephen J. Turnbull
2008-04-14  3:19   ` Eli Zaretskii
2008-04-14  7:32     ` Stephen J. Turnbull
2008-04-14  8:20       ` David Kastrup
2008-04-14 18:25         ` Stephen J. Turnbull
2008-04-14 18:46           ` Eli Zaretskii
2008-04-14 21:01             ` Stephen J. Turnbull
2008-04-14 21:15               ` Andreas Schwab
2008-04-15  0:22                 ` Stephen J. Turnbull
2008-04-15  3:25               ` Eli Zaretskii
2008-04-15 16:51                 ` Stephen J. Turnbull
2008-04-15 20:09                   ` Eli Zaretskii [this message]
2008-04-15 20:31                     ` Eli Zaretskii
2008-04-15 20:35                       ` David Kastrup
2008-04-16 20:15                     ` Stephen J. Turnbull
2008-04-16 20:32                       ` David Kastrup
2008-04-17  3:23                         ` Stephen J. Turnbull
2008-04-17  3:26                           ` Eli Zaretskii
2008-04-17  7:44                             ` Stephen J. Turnbull
2008-04-17  8:19                               ` Jan Djärv
2008-04-17 12:41                                 ` Eli Zaretskii
2008-04-17 17:20                                 ` Stephen J. Turnbull
2008-04-17 18:03                                   ` Eli Zaretskii
2008-04-16 22:09                       ` Eli Zaretskii
2008-04-17  1:14                     ` Stefan Monnier
2008-04-14 20:20           ` Stefan Monnier
2008-04-14 20:58             ` David Kastrup
2008-04-14 22:19               ` Stefan Monnier
2008-04-14 22:26                 ` David Kastrup
2008-04-14 22:33                   ` Stefan Monnier
2008-04-15  5:44                     ` David Kastrup
2008-04-15 15:35                       ` Stefan Monnier
2008-04-14 21:35             ` Stephen J. Turnbull
2008-04-14  5:17 ` Kenichi Handa
2008-04-14 13:57   ` Stefan Monnier
2008-04-14  7:02 ` tomas
2008-04-14 17:45   ` Eli Zaretskii
2008-04-15  7:38     ` tomas
2008-04-15 22:30       ` Juri Linkov
2008-04-16  3:20         ` Eli Zaretskii
2008-04-16  8:12           ` Jason Rumney
2008-04-16 13:35             ` Stefan Monnier
2008-04-16 14:45               ` Jason Rumney
2008-04-16 17:05                 ` Stefan Monnier
2008-04-16 20:09               ` Stephen J. Turnbull
2008-04-16 23:17               ` Juri Linkov
2008-04-16 23:42                 ` Jason Rumney
2008-04-17  1:03                   ` Kenichi Handa

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=uk5iyribn.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=turnbull@sk.tsukuba.ac.jp \
    /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.