Ticket #2678 (closed defect: fixed)

Opened 8 years ago

Last modified 8 years ago

Cmdline cursor misplaced after a resize in viewer

Reported by: egmont Owned by: andrew_b
Priority: minor Milestone: 4.8.1
Component: mc-core Version: 4.8.0
Keywords: Cc:
Blocked By: Blocking:
Branch state: merged Votes for changeset: committed-master committed-stable

Description

  • 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?!? :))

Attachments

mc-4.8.0-prompt.patch (1.7 KB) - added by egmont 8 years ago.
fix - please review :)

Change History

comment:1 Changed 8 years ago by 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.

Changed 8 years ago by egmont

fix - please review :)

comment:2 Changed 8 years ago by egmont

Please see the attached patch, thanks!

comment:3 Changed 8 years ago by andrew_b

  • Status changed from new to accepted
  • Owner set to andrew_b
  • Branch state changed from no branch to on review
  • Milestone changed from Future Releases to 4.8

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

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

comment:4 Changed 8 years ago by andrew_b

  • Keywords stable-candidate added

comment:5 follow-up: ↓ 6 Changed 8 years ago by 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? :)

comment:6 in reply to: ↑ 5 Changed 8 years ago by 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 raises. That can be many times. Now panels are updated only once when they are shown again after editor or viewer close.

Last edited 8 years ago by andrew_b (previous) (diff)

comment:7 Changed 8 years ago by 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!!!

comment:8 Changed 8 years ago by 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.

comment:9 Changed 8 years ago by slavazanko

  • Blocking 2686 added

comment:10 Changed 8 years ago by slavazanko

  • Votes for changeset set to slavazanko

comment:11 Changed 8 years ago by angel_il

  • Votes for changeset changed from slavazanko to slavazanko angel_il
  • Branch state changed from on review to approved

comment:12 Changed 8 years ago by andrew_b

  • Status changed from accepted to testing
  • Votes for changeset changed from slavazanko angel_il to committed-master
  • Resolution set to fixed
  • Branch state changed from approved to merged
  • Milestone changed from 4.8 to 4.8.1

Merged to master.
changeset:ae40921783a32e00a2ffd001fd2b7bc6c163c475

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

comment:13 Changed 8 years ago by andrew_b

  • Blocking 2686 removed

comment:14 Changed 8 years ago by andrew_b

  • Status changed from testing to closed
  • Keywords stable-candidate removed
  • Votes for changeset changed from committed-master to committed-master committed-stable
Note: See TracTickets for help on using tickets.