unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Juri Linkov <juri@linkov.net>
Cc: 46240@debbugs.gnu.org
Subject: bug#46240: Sorting order of read-char-by-name
Date: Tue, 02 Feb 2021 20:44:47 +0200	[thread overview]
Message-ID: <838s865mxs.fsf@gnu.org> (raw)
In-Reply-To: <87o8h266x2.fsf@mail.linkov.net> (message from Juri Linkov on Tue, 02 Feb 2021 19:13:13 +0200)

> From: Juri Linkov <juri@linkov.net>
> Cc: 46240@debbugs.gnu.org
> Date: Tue, 02 Feb 2021 19:13:13 +0200
> 
> > This has 2 disadvantages:
> >
> >   . the user needs to know the order of characters within a script
> >     he/she doesn't necessarily read
> 
> In this case usually the names of characters of an unknown script
> say nothing too, so sorting them by their names doesn't help much.

It isn't black and white.  For example, I'm familiar with quite a few
scripts and their characters, but have no idea about the alphabetical
order of most of them, with the exception of only two or three (end
even there I don't always remember the order of every character).

> >   . the user needs to know the order _between_ scripts, if the
> >     candidates include characters from different Unicode blocks
> 
> IMHO, this is not a disadvantage, but an advantage, because
> it helps to group the matched characters by their Unicode ranges.

Think of a case when there are more than 2 or three scripts involved.
You will have them take several window-fulls, and it could then be a
problem to find the script you are looking for.  This is similar to
having a directory with many files whose names use several scripts:
when these files are sorted alphabetically, you may not immediately
know whether file names that belong to some script are close to the
beginning or end of the list, because the relative ordering of scripts
in Unicode codepoint order is not necessarily something we remember.
(And then there are some scripts that use more than a single Unicode
block.)

> > If the user doesn't know this order, he/she might be unable to find
> > the required character quickly, if the list of candidates is long
> > enough.
> 
> I never rely on the current sorting alphabetically by names.
> When the list of candidates is long, I need to use isearch
> to search in the necessary block whose characters are scattered
> currently in almost random order.

Well, I guess there are also people like you, then.  So maybe we need
this to be an opt-in behavior.





  reply	other threads:[~2021-02-02 18:44 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-01 17:23 bug#46240: Sorting order of read-char-by-name Juri Linkov
2021-02-01 17:41 ` Eli Zaretskii
2021-02-02  8:40   ` Lars Ingebrigtsen
2021-02-02 17:16     ` Juri Linkov
2021-02-02 17:57       ` bug#46240: [External] : " Drew Adams
2021-02-02 18:47       ` Eli Zaretskii
2021-02-03 15:38       ` Lars Ingebrigtsen
2021-02-03 18:02         ` Lars Ingebrigtsen
2021-02-03 18:17           ` Eli Zaretskii
2021-02-03 18:21             ` Lars Ingebrigtsen
2021-02-03 18:40               ` Eli Zaretskii
2021-02-03 19:43           ` Juri Linkov
2021-02-04  7:56             ` Lars Ingebrigtsen
2021-02-04  9:32               ` Juri Linkov
2021-02-04 16:19                 ` Lars Ingebrigtsen
2021-02-04 22:34                   ` Juri Linkov
2021-02-05  7:36                     ` Eli Zaretskii
2021-02-06 19:35                       ` Juri Linkov
2021-02-06 20:01                         ` Eli Zaretskii
2021-02-07 18:56                           ` Juri Linkov
2021-02-07 19:54                             ` Eli Zaretskii
2021-02-09 18:13                               ` Juri Linkov
2021-02-09 19:00                                 ` Eli Zaretskii
2021-02-09 19:16                                   ` Juri Linkov
2021-02-02 17:13   ` Juri Linkov
2021-02-02 18:44     ` Eli Zaretskii [this message]
2021-02-03 17:27       ` Juri Linkov
2021-02-03 17:54         ` Eli Zaretskii
2021-02-03 19:44           ` Juri Linkov
2021-02-03 15:35     ` Lars Ingebrigtsen
2021-02-01 19:35 ` bug#46240: [External] : " Drew Adams
2021-02-02 17:18   ` Juri Linkov
2021-02-02 17:49     ` Drew Adams

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=838s865mxs.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=46240@debbugs.gnu.org \
    --cc=juri@linkov.net \
    /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).