From: Drew Adams <drew.adams@oracle.com>
To: Juri Linkov <juri@linkov.net>
Cc: "46240@debbugs.gnu.org" <46240@debbugs.gnu.org>
Subject: bug#46240: [External] : bug#46240: Sorting order of read-char-by-name
Date: Tue, 2 Feb 2021 17:49:13 +0000 [thread overview]
Message-ID: <SA2PR10MB4474ACA985EA2C626E705BA7F3B59@SA2PR10MB4474.namprd10.prod.outlook.com> (raw)
In-Reply-To: <87pn1iafr6.fsf@mail.linkov.net>
> >> More examples with better sorting
> >
> > It's not "better" sorting; it's different sorting.
> >
> > Different sort orders are useful in different ways.
>
> This means there should be a customizable option?
Not necessarily an option. But a variable,
yes.
Emacs has a policy (misguided, IMO) that
code should never bind a user option.
Given that policy, making this (only) a
user option means code can't override
the option value.
What's really needed (for this and other
stuff) is BOTH a way for users to express
a general, default, preference (defcustom)
AND a way for user code and other code to
bind a variable for this to any (allowed)
value.
E.g., a user or a library should be able
to create a command that does completion
against ucs-names with a particular sort
order, which might be different from
whatever the user (defcustom) chose as
the option value.
___
(I know that in Isearch you chose to have
both a defcustom and a defvar for some
things, which is fine as one solution.
My own preference would be to relax the
policy of never allowing an option to be
bound.)
prev parent reply other threads:[~2021-02-02 17:49 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
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 [this message]
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=SA2PR10MB4474ACA985EA2C626E705BA7F3B59@SA2PR10MB4474.namprd10.prod.outlook.com \
--to=drew.adams@oracle.com \
--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).