Add workaround for Midnight Commander's issue with prompt extraction #9540
Conversation
When we draw the prompt, we move the cursor to the actual
position *we* think it is by issuing a carriage return (via
`move(0,0)`), and then going forward until we hit the spot.
This helps when the terminal and fish disagree on the width of the
prompt, because we are now definitely in the correct place, so we can
only overwrite a bit of the prompt (if it renders longer than we
expected) or leave space after the prompt. Both of these are benign in
comparison to staircase effects we would otherwise get.
Unfortunately, midnight commander ("mc") tries to extract the last
line of the prompt, and does so in a way that is overly naive - it
resets everything to 0 when it sees a `\r`, and doesn't account for
cursor movement. In effect it's playing a terminal, but not committing
to the bit.
Since this has been an open request in mc for quite a while, we hack
around it, by checking the $MC_SID environment variable.
If we see it, we skip the clearing. We end up most likely doing
relative movement from where we think we are, and in most cases it
should be *fine*.
|
Good fix. Long term I'd like to remove the |
|
The |
|
Unfortunately, the So I would love if this could just be fixed in conhost, which has a billion dollar company behind it. Alternatively, I'm not sure if the move(0, 0) is the actual problem or the move after - is it possible we do cell-by-cell movement here and can that be changed? |
|
#8011 is only if right prompt exists (and it doesn't by default) so I think it's fine it ignore.
It could be the move after, I'm not sure. All I know is that I can see the cursor moving to the start of the line when doing heavy terminal output so it's a non-negligible amount of time. |
No, it's not. It started as that, then I noticed that it suddenly worked better with a right prompt, so I added it to the path without as well. What happens is that, without the move to the beginning, we depend on our width calculation for the prompt (including left!) being correct - and "correct" in the sense that it's the same result the terminal reached. If it's not, we can be off in all manner of ways. So, by moving to the beginning, we remove that and then go explicitly to the cell we want to draw the commandline in. So if we're off in the prompt calculation, we can both overwrite the prompt or leave a gap after the prompt, but we can never overflow the line because of errors there. That was a big issue that could render fish almost unusable, and was easily triggered with ambiguous-width codepoints. We've had it reported multiple times, and zero times since #8011. |
Description
When we draw the prompt, we move the cursor to the actual position we think it is by issuing a carriage return (via
move(0,0)), and then going forward until we hit the spot.This helps when the terminal and fish disagree on the width of the prompt, because we are now definitely in the correct place, so we can only overwrite a bit of the prompt (if it renders longer than we expected) or leave space after the prompt. Both of these are benign in comparison to staircase effects we would otherwise get.
Unfortunately, midnight commander ("mc") tries to extract the last line of the prompt, and does so in a way that is overly naive - it resets everything to 0 when it sees a
\r, and doesn't account for cursor movement. In effect it's playing a terminal, but not committing to the bit.Since this has been an open request in mc for quite a while, we hack around it, by checking the $MC_SID environment variable.
If we see it, we skip the clearing. We end up most likely doing relative movement from where we think we are, and in most cases it should be fine.
TODOs: