Search code examples
fish

Scrolling "too long" command doesn't work properly

Assume I want to invoke a tool with a lot of options, like:

$ somescript --option1 --option2 --option3 --option4 --option5 whatever even more stuff

But the width of the terminal doesn't allow to have that thing on a "single line".

That alone isn't a problem, but with fish, there is a problem with scrolling.

When I enter that extra-wide command, at some point, there will be a line break:

$ somescript --option1 --option2 --option3 --option4 --option5

whatever even more stuff

All fine so far. While typing such a lengthy command, I can scroll forth and back at any point. Works as expected. So, assume I entered the command, made a mistake, and now want to remove --option4.

The normal thing: use "arrow up" to get to that command in the history, to then use "arrow left" to scroll within the command. And now something weird happens.

Everything is fine while the cursor is within the second line. But when the cursor moves to the first line ... after 3 to 5 more "arrow left" strokes, the cursor moves UP another line. Then it sits above the first line of the command. There is also a vertical jump of a few characters.

In other words: as soon as a command is longer than the width of the terminal, I am unable to scroll into the first line reliably. The cursor shows up somewhere, and it is really hard to guess where it really sits at any moment. Which makes it almost impossible to edit anything in that first line.

This is on MacOs, using iterm 3.2.9 and fish version 3.0.2 installed via brew.

Solution

  • Wrote up defect 6014 on github. Outcome is rather frustrating.

    The problem is: the Mac terminal(s) all handle certain unicode characters the wrong way. "Normally" that isn't a problem, but when you use one of those fish prompts that give you the git status (like AcidHub which is my favorite) ... fish can't compute/determine the exact line width, and there you go.

    So, basically, when using fish on MacOs, option space is limited to:

    • use the defaults, which (when using special prompts, like AcidHub will lead to scrolling issues)
    • adapt the fish prompt accordingly (in my case, I replaced all special unicode chars with something simpler). It doesn't look that great, but scrolling simply works again.

    And a completely different and unexpected solution to the problem: I am using iterm2 on my Mac, and iterm2 just added a "status bar" section. That can be easily configured, and of course, it already has a status bar component that tells you about git status.

    Thus my solution: I changed the fish prompt to just give the PWD, and all the other things that the AcidHub prompt has to offer, are now "iterm2 status bar" components!