window size fwobling it up again

DNDEBUG commented 2 years ago

testing the columns thing

https://user-images.githubusercontent.com/98880063/164946097-23fb86b6-376c-4e4c-886b-ce90bb485a5e.mp4

DNDEBUG commented 2 years ago

also wtf is it 1|4|7 2|5|8 3|6|9

leo-arch commented 2 years ago

This is not exactly the same issue we had before: what I fixed before was the suggestions thing, which, being dependent upon the window size, is related to this, but not the same thing. I was already aware, specially since I was playing around with tilling window managers, that the interface (the files list) won't update automatically upon resizes: you need to refresh the screen manually (rf).

It's not just a matter of adding a screen refresh routine triggered after each screen resize. This works fine provided we have a small list of files, but could become annoying when it comes to large amount of files, for example /bin.

It's an implementation decision. Still trying to figure out the best approach to keep things ordered.

leo-arch commented 2 years ago

As to the columns issue, I'm running CliFM now on i3 using xterm as terminal emulator and cannot reproduce this issue. When I create a new window and close it, the area covered by the new window remains black (instead of being updated), while the unaffected part of the screen is fine. This is the issue I was talking about. But I'm not getting messed up columns.

The video starts with columns already messed up. Could you describe how to get them messed that way?

DNDEBUG commented 2 years ago

just make it like the first list but fit it horizontally 1: file1 2: file2 3: file3 4: file4 lets say a file has a long name it wont fit so instead of 1: file1 2: file2 3: file3 4: file_with_long_name do 1: file1 2: file2 3: file3 4: file_with_long_name

so its just the first list, but only for things that can fit in a column

DNDEBUG commented 2 years ago

the video starts with everything nomal i just open some windows to change the size and things get messed up

maybe you could set an warning like other programs do "the window needs to be the size XxW"

leo-arch commented 2 years ago

Great. So, it happens only when you list files horizontally instead of vertically, isn't it?

DNDEBUG commented 2 years ago

yeah

DNDEBUG commented 2 years ago

https://user-images.githubusercontent.com/98880063/164951901-927fd3e8-c0b3-4e5d-9ced-9135714c818d.mp4

example with ccmake

leo-arch commented 2 years ago

I see.

Trying to reproduce the issue now. But I'm not sure why your video shows the files list being updated upon window's resize. It shouldn't: I do was playing around with automatic screen refresh, but since I didn't get yet the expected results, removed that code.

DNDEBUG commented 2 years ago

maybe it depends on the terminal? the first resize changed the amount of files vertically but at some point the text started to be cut

leo-arch commented 2 years ago

