bug: zsh tab completion with two characters duplicated

[kunxi]

Are you following the right branch?

• [X] My Nixpkgs and Home Manager versions are in sync

Is there an existing issue for this?

• [X] I have searched the existing issues

Issue description

The symptom is if use tab complete, the first two characters are duplicated:

The root cause is the zsh miscalculate the position of the cursor due to the unicode in the prompt. It might result in:

1. A bug in the theme, in my case pure or starship.
2. incorrect locale.

It is easy to rule out the first hypothesis, I can invoke a zsh shell inside the current zsh shell, and the symptom no longer reproduce.

For second hypothesis, my assumption is locale might be set after the starship is initialized. Here is my home-manager setup: https://github.com/kunxi/nix-config/

The locale is set in the hm-session-vars.sh, only related part:

export LANG="en_US.UTF-8"
export LC_ALL="en_US.UTF-8"
export LC_CTYPE="en_US.UTF-8"
export LOCALE_ARCHIVE_2_27="/nix/store/1vxmfqmxzm3z959fbdgspv4yz75x3y0q-glibc-locales-2.35-224/lib/locale/locale-archive"

And it is sourced in zshenv:

# Environment variables
. "/home/bookstack/.nix-profile/etc/profile.d/hm-session-vars.sh"

The starship is configured in .zshrc:

if [[ $TERM != "dumb" && (-z $INSIDE_EMACS || $INSIDE_EMACS == "vterm") ]]; then
  eval "$(/home/bookstack/.nix-profile/bin/starship init zsh)"
fi

So we should have locale setup correctly, right? I also search the issues, such as this one, and consider another home-manager specific issue might be LOCALE_ARCHIVE environment variable?

❯ env | grep ARCH
LOCALE_ARCHIVE_2_27=/nix/store/8kl2vsyflx859lz3n8lc3z6v1dgc36cs-glibc-locales-2.35-224/lib/locale/locale-archive

With the suggestion in the above issue, I add LOCALE_ARCHIVE and did no change the outcome?

Any idea?

Maintainer CC

No response

System information

❯ nix-shell -p nix-info --run "nix-info -m"
this path will be fetched (0.00 MiB download, 0.00 MiB unpacked):
  /nix/store/xf4zw8cqbh9r599273cvc5rpnnkql9sh-nix-info
copying path '/nix/store/xf4zw8cqbh9r599273cvc5rpnnkql9sh-nix-info' from 'https://cache.nixos.org'...
 - system: `"x86_64-linux"`
 - host os: `Linux 5.10.102.1-microsoft-standard-WSL2, Debian GNU/Linux, 11 (bullseye), nobuild`
 - multi-user?: `no`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.12.0`
 - channels(bookstack): `"home-manager, nixpkgs"`
 - nixpkgs: `/home/bookstack/.nix-defexpr/channels/nixpkgs`

[ncfavier]

I don't know if this applies in your case, but there's a whole class of issues where characters in Private Use Areas get assigned a width of 1, so if you're using a font that displays those characters with wider glyphs it might lead to issues.

[kunxi]

@ncfavier It is quite hairy when debugging this kind of errors.

I have a hunch it is related to the locale or nix-specific, as the zsh inside zsh just works fine. I would appreciate if someone could give me some hints how to debug this. I really want scratch the itch.

Thanks.

[ncfavier]

I expect you'd have more luck asking the starship maintainers as they have more experience with what could go wrong. This could be a home-manager problem but I have no clue what a priori.

[stale[bot]]

Thank you for your contribution! I marked this issue as stale due to inactivity. Please be considerate of people watching this issue and receiving notifications before commenting 'I have this issue too'. We welcome additional information that will help resolve this issue. Please read the relevant sections below before commenting.

If you are the original author of the issue

* If this is resolved, please consider closing it so that the maintainers know not to focus on this. * If this might still be an issue, but you are not interested in promoting its resolution, please consider closing it while encouraging others to take over and reopen an issue if they care enough. * If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

If you are not the original author of the issue

* If you are also experiencing this issue, please add details of your situation to help with the debugging process. * If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

Memorandum on closing issues

Don't be afraid to manually close an issue, even if it holds valuable information. Closed issues stay in the system for people to search, read, cross-reference, or even reopen – nothing is lost! Closing obsolete issues is an important way to help maintainers focus their time and effort.

[joeylibj]

this solved my problem:

export LANG=C.UTF-8

[LGUG2Z]

this solved my problem:

export LANG=C.UTF-8

For what it's worth, I started experiencing this same issue a few days ago, and exporting this fixed the issue.

[stale[bot]]

Thank you for your contribution! I marked this issue as stale due to inactivity. Please be considerate of people watching this issue and receiving notifications before commenting 'I have this issue too'. We welcome additional information that will help resolve this issue. Please read the relevant sections below before commenting.

If you are the original author of the issue

* If this is resolved, please consider closing it so that the maintainers know not to focus on this. * If this might still be an issue, but you are not interested in promoting its resolution, please consider closing it while encouraging others to take over and reopen an issue if they care enough. * If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

If you are not the original author of the issue

* If you are also experiencing this issue, please add details of your situation to help with the debugging process. * If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

Memorandum on closing issues

Don't be afraid to manually close an issue, even if it holds valuable information. Closed issues stay in the system for people to search, read, cross-reference, or even reopen – nothing is lost! Closing obsolete issues is an important way to help maintainers focus their time and effort.

[alxdb]

I just experienced this same issue, and the above mentioned fix (export LANG=C_UTF.8) resolved it.

Pretty sure this should be addressed in home-manager, as I've used starship with zsh in other setups and never experienced this issue. Seems to be an ordering issue between the starship and the zsh modules of home-manager.

[weberbr]

I'm having a similar issue with home-manager on ubuntu, zsh and an oh-my-zsh custom prompt. The home-manager zsh version works fine on nixos. zsh in zsh and the export LANG=8_UTF.8 both resolve the issue on my end too, though I have no idea why. I spent a long time using vimdiff to compare functions and env between zsh and zsh in zsh, to no avail. I'm wondering if there's an odd interaction happening between the system /etc/zsh{rc,env,login...} and home-manager's zsh config?

EDIT: Moving /etc/zshrc and /etc/zsh doesn't work either, so I don't think it's a conflict with system config.

[weberbr]

I don't know if this applies in your case, but there's a whole class of issues where characters in Private Use Areas get assigned a width of 1, so if you're using a font that displays those characters with wider glyphs it might lead to issues.

This was part of the issue in my case. Wrapping all of my non-ascii characters with %{%G<non-ascii char>%} to force a narrow character in my prompt also worked, as described in https://github.com/ohmyzsh/ohmyzsh/issues/7945#issuecomment-508724741, but I'm not sure if that's relevant to starship.

[LadySerena]

this solved my problem:

export LANG=C.UTF-8

Sorry to necro this thread, but while this fix works, you might want to use a finer grained locale variable. I found setting LC_CTYPE=C.UTF-8 did the same thing.

export LC_CTYPE=C.UTF-8

This is my current locales running on my machine.

❯ locale
LANG=en_US.UTF-8
LC_CTYPE=C.UTF-8
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE=C
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

See this commit for how I set this within my home.nix file. Consult locale(7) for more details.

[alxdb]

This seems to no longer be an issue for me?

I don't modify any locale env vars, and I don't get the duplication on tab complete any more.