search

akinomyoga / ble.sh

Bash Line Editor―a line editor written in pure Bash with syntax highlighting, auto suggestions, vim modes, etc. for Bash interactive sessions.
BSD 3-Clause "New" or "Revised" License
2.33k stars 77 forks source link

[Alacritty v0.7.0-0.13.1] Newlines inserted when scrolling up #434

Closed teutat3s closed 2 months ago

teutat3s commented 2 months ago

ble version: 0.4.0-devel4+27e6309 Bash version: 5.2.15(1)-release (x86_64-pc-linux-gnu)

When scrolling up in bash with ble.sh installed, and with previous output above, I can observe two newlines being inserted at the top of the terminal. I am looking for debugging guidance to better understand why this happens - and to find out if this is a problem in ble.sh or something else causing this. If desired, I can try to record a short video to show the problem in action.

What I have tried:

Other installed components:

akinomyoga commented 2 months ago

Thanks. The problem doesn't seem to arise in my environment.

$ ble/widget/display-shell-version
$ INPUTRC=/dev/null bash --norc --noprofile
$ source out/ble.sh --norc --noinputrc
$ eval "$(starship init bash)"
$     # <-- check if the problem reproduces
teutat3s commented 2 months ago

Thank you for the debugging help!

❯ ble/widget/display-shell-version
GNU bash, version 5.2.15(1)-release (x86_64-pc-linux-gnu) [NixOS 23.11 (Tapir)]
ble.sh, version 0.4.0-devel4+27e6309 (noarch) [git 2.42.0, GNU Make 4.4.1, GNU Awk 5.2.2, API 3.2, PMA Avon 8-g1]
bash-completion, version 2.11 (hash:deb4862e60d728757fcb1067b689fd4d35c3fbe4, 76396 bytes) (noarch)
fzf key-bindings, (hash:18db7a864d576755199efdfee73ff29345833da7, 5577 bytes) (noarch)
WARNING: fzf integration "integration/fzf-key-bindings" is not activated.
starship, version 1.17.1 (rustc 1.73.0 (cc66ad468 2023-10-03) (built from a source tarball), 1980-01-01 00:00:00 +00:00)
locale: LANG=en_US.UTF-8
terminal: TERM=xterm-256color wcwidth=15.0-west/15.1-2+ri, alacritty:1901 (0;1901;1)

I was not able to reproduce the problem with only plain ble.sh plus starship, following your commands. That hints at something in my config that inserts those newlines. Do you have any idea where to look?

teutat3s commented 2 months ago

I have to add, I cannot reproduce the problem with plain bash + starship. When running the commands you mentioned, I get this when trying to source ble.sh:

❯ INPUTRC=/dev/null bash --norc --noprofile

bash-5.2$ echo $(blesh-share)/ble.sh
/nix/store/5cjglj17b6a1jgy45brmv6p92ah175dm-blesh-27e6309ef2344d37a6cec49f37b958c70f660472/share/blesh/ble.sh

bash-5.2$ source $(blesh-share)/ble.sh --norc --noinputrc
ble.sh: ble.sh is not intended to be used with the line-editing mode disabled (--noediting).

bash-5.2$ eval "$(starship init bash)"
akinomyoga commented 2 months ago

I was not able to reproduce the problem with only plain ble.sh plus starship,

I'm confused. Let me confirm. Does that mean Bash works with the plain ble.sh plus starship without problems? Or does it mean just you couldn't test it because ble.sh is not loaded? In the next reply, you've posted another result, but is it the same as the one you first tried? Or do you try that in a separate environment, which produced a different result?

akinomyoga commented 2 months ago 
bash-5.2$ source $(blesh-share)/ble.sh --norc --noinputrc
ble.sh: ble.sh is not intended to be used with the line-editing mode disabled (--noediting).
$ type -a bash
$ ls -la "/proc/$$/exe"
teutat3s commented 2 months ago

Sorry for the confusion. I first though the message from ble.sh was just a warning, but then noticed it was an error and it did not start. That's why I couldn't test it yet, because ble.sh was not loaded.

EDIT: To give you some additional context, this is my bash / ble.sh config. EDIT2: By commenting out parts of initExtra, I have tracked it down to some ble.sh option in lines 43 - 90. But I have no idea yet which one it might be. EDIT3: Further tracked down to lines 74 - 90, where I configure vim mode for ble.sh. :mag: :detective:

