Cmdline cursor misplaced after a resize in viewer

[egmont]

• View a file with F3 using the builtin viewer
• Resize the terminal window
• Quit the viewer
• Notice that the cursor is misplaced. It is in the command line, but in the wrong column: there's lot of room between the prompt and the cursor. (Note that the command that's being edited, if any, is also misplaced.)
• It doesn't jump back on Ctrl-L, but it jumps back as soon as the prompt changes (you switch directory).

(This bug was driving me crazy for many years now, and I was never able to reproduce... How come that for years I didn't think it was the terminal resize that triggers it?!? :))

[egmont]

My findings so far:

The bug only occurs with subshell enabled.

When resizing the window while in the viewer, the subshell resizes itself and hence prints its prompt again. This is captured and processed by mc.

src/filemanager/layout.c:setup_panels() is executed and recalculates properties of the panel, but for some reason this time mc_prompt does contain all the invisible characters, they are not stripped off, hence size calculation goes wrong.

[egmont]

fix - please review :)

[egmont]

Please see the attached patch, thanks!

[andrew_b]

The problem is more complicated than it seems at first look.

Branch:2678_resize_layout_fix (parent: master).
Initial changeset:59ba60e3e89309dec6a569dd178d0a42f5c617b4

[egmont]

Hi Andrew,

I applied your patch on top of 4.8.0, and it doesn't fix the problem I reported. Maybe it fixes something else, I don't understand your patch, but the prompt issue remains: the prompt is still read and stored in its raw value (including invisible characters) and this procedure is aborted without stripping off those invisibles, if mc is resized while builtin viewer or editor is open.

In normal circumstances, I found that there's only one invisible thing appended to the prompt; this might depend on shell version and may not exist on some systems, I'm not sure. The bug is more prominent if the prompt expilcitly contains invisibles such as bold, e.g. put this in your .bashrc:

export PS1=$'\\[\e[1m\\]boldprompt$ \\[\e[0m\\]'

You might have fixed something else indeed, in which case maybe both of our patches should be applied? :)

[andrew_b]

Replying to egmont:

You might have fixed something else indeed, in which case maybe both of our patches should be applied? :)

Yes, both. The bugfixing commit is second one in the branch. You can apply only that to check whether the bug is fixed or not.

1st commit optimizes the SIGWINCH handling. This is preparation for the main fix. Without that, when editor or viewer is open and window is being resized, the setup_panels() is called for invisible panels each time when SIGVINCH is raised. That can be many times. Now panels are updated only once when they are shown again after editor or viewer close.

[egmont]

Indeed, you're right. I guess it's time for me to finally learn git :) I just saw one changelist (the one linked above in this bug), didn't think there was another one accessible from there. Thanks!!!

[egmont]

Just fyi: Stress-testing your change revealed another, independent bug: #2684. Depending on the way the window manager sends resize events to the terminal, and then on the way the terminal sends it to the application (continuously during dragging, or just once, or something in between), this current changeset might trigger that bug more often for some people and less often for others.

[andrew_b]

Merged to master.
changeset:ae40921783a32e00a2ffd001fd2b7bc6c163c475

git log --pretty=oneline 91ab327..ae40921

[andrew_b]

Cherry-picked to 4.7.5-stable.
changeset:db703b88cd0043d4833e09597be2d01c64a1cd46
changeset:0194c42d9ae32e8021e50be5c3188f89a3a34492