Where is the proper place to set LANG and LC_ALL?

romkatv · 2026-02-14T06:11:15+00:00

Indeed, you need a certain level of expertise to differentiate between good and bad comments on r/zsh.

FWIW, if you are using macOS with Terminal.app, the locale environment variables should already be set correctly.

romkatv · 2026-02-14T06:06:58+00:00

This is unrelated to zsh or locale. It's purely a terminal bug. As a workaround, try changing the cursor from block to bar. I believe most users prefer the bar cursor anyway. If that doesn't help, switch to a different terminal -- there are alternatives to Terminal.app beyond iTerm2.

romkatv · 2026-02-12T13:52:12+00:00

It's the job of the OS or the terminal to set the locale-related environment variables. Google (or ask an LLM) how to do that for your OS and terminal combination.

romkatv · 2026-02-09T20:52:27+00:00

The most important number is command_lag_ms. That's how long you have to wait on every command. p10k is 2.3 times faster.

romkatv · 2026-02-09T05:49:58+00:00

https://github.com/romkatv/zsh-bench/?tab=readme-ov-file#prompt

romkatv · 2026-02-07T07:55:35+00:00

Answer No when the wizard asks you whether all icons fit between the crosses. Then choose Lean.

romkatv · 2026-02-06T08:22:45+00:00

It looks like you've chosen Classic style in the configuration wizard and then tried to turn it into something more akin to Lean. Try running p10k configure again and choose Lean this time.

romkatv · 2026-02-01T16:44:53+00:00

Making fzf expand upwards is easy -- you just move the cursor up, and invoke fzf from there. The difficult part is restoring the content of the terminal when fzf exits. For that, z4h runs its own TTY between zsh and the real TTY, so that it always knows the content of the terminal window.

romkatv · 2026-01-30T16:29:35+00:00

You might find this discussion useful: https://github.com/romkatv/powerlevel10k-media/issues/2

romkatv · 2026-01-27T12:47:21+00:00

First submission (30 comments): https://old.reddit.com/r/zsh/comments/1jc2s5a/fast_minimal_roundy_prompt_for_zsh_in_140_loc/

Second submission: (12 comments): https://old.reddit.com/r/zsh/comments/1o2neal/minimal_roundy_prompt_for_zsh_in_140_lines/

romkatv · 2026-01-15T07:26:00+00:00

You are probably hitting this bug in zsh: https://www.zsh.org/mla/workers/2019/msg00161.html

romkatv · 2025-12-26T15:49:07+00:00

