Tab completion problem

[terry182]

I am having a problem using this theme when I try to tab complete

so it's like
▲ .oh-my-zsh/custom/themes ls
and after tab completion it becomes
▲ .oh-my-zsh/custom/themesls

I tried to modify the theme but failed. Really can't figure out where the problem is

[frm]

What OS and terminal emulator are you running, so I can try to reproduce the issue?

[terry182]

@frmendes I am using OSX El Capitan 10.11.5 (15F34). The emulator is the terminal.app (?

[frm]

@terry182 I can't seem to reproduce it. I have the same OS version and tried on Terminal.app. It works on both Terminal and iTerm2 on my end. Can you try and disable other plugins you have (preferably one at a time) to see if there's some side effect created by the theme?

[terry182]

@frmendes I didn't use any plugin as I just clean install my Macbook. But I notice that I am just using it as a theme, will that be the problem?

I just download the geometry.zsh and put it in ~/.oh-my-zsh/custom/themes and rename it.

FYI, I reproduce the result by pressing l, s, Tab in my end. Maybe this could help

[terry182]

I found the problem happens to be the international setting Unicode East Asian Ambiguous characters are wide of terminal.

I guess this issue can be closed.

[IanCStewart]

@frmendes it seems that tab completion adds a character to the sentence

if you type anything and then tab it changes from for example git to ggit
this is just visual, the commands still get send without the extra

[frm]

Does this happen by just typing <command> <tab>? What encoding are you using?

[IanCStewart]

it happens automatic when u type <command> <tab> & when you type <half command> <tab> and this half command has lots of possibilities. but not when you type <half command> <tab> and there is only one possibility. my encoding must be on the default don't know where to find this.

[frm]

What terminal emulator and OS are you using?

[IanCStewart]

iTerm and osx El Capitan

[frm]

You can check your encoding in Preferences > Profiles and then select the active profile (should probably the one with a ⭐️). Encoding is in the Terminal tab. Can you check it there, please?

[IanCStewart]

@frmendes my encoding is on unicode (UTF-8)

[andreabedini]

I am experiencing the same issue as @IanCStewart :-/

[andreabedini]

I can reproduce this reliably on iTerm 3.0.5 when I open a new shell. Here is a sequence of screen shots where I type 'l' and keep pressing TAB (note that there's no available ll command). Disabling the theme returns to the correct behaviour.

[andreabedini]

Update, this only happens if I set export GEOMETRY_SYMBOL_PROMPT="♦︎"

[frm]

@andreabedini @IanCStewart should be fixed by now. Sorry it took me so long.

It's ok on my end but can you confirm it, please? I'll re-open the issue if it persists.

[andreabedini]

@frmendes works now, thanks! all this is a bit above my head, could you say a word about why this was happening? btw I tried to hack a simple pyenv integration to your theme in 9b1c1ee

[frm]

To be honest, it was something pretty new to me as well. The relevant change is this line.

When you are using some special characters, like ♦︎, the terminal has a hard time determining their true width.

Zsh checks the full width of the prompt in order to place each character in the correct column of a line. With some characters, especially unicode, there was a tendency to over-estimate the character width.

If you Google around for zsh tab completion duplicate character you'll find a lot of recomendations saying to wrap the troublesome part in %{...%} to escape some color code sequences. This tells zsh the color codes have zero-width: they should be interpreted but don't occupy on-screen space, which intuitively makes sense.

However, if you try this in geometry, in the line I previously linked, you'll see that it starts ignoring the space after the prompt character, unless you are on a git repo. This ticked me off because it meant the width of the character assumed by zsh was definitely wrong.

Instead, I had to explicitly tell zhs the width of the prompt character, by wrapping it in %1{...%}.

I wouldn't have noticed it only happened with specific prompt characters without your comment, thanks for that one!

As for your comment, feel free to open a PR!

I'm not sure I want to bind geometry, to any particular language, which means I'd eventually put something for rbenv/rvm and nvm as well. I'm on the fence on how fast the version check is as well. geometry is starting to get a bit slow, especially in large repos. Maybe something as discussed in #6 would come in handy for this.

If you do open the PR, I'd like to discuss some options.

[IanCStewart]

@frmendes looks like its working just doing some weird indenting jumping stuff now. ass u can see below first it has more space then the space disappears

[frm]

That really shouldn't happen after the fix. Can you check if it happens with export GEOMETRY_SYMBOL_PROMPT="♦︎"? Besides that, can you provide the prompt character you are using?

[andreabedini]

just FYI I switched to ☁︎ and ☂ for GEOMETRY_SYMBOL_PROMPT and GEOMETRY_SYMBOL_EXIT_VALUE (thanks for the tip @IanCStewart!) and I can reproduce. The autocompleted command shifts left.

[frm]

I just pushed a fix for this.

There's a small caveat with it, though. Using unicode characters means I have to calculate the size of the prompt character. In some cases, such as ☁︎, zsh has some issues figuring out the prompt character columns and a space gets added after the prompt.

However, this only happens with some characters, as far as I could tell, which means I don't have a fix for it. It should be solved on a case-by-case basis, changing the prompt_geometry_render function on geometry.zsh to add/remove any extra space.

If someone finds a fix for that, I'd really appreciate.

[steinybot]

@fribmendes This seems to have reappeared after updating to macOS High Sierra v10.13.1 using iTerm2 v3.1.5. It works perfectly fine in Terminal. It was also working fine before updating the OS. The particular character that I have found that doesn't work is ⚡ (U+26A1).

[goliatone]

I'm having the same issue, removing the docker_machine plugin then it seems to work ok. Also, updating the value of GEOMETRY_SYMBOL_DOCKER_MACHINE to something else works

[frm]

@goliatone @lox is any of you running High Sierra?

[lox]

Yup, sure am!

[goliatone]

Yes

[jedahan]

So with inconsolata for powerline, that symbol seems to be 'double wide' I know almost nothing about unicode and font rendering, but thought I would share in case it would help someone who knows more.

[primalmotion]

Hi,

not sure if it's the exact same issue, but mine is doing some weird stuff too

High Sierra, iTerm 3.1.5, Roboto Mono as font

I also tried to do this

export GEOMETRY_SYMBOL_PROMPT="o"
export GEOMETRY_SYMBOL_RPROMPT="o"
export GEOMETRY_SYMBOL_EXIT_VALUE="o"
export GEOMETRY_SYMBOL_ROOT="o"

And it does the same thing

[nath1as]

Hi,
I'm on termite and get this issue when trying to set my symbols bold with \e[1m . Is there any way around the issue?

[frm]

Some news about this. The explanation is available in this comment and you can trace this back to f0973e9 which fixes it.

I didn't have this issue in Sierra, was finally able to upgrade to High Sierra and I am only able to reproduce it when I copy @steinybot 's character. Not when I hit cmd + ctrl + space and selected the thunder.

So I did the following in Ruby:

[1] pry(main)> steinybot_thunder = "⚡"
=> "⚡"
[2] pry(main)> apple_thunder = "⚡️"
=> "⚡️"
[3] pry(main)> steinybot_thunder == apple_thunder
=> false
[4] pry(main)> steinybot_thunder.codepoints
=> [9889]
[5] pry(main)> apple_thunder.codepoints
=> [9889, 65039]

I do believe nothing has changed in the meantime, it's about the different characters and their respective byte size. zsh has some issues calculating the byte size. The problem is that with @steinybot 's thunder emoji, there's only 1 byte in the string but probably it requires more than that in the screen? I'm not 100% sure on how UTF-8 works in this sense.

I'm not sure there is a fix required in this sense.

@primalmotion can you see if yours is related to #214 ?

EDIT: Apparently the thunders are not being displayed correctly in a code block. This is steinbot's thunder: ⚡. This is apple's: ⚡️. They look the same in the terminal but the byte size is different.

[frm]

@n-a-t-h-i-a-s bold is a bit more difficult. If I do GEOMETRY_SYMBOL_PROMPT="\e[1mA" then zsh detects the byte size as 6. However it should only occupy one symbol on screen (A). I'll try to get around this and see what I can do.

[frm]

@n-a-t-h-i-a-s I added some proposals to support that in #216

[frm]

Another update on apple emojis: 🌊 and 🤙 have one single codepoint, which means they share the same issue as the thunder I mentioned previously. I'm not sure how to handle this.

[jedahan]

fixed in v2 i think

[frm]

Here's a blast from the past.

This is currently happening to me by swapping the order of the plugins:

GEOMETRY_PROMPT=(geometry_newline geometry_path geometry_status)

With the above config, if I do ls<tab> it converts to lls. Still haven't quite got to the root of the problem

[frm]

Seems to be geometry_newline, the \r in particular.

GEOMETRY_PROMPT=(geometry_path geometry_status) works.

[jedahan]

hmm i forget the history of why we needed \r - I believe it had to do with weird spacing with non-simple-width prompt

[jedahan]

#100 related

I wonder if \r\n works

[jedahan]

\n\r is even worse lol

[frm]

So, \n doesn't work but \n\r does (I also tried \r\n and had a laugh as well). Assuming it has to do with string termination, we could go with \n\0 which does seem to work 🤔

Although I'm curious as to why

[frm]

Fixed by #298