teutat3s commented 2 months ago

Okay, I found out that somehow enabling vim mode in ble.sh triggers the newlines being inserted at the top in my environment.

if [[ $- == *i* ]]; then # in interactive session
  set -o vi
fi

Without these lines in my config, all is well. How would I continue to debug this?

teutat3s commented 2 months ago

Another hint, I tried out the change mentioned in this comment to see if anything changes and IT DOES fix the newlines being inserted for me.

akinomyoga commented 2 months ago

Maybe do you set add_newline = true in your starship configuration? If that Starship setting outputs something in evaluating PROMPT_COMMAND, it might cause the shift of the cursor position in the terminal display when there is a vi-mode indicator. If you would like to achieve the behavior add_newline with ble.sh, could you set add_newline = false in the starship configuration and instead use ble.sh's bleopt prompt_ruler=empty-line?

Or it causes a small delay, but you might set bleopt prompt_command_changes_layout=1.

teutat3s commented 2 months ago

I have that starship option set to false.

akinomyoga commented 2 months ago

Thank you. Hmm, then my guess was not correct.

Could you check if the situation changes when you set bleopt prompt_command_changes_layout=1?

teutat3s commented 2 months ago

I have tried with bleopt prompt_command_changes_layout=1 just now and the problem is still there.

akinomyoga commented 2 months ago

Sorry for the delay. Currently, I don't have an idea. I'll take a look at your settings again later.

akinomyoga commented 2 months ago

@teutat3s After some investigations, this finally turned out to be a bug of Alacritty in v0.7.0..0.13.1 (https://github.com/alacritty/alacritty/pull/7725). It is fixed in the latest version of Alacritty. Which version of Alacritty do you use? Could you update Alacritty to the latest version (v0.13.2)?

I could reproduce the reported behavior in Alacritty, but it seems like a quirk of Alacritty. Alacritty behaves in a strange way even without ble.sh. In the plain Bash (without ble.sh or any other settings), the following command inserts `99\n100\n98` at the end of the scrollback in Alacritty 0.12.3 (Fedora 39): ```bash $ seq 100; tput cuu 3 dl 3 ``` The scrollback becomes like this ``` 70 71 99 # <-- 100 # <-- 98 # <-- Those three lines are inserted 72 73 ... 97 ``` I checked the behaviors of the other terminal implementations as follows, but any other terminals do not behave in a way Alacritty does (I also tried `st` but realized that it doesn't have a scroll buffer). - xterm - terminator (vte based) - konsole - urxvt - kitty - terminology - wezterm - mintty - mlterm - tmux - screen I also noticed that this quirk doesn't exist in Alacritty 0.13.2 (Arch Linux). I built different versions of Alacritty from the source. The strange behavior seems to exist in v0.7.0..0.13.1. I've bisected the behavior change. The strange behavior was introduced in commit https://github.com/alacritty/alacritty/commit/4975be29df848db9b339b5390290e4eb2ac8e140 and fixed in commit https://github.com/alacritty/alacritty/commit/f1853a031d52f6964bbf368d2975767449fc4814. - v0.5.0 ok - v0.6.0 ok - v0.6.2 bad(this seems a fake tag) - 26479bb9 ok - e924c844 ok - 4975be29 bad(quirk) - 6e1b9d8b bad(quirk) - v0.7.0-rc1 bad(quirk) - v0.7.0 bad(quirk) - v0.8.0 bad(quirk) - v0.10.0 bad(quirk) - v0.11.0 bad(crash) - v0.12.3 bad(quirk) - v0.13.0-rc1 bad(quirk) - v0.13.0 bad(quirk) - v0.13.1 bad(quirk) - de12f03 bad(quirk) - f1853a0 ok - v0.13.2 ok - master ok https://github.com/alacritty/alacritty/commit/f1853a031d52f6964bbf368d2975767449fc4814 is associated with https://github.com/alacritty/alacritty/pull/7725.
teutat3s commented 2 months ago

Nice bug hunting, thanks! I can confirm updating to the latest alacritty version fixes the issue here. :raised_hands: :tada:

akinomyoga commented 2 months ago

Thank you!