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

[teutat3s]

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:

• the issue does not occur when using plain bash without ble.sh

Other installed components:

• starship

[akinomyoga]

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

• Q1: What is the result of the following command?

$ ble/widget/display-shell-version

• Q2: What is your terminal and its version? Do you also use the terminal multiplexer?
• Q3: Does the problem reproduce in the sessions with only plain ble.sh plus starship (as started in the following way)?

$ INPUTRC=/dev/null bash --norc --noprofile
$ source out/ble.sh --norc --noinputrc
$ eval "$(starship init bash)"
$     # <-- check if the problem reproduces

[teutat3s]

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]

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]

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]

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).

• Q4: Did you run this inside nix-shell, nix shell, or nix develop? The bash binary provided in those environments is a dumb binary that is not intended for interactive use so is not suited for testing the behavior.
• Q4a: If the answer to Q4 is yes, how about the result of Q3 outside those envionments?
• Q4b: If the answer to Q4 is no, what are the results of the following commands?

$ type -a bash
$ ls -la "/proc/$$/exe"

[teutat3s]

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.

• Q4: Thank you for the pointer, it looks like I accidentally DID run this inside a nix shell without noticing.

• Q4a: The answer to Q4 is yes 😇

• Q3: We're back to my initial response. 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?

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. 🔍 🕵️

[teutat3s]

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]

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]

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]

I have that starship option set to false.

[akinomyoga]

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]

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

[akinomyoga]

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

[akinomyoga]

@teutat3s After some investigations, this finally turned out to be a bug of Alacritty in v0.7.0..0.13.1 (alacritty/alacritty#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):

$ 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 alacritty/alacritty@4975be2 and fixed in commit alacritty/alacritty@f1853a0.

• 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

alacritty/alacritty@f1853a0 is associated with alacritty/alacritty#7725.

[teutat3s]

Nice bug hunting, thanks! I can confirm updating to the latest alacritty version fixes the issue here. 🙌 🎉

[akinomyoga]

Thank you!