bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#20499: [PROPOSED PATCH] C-x 8 shorthands for curved quotes, Euro, et


From: Eli Zaretskii
Subject: bug#20499: [PROPOSED PATCH] C-x 8 shorthands for curved quotes, Euro, etc.
Date: Sat, 09 May 2015 10:44:30 +0300

> Date: Fri, 08 May 2015 14:46:58 -0400
> From: Richard Stallman <address@hidden>
> CC: address@hidden, address@hidden
> 
>   > > Are you kidding?  Just to see 32 characters' glyphs
>   > > I'd have to type 128 input characters.
> 
>   > No, you need to type much less.  A codepoint, if you know it, is at
>   > most 5 characters,
> 
> I miscalculated.  C-x 8 RET codepoint RET is 8 characters (or 9).
> Thus, to see 32 characters' glyphs that way, I'd need to type
> between 256 and 288 input characters.

If you are not looking for a single specific character by its
codepoint, then typing the codepoint makes no sense.

>    > and for name completion, typing something like
> 
>    >  C-x 8 RET greek <TAB> <TAB>
> 
> That is a lot less input than the other method, and is sort of usable,
> but inconvenient.  I tried it in that very case.
> 
> It includes Coptic characters as well as Greek; I don't know why.

I don't know either.  If I type TAB after just "greek", then I see no
Coptic characters in completion candidates.  What did you type before
asking for completion?

> It also includes many punctuation characters, and letters with
> diacritics, that are in a different part of Unicode, and are not
> normal Greek letters.

This is simple Emacs completion at work: it brings you every character
whose name begins with "GREEK".

In any case, when I complete on "greek", I see only punctuation and
diacriticals from the same block as alpha, so I don't think we show
irrelevant punctuation.  We do show some ancient characters from other
Greek blocks than the one where alpha lives, but they are not
punctuation.

As for letters with diacriticals, how would Emacs know that you don't
need those?  I think the use case where the user looks for characters
with diacriticals is much more plausible than when she looks for some
simple character like alpha.  But if we think that looking for
characters "with diacriticals" or "without diacriticals" is an
important use case, we could provide that as well, based on the
'decomposition' property of the characters.

> If I could see the glyphs of the area of Unicode which alpha is in, I could
> easily see the character I want.

If you only want letters, you can give a more accurate spec to
completion: "C-x 8 RET greek*letter <TAB> <TAB>".  (The asterisk is a
wildcard character.)  That still produces quite a long list, but no
symbols, punctuation, or lone diacriticals.

Alternatively, you'd need to know the Unicode block in which those
characters live, or find it by completing on block names.  (This
block's name is "Greek and Coptic".)

> And when I want to enter some non-ASCII punctuator, if I could see
> the glyphs of that part of Unicode, it would be easy.
> I don't want to have to remember their official names.

Only a small part of (language- and script-agnostic) punctuation
characters have their own block.  The language-specific punctuation is
in the same block as their main characters.

We could have a feature which would display punctuation characters,
either specific to a language/script or not.  Such a feature would
need to use [:punct:] regexp (we'd need to extend [:punct:] to use
Unicode character properties).  Similarly, using [:alpha:] would bring
only letters.

I hope you now agree that the use case of searching for a character
with only some vague idea about its appearance and/or name needs some
pretty sophisticated (and overlapping) capabilities for allowing the
user to specify what she knows, before showing the possible
candidates.  I'm not really sure what would be a good UI for such
specifications; perhaps something using the widget library a-la
Customize, where you can check or uncheck certain options and specify
values for non-boolean fields.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]