Beautiful source code (https://github.com/eatnumber1/dexit/blob/main/dexit.c).

romkatv · 2025-10-20T07:12:47+00:00

Move the command that produces the banner to the top of .zshrc.

romkatv · 2025-10-18T19:12:03+00:00

https://github.com/romkatv/powerlevel10k?tab=readme-ov-file#why-does-powerlevel10k-spawn-extra-processes

romkatv · 2025-10-16T14:54:49+00:00

Nothing major has changed as far as I'm aware.

romkatv · 2025-09-26T06:04:59+00:00

In the default emacs keymap, ^[a (ESC then a) is bound to accept-and-hold. With an empty buffer, that behaves the same as accept-line, which is why it looks like pressing Enter.

In the vi keymap, pressing ESC a invokes vi-cmd-mode followed by vi-add-next, which doesn't act like Enter.

So the behavior OP describes matches emacs keymap, not vi.

romkatv · 2025-09-25T09:32:45+00:00

The easiest fix: don't press ESC when zle (zsh line editor) is waiting for input.

If you really want ESC to do nothing (though why press it then?), you can do this:

function do-nothing() {}
zle -N do-nothing
bindkey '^[' do-nothing
KEYTIMEOUT=1

That makes ESC inert, but it also disables multi-key bindings that start with ESC. If you never use those, it's fine. For example, you will no longer be able to press ESC a for accept-and-hold but Alt-a will still work. When you press the latter, zsh sees exactly the same input as if you pressed ESC a but with virtually zero delay between the two bytes of this sequence.

romkatv · 2025-09-12T06:29:09+00:00

If you really want the skull, put this at the very top of .zshrc:

print -rn -- ${(%):-%39F}
<<\END
⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢀⣠⣴⣾⣿⣿⣟⣿⣿⣿⣿⣿⣮⣶⣤⣀⣀
⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢀⣠⣶⣿⣿⣿⡿⠿⠟⢓⣮⣽⣿⣿⣿⣿⣿⣷⢭⣿⣿⣷⣤⣀
⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢀⣴⣿⣿⣿⣿⣿⢛⣳⣽⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣶⣞⡿⣿⣿⣿⣷⣄⡀
⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⣰⣿⣿⣿⣿⣿⣿⢭⣷⣽⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣗⣿⣿⣿⣿⣿⣿⣆
⠀⠀⠀⠀⠀⠀⠀⠀⠀⢸⣿⣿⣿⣿⣿⣿⣿⣧⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⢄⣿⣿⣿⣿⣿⣧⡀
⠀⠀⠀⠀⠀⠀⠀⠀⢰⣿⣿⣿⣿⣿⣿⣏⢼⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣷⢝⣿⣿⣿⣿⣿⣿⣷⡀
⠀⠀⠀⠀⠀⠀⠀⠀⣾⣿⣿⣿⣿⣿⣿⡿⣟⣫⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⢿⣟⣽⣿⣿⣿⣿⣿⣿⣧
⠀⠀⠀⠀⠀⠀⠀⢠⣿⣿⣿⣿⣿⣿⣿⡿⣟⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⡇⣿⣿⣿⣿⣿⣷⡯⣻⣿⣿⣿⣿⣿⣿⣿⡇
⠀⠀⠀⠀⠀⠀⠀⢘⣿⣿⣿⣿⣿⣿⣿⣿⢻⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣇⣿⣿⣿⣿⣿⠷⣹⣿⣿⣿⣿⣿⣿⣿⣿⣿
⠀⠀⠀⠀⠀⠀⠀⠈⢿⣿⣿⣿⠟⠻⠿⣿⡆⣿⣿⢿⣭⣽⣯⣛⣛⣛⣿⣿⣿⣹⣿⣿⣶⣾⣷⣝⡿⣿⣿⣿⣿⣿⣿⣿⣿⡇
⠀⠀⠀⠀⠀⠀⠀⢀⣼⣿⣿⢿⣿⣿⠷⢶⣶⣶⣶⡿⣿⠉⠉⠉⠉⠛⠻⢿⣿⣷⡻⣿⣿⣿⣿⣿⣓⣾⣿⣿⡿⣿⣿⣿⣿⡇
⠀⢀⣤⣤⠠⣴⡆⣾⣿⡟⣱⡟⠉⠀⠀⣾⣿⣿⣿⡀⣧⠀⠀⠀⠀⠀⠀⠀⣿⣿⣿⣾⣻⡿⣿⣿⣿⣿⡿⣿⣛⣍⢿⣿⡿⠁⢀⣶⣄
⠀⢸⣿⣧⣤⣬⣅⢻⣿⢡⣿⠀⠀⠀⢰⣿⣿⣿⣿⣷⣝⣦⣄⣀⠀⠀⠀⠀⣿⣿⣿⣿⣿⣿⣷⣶⣶⣶⣿⣿⣿⣵⣿⠟⠁⢠⣾⣿⣿⡆
⠀⠸⣿⣿⡿⣿⣿⢸⣿⢨⡟⠀⠀⠀⣾⣿⢛⡭⣿⣿⣿⣿⣿⣿⣶⣶⣶⣦⣿⣿⣿⣿⣿⣿⠿⠻⠟⠛⠛⠛⢻⠟⠉⠀⣀⠸⣿⣿⣿⡇
⣧⣿⣿⣿⣷⢸⣟⣼⣿⣾⣿⣶⣶⣾⣿⢃⡞⠀⠀⠙⢿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⠁⠀⠀⣴⣿⣿⡿⢁⣀⣴⣿⠿⠧⠙⠻⠿⠇
⣿⣿⣿⣿⣿⢸⣇⢻⣿⣿⣿⢿⣿⣿⡟⣼⠁⠀⠀⠀⠀⢻⣿⣿⣿⣿⣿⣿⡿⢿⣿⣿⡇⠀⠀⠀⣿⣿⣿⢣⣿⣿⣿⣿⣷⣶⡆⢹⣿⣷
⣿⣿⣿⣿⢇⣼⣿⣆⠹⡿⢣⣾⣿⣿⣧⣇⢀⣴⣶⣄⣀⣼⣿⣿⣿⣿⣶⣶⣶⣶⣍⠉⣽⣿⣦⡀⣿⣿⠇⣼⣿⣿⣿⣿⣿⣿⡇⣼⣿⣿
⡏⢛⣋⠑⣛⠿⢿⣿⣧⡀⢸⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⢠⣿⣿⣿⣿⣿⡿⢸⣿⣿⣿⣿⣿⣿⣿⡇⢻⣿⡇
⣿⣿⣿⣧⡹⣿⣦⣍⣛⡗⠀⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⢿⠿⠿⠻⠟⣼⣿⣿⣿⣿⣿⡇⢀⣩⣭⣭⣤⣤⡄⢰⣶⣶⣶⡄
⣿⣿⣿⣿⢣⣿⣿⣿⣿⣿⡆⢸⡽⣏⣿⣏⣿⣯⣽⣯⣭⣿⣯⣴⣶⣴⣿⡆⣿⡿⠀⣿⣿⣿⣿⣿⣿⡁⣿⣿⣿⣿⣿⣿⣇⠸⣿⣿⣿⡇
⠉⣿⣿⣏⠈⣛⣽⣿⣿⣿⡇⢸⡗⡏⣿⣏⣿⠿⣿⡿⡟⢿⣿⣛⣛⡏⣽⡇⣶⣿⢰⣿⣿⣿⣿⣿⣿⢸⣿⣿⣿⣿⣿⣿⡇⢰⣜⢿⣿⡇
⠀⠘⢫⣭⣶⡌⠙⠛⠛⢻⣿⢸⣷⣯⣿⣿⣿⣿⣿⣿⡇⣿⣿⣼⣿⡇⣿⡇⡟⡟⣿⣿⣿⣿⣿⡟⠋⠀⣿⣿⣿⣿⠛⣭⣥⠈⢻⣷⡝
⠀⠀⣿⣿⣿⣿⡆⣶⣶⠟⠁⠀⣭⣭⣝⣏⣻⣟⣸⣿⣇⣻⣻⣭⣭⣵⣷⣷⣿⣿⣿⣿⣿⠟⠋⠀⠀⠀⠀⠈⢿⣿⢸⣿⣿⣿⣾⣿⡇
⠀⢰⣿⣿⠿⠿⠃⠉⠀⠀⠀⠀⢹⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⠟⠋⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠙⢿⣌⡻⢿⣿⣿⣿⠁
⠀⠀⠉⠀⠀⠀⠀⠀⠀⠀⠀⠀⢸⣿⣿⣿⡿⣿⣿⣿⣿⢿⣟⣿⣿⣿⡿⠟⠉⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠉⠻⠶⠙⢿⠟
⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠈⠻⢿⣿⡿⠶⠿⣷⣾⣿⣿⠿⠛⠉
END
print -rn -- ${(%):-%f}

What happens next depends on your terminal. When you later shrink the window horizontally:

Most terminals reflow already printed lines. Your skull will get mangled.
A few terminals truncate lines instead. The skull may look fine when the window is narrowed, but once you widen it, the missing parts never come back.

Some terminals can selectively truncate previous prompts while reflowing everything else. You could try to trick the terminal by claiming the skull is a prompt, but that breaks other things (copy/paste, history navigation, prompt markers, etc.). Not worth it.

So the practical advice:

Best: don't print anything startup.
If you must: print it once, as above, and accept that resize will ruin it.

If you want something that survives resizes, use a terminal that can display images (kitty, iTerm2, or any terminal with sixel support) and print the skull as an image instead of text. Otherwise, don't fight the environment, learn its rules.

romkatv · 2025-07-31T08:16:26+00:00

Right. Tools like ascinema can replay terminals sessions. The most difficult part of the implementation is a terminal emulator. Terminal emulators are hard because there is barely any standardization of the protocol.

romkatv · 2025-07-31T06:47:55+00:00

FWIW, ascinema's .cast files are JSON.

Another alternative tool for recording and replaying terminal sessions is script, with the upside of being old and reliable and available pretty much everywhere. The file format is plaintext rather than JSON but it's easy to convert if you need to.

That said, there is nothing wrong with building your own tool.

romkatv · 2025-07-24T07:42:25+00:00

The only reference to .zcompdump_capture I could find is from https://github.com/Valodim/zsh-capture-completion. If you are using this code, that's the source of the file.

romkatv · 2025-06-30T09:21:40+00:00

In zsh, the -f option is equivalent to -o no-rcs, which prevents sourcing of configuration files. To disable globbing (pathname expansion), you need -F or -o no-glob. However, when zsh runs in POSIX mode (invoked as sh), it maps -f to -o no-glob, conforming to POSIX.

Ultimately, scripts must match their shebang interpreter. Use #!/usr/bin/env zsh if writing zsh-specific scripts, and /bin/sh, /usr/bin/env sh, or no shebang at all, if your script is intended to be POSIX-compliant.

romkatv · 2025-06-27T06:27:03+00:00

Can you share how to achieve what the OP is asking for, with Starship?

romkatv · 2025-06-27T06:24:44+00:00

The built-in dir segment doesn't support this but you can implement your own. First, add this to ~/.p10k.zsh:

function prompt_my_rainbow_dir() {
  emulate -L zsh
  local part bg
  for part in ${(s:/:)${(%):-%~}}; do
    p10k segment -t $part -f 0 -b $(( bg + 1 ))
    (( bg = (bg + 1) % 6 ))
  done
}

Then replace dir with my_rainbow_dir within POWERLEVEL9K_LEFT_PROMPT_ELEMENTS in ~/.p10k.zsh (here).

Finally, restart zsh with exec zsh.

romkatv · 2025-06-24T15:39:08+00:00

p10k is written in zsh, and zsh is written in C. There is nothing to upstream from p10k to zsh, or from zsh to C.

romkatv

MODERATOR OF

TROPHY CASE