unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
To: "'Alan Mackenzie'" <acm@muc.de>
Cc: 3501@emacsbugs.donarmstrong.com
Subject: bug#3501: 23.0.94; Use Unicode in Info (?)
Date: Tue, 9 Jun 2009 12:56:24 -0700	[thread overview]
Message-ID: <3022D2AAB13E41CEA14A86DF771BAEB2@us.oracle.com> (raw)
In-Reply-To: <20090609181705.GD11634@muc.de>

> > Isn't Emacs capable of somehow knowing whether the current 
> > display can show non-ASCII chars?
> 
> Emacs is capable of anything, provided you put enough effort 
> into telling it.  Assuming you're running on a pure ASCII
> display, or one running an ISO-8859 character set (as I do),
> how much effort must you put into telling Emacs (and
> standalone Info) that you really, really don't want
> random Unicode bytes cluttering up your screen?

I meant Emacs, not the user. Can't Emacs itself tell whether to show Unicode or
not? See my example regarding buff-menu.el. Emacs already decides whether to try
to show you images and other display features.

> > I'm not against coddling your sturdy old card punch, but not at the
> > price of giving up the world beyond ASCII for the rest of, well, the
> > world beyond ASCII (does your punch _really_ speak ASCII, or does it
> > speak EBCDIC or perhaps Univac field-data chars?).
> 
> > Would you by the same token remove the possibility of Emacs files to
> > use Unicode chars?
> 
> Not at all.  Quite a lot of people want Unicode, but quite a 
> lot don't. We shouldn't force it upon them.

If their Emacs supports Unicode, they would see the people's real names. If
their Emacs does not support Unicode, they would see an ASCII-art version of the
real names, like now. Where's the forcing? If they want to stick with ASCII,
they'll see ASCII.

If users want only black & white, they get it. If they don't want a mouse, they
don't need a mouse. Likewise menus, highlighting, and all the rest. No problem.

I agree that one should not need to have Unicode support to be able to use Info.
It does not follow that Info must present itself, by default and to everyone,
using only the lowest common denominator for every possible user interaction.

We've finally added font-locking by default, and we've gotten rid of vestigial
limits due to 900-baud communication - by default, at least. And you can turn
off font-locking.

No one stops a user from wearing a hair shirt and sleeping on nails in a
Siberian cabin without windows or running water. But that doesn't mean that the
default should be to expect that most users have such preferences.

Unicode is today's ASCII, like it or not. And I notice that you said you use ISO
8859. Why is that? Did you get tired of using `$' to represent a pound or a
euro? For you, I guess, whatever you use is OK for the default - ISO 8859 would
be OK for Info, instead of ASCII? 

Why don't you limit yourself to Extended ASCII, which has a pound sign and lots
of other "fancy" stuff (http://www.asciitable.com/)? Why go all of the way to
the wild side, to ISO 8859? Aren't you afraid that that will open the flood
gates to using such fancy characters (including character graphics) all over the
place? Who can trust users to behave themselves with such means in their hands?

> > Jørgensen is more readable than J/orgensen, but J/orgensen 
> > is fine for a card punch. ;-)
> 
> Possibly.  But I have just the _tiniest_ suspicion that this 
> is the thin end of the wedge, the crack in the dyke, the floodgates 
> wanting to burst open.  How long before people start using Xah's
> fancy 3-byte quote marks, with associated dangly bits hanging off them?

Fear can be a powerful motivator. But not necessarily a wise counselor.

It's not because you _can_ make text proportional or italic or magenta or
23-point or blinking or boxed or gothic that you _will_ do so everywhere. 

Your reaction reminds me of conservatives who try to deny access to information
and new possibilities because of fear of the unknown. Keep women at home or
covered in black. No libraries, so we don't incite the unwashed masses with
ideas they won't be able to handle responsibly. No voting for the ignorant or
unpropertied. Close the box, quick!

(How do you spell etidull?)






  reply	other threads:[~2009-06-09 19:56 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-08 21:58 bug#3501: 23.0.94; Use Unicode in Info (?) Drew Adams
2009-06-09  3:11 ` Eli Zaretskii
2009-06-09  3:23   ` Drew Adams
2009-06-09  3:42     ` Eli Zaretskii
2009-06-09  4:10       ` Drew Adams
2009-06-09 17:17     ` Alan Mackenzie
2009-06-09 17:43       ` Drew Adams
2009-06-09 18:17         ` Alan Mackenzie
2009-06-09 19:56           ` Drew Adams [this message]
2009-06-09 21:10             ` Alan Mackenzie
2009-06-09 21:31               ` Lennart Borgman
2009-06-09 22:48           ` Jason Rumney
2009-06-09 17:46       ` Lennart Borgman
2009-06-25 23:12 ` Stefan Monnier

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

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3022D2AAB13E41CEA14A86DF771BAEB2@us.oracle.com \
    --to=drew.adams@oracle.com \
    --cc=3501@emacsbugs.donarmstrong.com \
    --cc=acm@muc.de \
    /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 public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).