[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Emacs Lisp's future
From: |
Stephen J. Turnbull |
Subject: |
Re: Emacs Lisp's future |
Date: |
Wed, 15 Oct 2014 16:17:52 +0900 |
Paul Eggert writes:
> It's perfectly fine for users to try "M-x grep -r" at home. It's
> not going to hurt them.
That's true for "hurt" == "must call 911". There are very few
computer applications where bugs can result in 911 calls, though.
That's an awfully low quality standard you have there.
> It's a common idiom, and lots of people use it every day.
Because they're monolingual English speakers, they can. Others
cannot, unless they have an environment where there is a common coded
character set used for all textual content. Even an American
searching for all instances of the CENT SIGN would be subject to
this bug.
http://www.thecomicstrips.com/store/add.php?iid=83467
> Conversely, it appears that you did not read the file
> admin/notes/unicode carefully;
"It appears that you have not studied Unicode carefully", as there is
nothing in that file that suggests anything but work is involved in a
conversion that loses no character information, since the external
coding system utf-8-emacs is available. Even that can be dispensed
with, and pure Unicode used, with a little more work (use the PUA,
that's what it is there for!)
The metadata (language, for which original coded character set is a
proxy) can be provided either with a markup language (eg, XML or even
HTML) or using Plane 14 tags (but I wrote that already).
> if you had, you would not be asserting so blithely that there is
> "no barrier" to converting all Emacs source files to UTF-8.
I stand corrected. No *technical* barrier. It does require
nontrivial work: simply filtering through iconv is not enough.
There's also a political barrier: I believe that characters are
characters, and may be shared across traditional character set
boundaries, and that the presentation layer should specify
presentation. Dr. Handa prefers that presentation be encoded in the
content. I have no stomach for that argument.
- Re: Emacs Lisp's future, (continued)
- Re: Emacs Lisp's future, Eli Zaretskii, 2014/10/13
- Re: Emacs Lisp's future, Stephen J. Turnbull, 2014/10/14
- Re: Emacs Lisp's future, Eli Zaretskii, 2014/10/14
- Re: Emacs Lisp's future, Eli Zaretskii, 2014/10/14
- Re: Emacs Lisp's future, Stephen J. Turnbull, 2014/10/14
- Re: Emacs Lisp's future, Stephen J. Turnbull, 2014/10/14
- Re: Emacs Lisp's future, Eli Zaretskii, 2014/10/14
- Re: Emacs Lisp's future, Paul Eggert, 2014/10/14
- Re: Emacs Lisp's future, Stephen J. Turnbull, 2014/10/14
- Re: Emacs Lisp's future, Paul Eggert, 2014/10/15
- Re: Emacs Lisp's future,
Stephen J. Turnbull <=
- Re: Emacs Lisp's future, Eli Zaretskii, 2014/10/15
- Re: Emacs Lisp's future, Stephen J. Turnbull, 2014/10/15
- Re: Emacs Lisp's future, David Kastrup, 2014/10/15
- Re: Emacs Lisp's future, Eli Zaretskii, 2014/10/15
- Re: Emacs Lisp's future, Stephen J. Turnbull, 2014/10/15
- Re: Emacs Lisp's future, Eli Zaretskii, 2014/10/15
- Re: Emacs Lisp's future, David Kastrup, 2014/10/15
- Re: Emacs Lisp's future, Stephen J. Turnbull, 2014/10/15
- Re: Emacs Lisp's future, Paul Eggert, 2014/10/15
- Re: Emacs Lisp's future, Stephen J. Turnbull, 2014/10/15