It might be a terminal thing. I have observed before some columns issue with aterm (which isn't able to adequately render some fonts). But that's it.

Btw, since a few versions ago, trimming file names down to 20 chars is the new default. Maybe this prevents that issue.

leo-arch commented 2 years ago

Try installing the latest version with a fresh config file.

DNDEBUG commented 2 years ago

i am

leo-arch commented 2 years ago

Could you try with a different terminal? If you're using the latest version, and a fresh config file, I still don't get why the files list is automatically updated and file names not trimmed down.

DNDEBUG commented 2 years ago

https://user-images.githubusercontent.com/98880063/164953336-80261e3b-d27d-41d7-ba1b-5014970e4a51.mp4

vte2.91

https://user-images.githubusercontent.com/98880063/164953341-ee5a2f10-6e4f-497b-b3df-9a1adf2590cc.mp4

zutty, the black thing happens

https://user-images.githubusercontent.com/98880063/164953351-ddf5643d-4460-42af-a1a5-79dbbcdcbf90.mp4

lxterminal

i believe lxterminal uses vte too

leo-arch commented 2 years ago

Reproduced!

leo-arch commented 2 years ago

Well, it's not CliFM who's refreshing the screen on resize, but the terminal emulator itself. However, I've tried a few other file managers and, despite getting the same behavior (the terminal performs the screen refresh itself), thing don't get messed up (maybe because they're all curses based, while CliFM isn't). And this is the expected behavior of course.

I'll keep working on this.

leo-arch commented 2 years ago

The feature is called rewrap on resize. In vte-2.9 it could be disabled via the -R,--no-rewrap switch.

EDIT: I've found qterminal, evilvte, and vte (legacy, 0.28.2) to behave quite nicely in this regard. Also, neither xterm nor st, rxvt, eterm, and aterm, at the very least, enable rewrap on resize by default.

Sadly, most modern terminal emulators rewraps upon resize. I need to find a workaround for this.

leo-arch commented 2 years ago

After some testing and research I can conclude that this issue is not directly related to CliFM, but to non-curses programs printing directly to STDOUT in general. The terminal emulator, provided it rewraps on resize, messes up the current screen content (you need to resize to the original screen size to get the correct output back).

For example: run ls(1) on lxterminal, resize the terminal window and you'll see the same distortion you observed in CliFM.

DNDEBUG commented 2 years ago

you should set a window size limit

leo-arch commented 2 years ago

Hi @DNDEBUG. After a few tries I came out with this solution:

The files list is refreshed upon window's resize
Minimum screen size is 20x3: below this values, a message is displayed

However:

The values for minimum screen size are arbitrary. Having a minimum doesn't make much difference. We could have none at all. Based on what criteria should we set these values indeed?
Refreshing the files list is fine provided the amount of listed files isn't huge. This feature might become annoying and slow if you have, say, 10000 files or more. This also depends on your terminal emulator: some old/basic/minimal terminals (like aterm) are really slow at rendering characters on the screen. Setting a maximum amount of files below which the screen is refreshed, on the other side, is also completely arbitrary.
After a screen refresh, the prompt is not completely reprinted, but only the last line. Not a big issue, but still.

DNDEBUG commented 2 years ago

i believe the size limit should be based on the amount of horizontal text so i could have a big screen and have a very small window and a small window with small text etc

this shouldn't be the default as the horizontal file isn't the default so you should specify this in the documentation if Y then X

vte and opengl terminals are mostly used so they are the ones that should be expected to be used by most people and these don't have such problems as being slow and having text rendering problems

you should add a mode for slow rendering like for example a page mode show 10 items, and the user can move around the pages go thought the file list instead of scrolling stuff

render once X amount of files, then render the next page if the user moves to the next page

i hope you get my idea

leo-arch commented 2 years ago

I'll keep working on it. Thanks for your suggestions!

Please give this new feature a try and tell me whether we can close this issue.

leo-arch commented 2 years ago

After a screen refresh, the prompt is not completely reprinted

Fixed.

DNDEBUG commented 2 years ago

there needs to be a logic on how things work but there are limitations that need to be accepted

leo-arch commented 2 years ago

Which are exactly those limitations? How that logic would be?

It's always possible to improve the implementation.

DNDEBUG commented 2 years ago

the terminal can only render text of course one can fiddle with unicode lines, use fancy fonts or that w3m thing to render images but the termainal is limited to text only and what it can do with text and the tecnology of what it does with the text if you implement something to work with vte it might not work on st

leo-arch commented 2 years ago

Well, that's one of the drawbacks of not working with the curses library. However, I think this new refresh on resize feature works quite fine and makes CliFM much more tilling WM/terminal multiplexer-friendly.

leo-arch commented 2 years ago

Hey @DNDEBUG! I've been working on this for the last few days, this time testing directly on a tiling WM (i3), and I think I finally got a quite decent implementation, specially regarding screen updates when opening files or running applications.

You might want to take a look at this. Any suggestion is welcome!

DNDEBUG commented 2 years ago

working great, no complaing for now i'll keep lookink for problems i will close it for now, but if anything comes i'll open it again

leo-arch commented 2 years ago

Hi @DNDEBUG! I completely refactored the refresh on resize feature due to serious inconsistencies and bugs I've found in the previous implementation.

We basically hit here the limits of a pure text file manager: handling screen contents without a screen handling library (like curses) proved to be a true mine field: event signals (mostly SIGWINCH), synchronous and asynchronous events, forbidden functions (like printf(3)) inside signal handlers, unexpected/unmanageable screen events (due to the asynchronous nature of signals), external applications taking the whole screen corrupted, unrecoverable freezes, and so on, and so on.

The new implementation avoids all these pitfalls, at the expense of some automation though. Take a look at the note I wrote apropos.

Please give it a try and tell me what you think. Of course, fell free to reopen this issue if necessary.

leo-arch / clifm

window size fwobling it up again #123