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

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

bug#20499: C-x 8 shorthands for curved quotes, Euro, etc.


From: Eli Zaretskii
Subject: bug#20499: C-x 8 shorthands for curved quotes, Euro, etc.
Date: Sat, 09 May 2015 11:22:09 +0300

> Date: Fri, 8 May 2015 17:03:53 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 20499@debbugs.gnu.org
> 
> I understand that Richard would like a help buffer that groups
> multiple glyphs together in blocks or in categories of various kinds.
> 
> I don't have that to offer, but maybe this would help in a different
> way: library `apu.el' provides apropos help for Unicode chars.
> 
> Command `apropos-unicode' shows you the Unicode chars that match
> an apropos pattern you specify: a regexp or a space-separated list
> of words.  The chars whose names match are shown in a help buffer,
> along with the names and code points (decimal and hex).

I hope I've succeeded to explain in my previous messages that just
matching the name against a regexp is not enough: you will most of the
time get a lot of candidates.  IOW, it's not focused enough, and the
reason is that the name of a character doesn't tell enough about the
character to be able to filter them only based on their names.

What we need is selection of candidates based on the character
attributes, and their language/script/block.  This could, of course,
use the completion/apropos infrastructure, but the completion
predicates must be smarter, and we should have a suitable UI for the
user to specify her partial knowledge of the characters she is after.

If you or someone else wants to work on this, I can provide advice as
to how to use Unicode character properties for such filtering.

> * Add an option of patterns to exclude from matches, to exclude
>   things like `TAG' and `VARIATION SELECTOR'.

The UI cannot be in these technical terms, because the user will most
probably fail to understand what that means for the search results.
E.g., it's quite probable that someone who wants an emoji characters
_will_ want the VARIATION SELECTOR included, but how many users will
understand that excluding it will not allow them to specify emoji
style of certain characters?

> * Be able to easily match a base char.  You can do this OK now
>   using a regexp such as ` \(BASE-CHAR \|$\)', but maybe there
>   is a better way.

I suggested the Custom-style interface using widgets.

> Is there a good way to exclude chars whose glyphs are essentially
> (apparently) whitespace, e.g., `MUSICAL SYMBOL END TIE'?

I'm not sure "mostly whitespace" is a good specification for those.  I
suppose someone who wants musical symbols will want this one as well.

> Is there a way to exclude chars that cannot be shown in the current
> font?  (Asked previously.)

Answered previously.





reply via email to

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