kitty is unable to determine that prompt is starting

[10b14224cc]

ble version:

NU bash, version 5.2.26(1)-release (x86_64-pc-linux-gnu) [Arch Linux]
ble.sh, version 0.4.0-devel4+838b4652 (noarch) [git 2.43.0, GNU Make 4.4.1, GNU Awk 5.3.0, API 4.0, PMA Avon 8-g1, (GNU MPFR 4.2.1, GNU MP 6.3.0)]
starship, version 1.17.1 (rustc 1.75.0 (82e1608df 2023-12-21) (Arch Linux rust 1:1.75.0-1), 2024-01-03 07:54:53 +00:00)
zoxide, version 0.9.2 (/usr/bin/zoxide)
atuin, version 17.2.1 (/usr/bin/atuin)
locale: LANG=en_US.UTF-8 LC_TIME=en_DK.UTF-8
terminal: TERM=xterm-kitty wcwidth=15.0-west/15.1-2+ri, kitty:0 (1;4000;32)

Using ble.sh, kitty @ get-text --extent=last_cmd_output returns the last prompt together with the last command output.

See also: https://github.com/mikesmithgh/kitty-scrollback.nvim/issues/179#issuecomment-1924045919 See also: https://github.com/kovidgoyal/kitty/issues/7099

To reproduce:

1. Issue

   echo "hello"
   echo "hi"

2. Press kitty_mod+g
3. kitty will page hi (output of last command) together with last prompt
4. Don't load ble.sh. Bug doesn't happen and kitty only page hi without the last prompt.

[akinomyoga]

Is the problem that you face only reproducible with Starship? I first tried it without Starship, i.e., just with kitty and plain Bash plus ble.sh, but there is already a problem, though I'm not sure if that is the identical problem as yours. Anyway, I'll fix the problem that I found in my environment.

[10b14224cc]

You are right. starship is unrelated to the issue and the issue happens also without starship.

Typing:

echo "hello"
echo "hi"

Pressing kitty_mod+g:

Without ble.sh:

With ble.sh:

I will modify the issue.

[10b14224cc]

issue still present with latest git.

[akinomyoga]

I took a look at this issue.

First of all, kitty's shell integration does something non-trivial. kitty disables the loading of ~/.bashrc and lets Bash instead load kitty's initialization script. Then, the user's ~/.bashrc is sourced from the kitty's initialization script. After loading ~/.bashrc, kitty's shell integration continues to set its PROMPT_COMMAND. However, as described in ble.sh's README, ble-attach needs to be executed at the end of ~/.bashrc, or more precisely ble-attach needs to be executed at the end of the shell initialization script. Any changes to PROMPT_COMMAND after ble-attach inside the initialization process will be discarded, which is to avoid the double execution of PROMPT_COMMAND by blesh and readline. So the PROMPT_COMMAND setting added by kitty after sourcing ~/.bashrc is discarded.

In this case, you need to give up the ble-attach approach (as kitty will never give up this approach). Then, the only way is to use the default approach (which is used when you just source ble.sh without passing --attach=none and don't call ble-attach). However, this is blocked by a bug in kitty's shell integration. I'll submit a PR. It is a trivial one, so I expect it's not so difficult to convince Kovid.

[10b14224cc]

I took a look at this issue.

First of all, kitty's shell integration does something non-trivial. kitty disables the loading of ~/.bashrc and lets Bash instead load kitty's initialization script. Then, the user's ~/.bashrc is sourced from the kitty's initialization script. After loading ~/.bashrc, kitty's shell integration continues to set its PROMPT_COMMAND. However, as described in ble.sh's README, ble-attach needs to be executed at the end of ~/.bashrc, or more precisely ble-attach needs to be executed at the end of the shell initialization script. Any changes to PROMPT_COMMAND after ble-attach inside the initialization process will be discarded, which is to avoid the double execution of PROMPT_COMMAND by blesh and readline. So the PROMPT_COMMAND setting added by kitty after sourcing ~/.bashrc is discarded.

In this case, you need to give up the ble-attach approach (as kitty will never give up this approach). Then, the only way is to use the default approach (which is used when you just source ble.sh without passing --attach=none and don't call ble-attach). However, this is blocked by a bug in kitty's shell integration. I'll submit a PR. It is a trivial one, so I expect it's not so difficult to convince Kovid.

Wow, that is turning out much more complicated than expected.

Thanks for the hard work!

[akinomyoga]

It's merged in kitty. It will be applied to the next release of kitty. After updating kitty to a fixed version, you can set up ble.sh using the auto-attach instead of using the manual attach (--attach=none and ble-attach).

# around the top of ~/.bashrc
[[ $- == *i* ]] && source /path/to/ble.sh

There's no fix on ble.sh's side.

[10b14224cc]

It's merged in kitty. It will be applied to the next release of kitty. After updating kitty to a fixed version, you can set up ble.sh using the auto-attach instead of using the manual attach (--attach=none and ble-attach).

# around the top of ~/.bashrc
[[ $- == *i* ]] && source /path/to/ble.sh

There's no fix on ble.sh's side.

So the suggestion to ALWAYS use the two part initialization scheme (one row at the top, one at the bottom) doesn't hold for kitty?

[akinomyoga]

Where is that suggestion? I have never written "always". Did anyone suggest you to use it always?

edit To answer the question, no, it doesn't hold for kitty.

[akinomyoga]

kitty version 0.32.2 seems to have been released two days ago. @10b14224cc Could you confirm that the issue is fixed?

[10b14224cc]

kitty version 0.32.2 seems to have been released two days ago. @10b14224cc Could you confirm that the issue is fixed?

Yes I don't see the prompt anymore. Thanks.

[akinomyoga]

Thanks!