-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
mc doesn't fully resize itself if reading directory while terminal's resized #4630
Comments
|
|
thinking big here, the obviously correct solution would be porting mc to the glib main loop, which would properly synchronize signal delivery, thus finally resolving the various race conditions related to sigwinch in particular.
this isn't a trivial project, but it also isn't huge. it might be actually faster to pull it off instead of investigating the issues of the current code. |
I agree with you, and I think Andrew would agree as well. Sadly, such a project is currently not something I could undertake. If someone would like to / could do it, patch with tests would be most welcome. |
Branch: 4630_resize |
master
4630_resize
FYI: typos in commit messages - (ialog_change_screen_size) in bbcfd02 and using retuirn value in a42fe0 |
|
Important
This issue was migrated from Trac:
zaytsev
(@zyv)michael@….org
Forwarding the bug from Debian - https://bugs-devel.debian.org/cgi-bin/bugreport.cgi?bug=1060651 :
If a terminal window's resized at a "bad time", mc's panels seem to keep
their old sizes indefinitely--even I press CTRL-L or navigate to another
directory. Oddly, the command bar at the bottom of the screen ("1Help",
etc.) does seem to be drawn with the proper width, but not on the proper
line. The rest of the interface doesn't react at all.
I sometimes notice this if I navigate into a large directory, and resize
the window while the "spinner" is animating at the top-right corner. It
can be difficult to reproduce once Linux has the data cached.
I've had some luck using an LD_PRELOAD library that hooks readdir() with
a usleep() call inserted. I'll attach that. To use it:
When mc clears the screen and starts animating the "/" at the top-right,
enlarge the terminal window. I'm using urxvt (rxvt-unicode).
I'm experimenting with an automated version of this test, but don't know
how reliable it will be.
The attached test case seems able to determine the width of the panels.
Without proper xterm-control and UTF-8 parsing, it may be fragile.
To build and run:
Or run "./a.out -P" to skip the $LD_PRELOAD setting, in which case the
signal isn't likely to come during readdir() and we'll measure a width
of 90 columns, as expected. So, I suspect it will print "PASS" if the
bug is fixed, but I don't know for sure.
It looks like the spinner--rotate_dash()--is actually the culprit. That
calls mc_refresh(), which empties sigwinch_pipe before do_nc() makes its
first dlg_run() call:
It's dlg_run() that will put the file browser into the top_dlg list; but
top_dlg is still empty in the above backtrace, so no MSG_RESIZE messages
are sent. If SIGWINCH comes at the "expected" time, I see this:
Simply sticking a "return" at the top of rotate_dash() makes the problem
unreproducible, and gives me a PASS from the test case. Something like
a global 'is_ready' flag might be a better way to do it; or just ensure
dialog_change_screen_size() doesn't flush the pipe if the dialog list is
empty.
While debugging this, I noticed a related bug in toggle_subshell(),
which has this code:
If a SIGWINCH were handled after setting was_sigwinch to 0 but before
flushing the pipe, the SIGWINCH would be missed. I never saw it happen,
but it could be easily fixed by replacing that code with:
and making that function return the appropriate boolean value.
Setting g->winch_pending in group_init() also works, and I don't imagine
it would have any negative effect.
Note
Original attachments:
zaytsev
(@zyv) onJan 12, 2025 at 10:55 UTC
zaytsev
(@zyv) onJan 12, 2025 at 10:55 UTC
The text was updated successfully, but these errors were encountered: