Newline added to fish prompt #4032
Comments
|
kitty doesnt draw prompts. The shell does. From your screen shot you are running what you should be running is or really |
|
Sorry to open this again, however this doesn't solve my issue. |
|
As I said, kitty does not draw prompts, the shell does. There is nothing kitty can do about what the shell chooses to draw. And running kitty --config NONE -o shell=fish with the fish_prompt set to |
|
And looking at your issue this is with regards to shell integration? which is not released yet? |
|
I'm not sure, I just installed kitty and fish today and am just trying to get them to play nice together. So what would the next step be? If it is shell integration, how do I remove that from my kitty install? |
|
shell integration in kitty is not released. So where did you get kitty from? In any case if you want to disable it, use shell_integration disabled in kitty.conf. |
|
I installed |
|
And this will fix it even with shell integration: a073936 for future reference, please mention the version of kitty you are using. |
|
Let me explain the problem, @kovidgoyal: Fish executes fish_prompt, and then trims a trailing newline from its output. This is so simple prompts like function fish_prompt
echo $PWD '>'
endwork without us having to constantly explain to use However, because kitty adds more output after the actual prompt output, the newline now isn't trailing anymore, so fish won't remove it. Ideally, you'd be trimming the trailing newlines yourself, or we'd find some other way to add your prompt marker.
It won't. It'll break every multiline prompt, because fish splits command substitutions on newlines. The simplest solution I can come up with requires printing twice ( set --local op (_ksi_original_fish_prompt) # trim trailing newlines to mimic fish behavior
string join \n -- $op[1..-2] # notice no quotes, so the lines are passed separately
printf '%s' $op[-1] # print the last component without a newlineor, with just set --local op (_ksi_original_fish_prompt) # trim trailing newlines to mimic fish behavior
if set -q op[2]
printf '%s\n' $op[1..-2] # notice no quotes, so the lines are passed separately
end
printf '%s' $op[-1] # print the last component without a newlineI think that should cover all bases, but it's possible I've overlooked something. Splitting on newlines makes it super-easy to deal with line-based output, but also makes it easy to drop or accidentally add a newline somewhere, so this is probably more finicky than it needs to be. Sorry! |
|
My apologies, is |
|
On Wed, Sep 15, 2021 at 04:30:14AM -0700, Fabian Homborg wrote:
Let me explain the problem, @kovidgoyal:
Fish executes fish_prompt, and then trims a trailing newline from its output. This is so simple prompts like
```fish
function fish_prompt
echo $PWD '>'
end
```
work without us having to constantly explain to use `echo -n`.
Yes, I understood the issue.
However, because kitty adds more output after the actual prompt output, the newline now isn't trailing anymore, so fish won't remove it. Ideally, you'd be trimming the trailing newlines yourself, or we'd find some other way to add your prompt marker.
>And this will fix it even with shell integration: a073936
It won't. It'll break every newline prompt, because fish splits command substitutions on newlines.
I dont use fish, so I'm not familiar with its stdlib, however simply
doing (_ksi_original_fish_prompt | string collect)
instead of (_ksi_original_fish_prompt) will fix that, I think. Or are
there any other footguns I'm missing?
|
|
And @faho since you are around, any interest in integrating shell integration natively in fish. It will work with more than just kitty, at least iterm2 and wezterm also support it. |
function fish_prompt
echo $PWD '>'
echo
endit won't work (this should possibly be changed, but at the moment that's the way it is). Really, I think writing the last line out separately is the best choice here.
I'm okay with adding a lot of stuff, by default. However, I've explained my conditions before:
If there's gonna be a bunch of these sequences, there could even just be a $NUTERM variable that y'all could set, and it would guarantee to fish that these things would be safe to send. I've really lost my appetite for complicated terminal detection and bug reports for poorly behaving terminals, so if we're gonna add something I want it to not cause more problems. If that's given, sure, send the docs or (better) a patch. |
|
In case you're only reading email: I've edited in how to write it out in my comment before. |
It is but I havent memorized commit hashes, so when you are running from master its best to mention that fact or I wont notice. |
|
On Wed, Sep 15, 2021 at 06:01:52AM -0700, Fabian Homborg wrote:
In case you're only reading email: I've edited in how to write it out in my comment before.
Thanks, that helped. But in my testing I discovered another bit of
weirdness. A double trailing newline seems to insert a number of blanks
on the last line, corresponding to the number of printable characters on the
previous line. A test case:
```fish
function fish_prompt
echo one
echo -e "\e[33mXXXX"
echo
end
```
Gives a prompt:
```
one
XXXX
<cursor>
```
Notice that fish seems to insert a number of spaces equal to the number
of characters in the previous line at the start of the last line. And
this is number of printable characters, not string length. Is this
intended behavior?
If I use my wrapper function, this doesn't happen anymore:
```fish
function _ksi_end_prompt
set --local cmd_status "$status"
set --local op (_ksi_original_fish_prompt)
if set -q op[2]
printf '%s\n' $op[1..-2]
end
printf '%s' $op[-1]
set --global _ksi_prompt_state "prompt_end"
_ksi_mark "B"
return "$cmd_status" # preserve the value of $status
end
```
gives
```
one
XXXX
<cursor>
```
I guess this is because the new lines are not trailing anymore?
|
|
And using function fish_prompt
echo one
echo -e "\e[33mXXXX"
echo
echo
endgives a prompt of: No inserted spaces on the last line. So to summarise, with two trailing newlines, one gets inserted spaces on the last line, with three or more one does not. EDIT: I am guessing this is because ith three the penultimate line has no printable characters. So fish's prompt algorithm seems to be:
|
|
Ah, okay. I can reproduce that, even without an escape. It seems we're mistakenly starting at the last line's width instead of the beginning of the line in that case. It's a fish bug that I don't think you need to concern yourself with. |
Thanks to some assistance from @faho See #4032 (comment)
|
OK then thanks for your help I have committed the pure printf based |
This makes us start drawing the commandline at the beginning of the line again. See kovidgoyal/kitty#4032 (comment)
Describe the bug
When using fish with anything other than the default prompt, a newline is added between the prompt and the cursor.
Initially submitted as an issue with fish: fish-shell/fish-shell#8297 (where a lot more information can be found), who believe kitty is adding this newline
To Reproduce
Steps to reproduce the behavior:
fish_promptScreenshots
If applicable, add screenshots to help explain your problem.
The expected behaviour is:
Environment details
Additional context
Cursor still offset with
kitty --config NONEThe text was updated successfully, but these errors were encountered: