zsh-workers
 help / color / mirror / code / Atom feed
From: dana <dana@dana.is>
To: zsh-workers@zsh.org
Subject: [BUG] Completion menu order doesn't (always) respect locale
Date: Wed, 17 Jan 2018 01:37:28 -0600	[thread overview]
Message-ID: <8EEE517F-5413-47EC-B114-7D2FD79ABCD7@dana.is> (raw)

The way completion possibilities are sorted in the menu has been bothering me,
but i was inspired to actually look into it today when i noticed that one
particular command was being sorted the way i wanted.

Here is an (abbreviated) example of the behaviour i see:

  % export LC_ALL=C
  % pgrep -<TAB>
  -F -G -L -P -U -a -d -f -g -i -l -n -o -q -t -u -v -x

  % export LC_ALL=en_GB.UTF-8
  % pgrep -<TAB>
  -F -G -L -P -U -a -d -f -g -i -l -n -o -q -t -u -v -x

  % export LC_ALL=C
  % pkill -<TAB>
  -F -G -L -P -U -a -f -g -i -n -o -q -t -u -v -x

  % export LC_ALL=en_GB.UTF-8
  % pkill -<TAB>
  -a -f -F -g -G -i -L -n -o -P -q -t -u -U -v -x

pkill is doing what i want — it respects my locale's collation settings. pgrep
is not — it always uses C/ASCII sorting.

The difference seems to be that pkill has 'grouped' options — i.e., multiple
options with the same description. In this case, the grouped ones are the
names of the signals, which all have the description 'signal'. If you
`unset signals` so that the function can't generate those options, pkill loses
its grouped options and it (mis)behaves like pgrep.

I tracked this down as far as cd_prep(). When there are grouped options, it
calls eltpcmp(), which in turn calls strcoll(). When there AREN'T grouped
options... well, it doesn't do that. Had to stop looking there.

The inconsistency affects many different completions. For example, ls and top
respect the locale, but ping and typeset do not. It's really irritating now that
i've noticed it.

I might look into it more later, but maybe someone already has an idea about it?

In the mean time, to at least make them consistent, i can set LC_COLLATE=C in
_main_complete.

dana


                 reply	other threads:[~2018-01-17  7:37 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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

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

  git send-email \
    --in-reply-to=8EEE517F-5413-47EC-B114-7D2FD79ABCD7@dana.is \
    --to=dana@dana.is \
    --cc=zsh-workers@zsh.org \
    /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.vuxu.org/mirror/zsh/

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 NNTP newsgroup(s).