OS X 10.13.4 complete freezes on scrolling and the scrolling is not smooth enough.

[TheTharin]

• Operating system and version: macOS High Sierra 10.13.4
• Terminal emulator and version: iTerm2 3.1.6 / kitty last build / Terminal.app
• Python version: 3.6.4 Anaconda
• Ranger version/commit: 1.9.1
• Locale: C/UTF-8
• System Specs: MacBook Pro 15-inch 2017 2,9 GHz core I7 16gb LPDDR3 RAM

Current Behavior

Slow and jagged scrolling in iTerm2 and Terminal.app (actually fast and smooth scrolling in kitty terminal emulator).
When there are many files with .jpg / .png in a folder, on scrolling it randomly freezes forever. Freezes only the ranger process, not reacting to anything. Only process restart helps. Happens frequently but not always. Sometimes it just works fine, but most of the time it freezes on a random file while scrolling. It could be a file with any extension, but most of the times it is images/pdf files when it freezes.
It never freezes when a folder consists only of nested folders or if there are just text documents in it.
System specs are pretty strong, so I can't really blame it on my mac, I guess...

Expected Behavior

Smooth and fast scrolling, no freezes. At least no freezes, scrolling smoothness is manageable.

Steps to reproduce

1. Open a random folder (I open Downloads), press j/k and watch it skip scrolling frames and then freeze eventually.

[toonn]

Could you try to reproduce with ranger --clean? It sounds like the problem is related to image previews.

[TheTharin]

Ran ranger --clean. Reproduced.
Thing is - it reproduces even with set preview_images false.
Managed to constantly make it work if scrolling down by one single file and let it show a preview on the right. After that if I scroll up and down fast - it doesn't reproduce. Guess it's just buffering the previews better (why it still lags with preview_images false - I don't know). Though when I 'buffer' all the files and their previews, the scrolling process in iTerm2 becomes twice or thrice as choppy and laggy. Checked ram - still plenty of gigabytes left. Processor isn't throttling too. It is OKAY when I use kitty emulator, but I couldn't make ranger preview images on kitty emulator (w3m doesn't come with w3mimgdisplay on OS X, apparently) and I really like that feature, to be honest. And even without it I still have to slowly go through the whole Download folder for that to start to work without freezes. Also I've found that in kitty emulator it sometimes freezes not forever but for 10-15 seconds, usually it freezes for much more on random files, so long that I just restart ranger without waiting for more than a minute.

[toonn]

FWIW native Kitty image previews are coming in the next release.
I can imagine this is quite an annoying issue but I still lack actionable information, not sure how to get more though. Can you reproduce it with all of preview_directories, preview_files and preview_images set to false?

[TheTharin]

Okay, I dug deeper. The problem reproduced with and without image previews, so I though it had nothing to do with them in first place. So I tried something else. I tried scrolling by repeatedly pushing 'j' key instead of pushing it and not releasing. It seems to me that ranger has something to do with a fast key input (I have mine modified so that the delay between key presses when I don't release the button is really low) so it overflows and stops answering to any command. In kitty I sometimes manage to fix it by switching to another terminal window and then switching back again. So ranger doesn't lag itself, it seems that it just can't handle really fast scrolling by fast input of commands and for some reason stops answering to any if overflown.

[toonn]

Hmm, could you try a different ncurses application to see if this is something we can fix on our side?

[TheTharin]

If you have OS X, you can try memorizing your InitialKeyRepeat and KeyRepeat defaults (to change them back) performing:
defaults read -g InitialKeyRepeat - like that.
And then setting them to my values (InitialKeyRepeat - 11, KeyRepeat - 2) to try to reproduce.
defaults write -g InitialKeyRepeat -int 11 - like that. After that you have to restart the system.
Would highly appreciate. I will try some ncurses app to look into that on my part.
Any you can suggest? I can hardly guess what to try...

[TheTharin]

Okay last news. I guess it's both. Both my fast scrolling + file preview buffering. Had a hint, because it stops freezing after I slowly scroll through the whole folder once. Then there are no problems with my fast scrolling speed (despite the choppiness). So I thought there IS some issue with previews at least. If I scroll manually, even pressing fast - everything is okay. If I scroll by not releasing the button - it freezes 100% of times if done the first time after I reopen ranger and try to reproduce without scrolling through the whole folder manually first. It definitely has something to do with fast flow of file previews. It doesn't even have anything to do with images. So temporary solution is to turn off file previews for that not to freeze at all / scroll manually / not scroll at all and use find.

[TheTharin]

Tried vifm and enabled right pane as a quick preview pane by this guide: (https://superuser.com/a/455551) for when I scroll through. Despite the fact It previews just pure file code instead of ranger's cool preview of what inside .zip and so on - it doesn't freeze. If vifm is ncursed based (google said it was), then I guess the problem is not with ncursed, or at least not to that extent.

[toonn]

Could you maybe look into how many tasks are spawned? You can see these in the task_view, opened with w.

[TheTharin]

I tried doing that, but when it freezes - it doesn't respond to any input command. Is there a way to show task view simultaneously scrolling down so I can see if there is anything in task view?

[toonn]

Right, that is problematic : ).

[TheTharin]

Have you tried doing what I suggested with testing it on OS X after modifying KeyRepeat?

[toonn]

I haven't because the multiple reboots are too much effort to put into this rn : ). I'm not entirely surprised by the issue though, there's been talk about doing proper async for previews so I think if that is implemented then this issue'll be solved too. I'll look into reproducing when/if I start work on this but that's definitely not for the upcoming release.

I can imagine this is an annoying issue for you but it's one of those things that's not easy to debug. Consider using more appropriate movements like <c-f>, <c-b>, <c-d>, <c-u>.

[TheTharin]

Yeah It's manageable, I can move my way around, thanks. Hope to see image previews on kitty :)

[Ninlives]

So this haven't been fixed yet? I encounter same issue.

[toonn]

It should be somewhat fixed on master, coming in the next release (a better fix would require a much more complicated design with asynchronous execution). For completeness I'm referring to #1193.

[purgat0ri]

I'm encountering this issue as well, although for me the speed of scrolling through files does not appear related to the cause of the freeze; instead, the freeze occurs more or less randomly on any file that isn't simply pain text. It also occurs regardless of the terminal or shell being used.

[toonn]

@purgat0ri, next step is finding out what kind of files it happens for.

[purgat0ri]

@toonn PDF files occasionally, .ooutline files frequently, and images fairly seldom.

[AlanWarren]

I have the same issue. I'm running iTerm2 build 3.3.1 on Mojave, with ranger running frequently inside of tmux. My key repeat is set to 15, and ranger constantly freezes / locks up, causing me to kill the pane from tmux. Both ranger-1.9.2 and master experience the issue with the same frequency for me.

I'd say without a doubt that it's related to ranger spawning arbitrary programs for previewing files. If I take my time and scroll very slowly it doesn't happen. However, as soon as I scroll at my normal pace, ranger freezes.

I tested a medium size directory with around 30 mixed file types. I scrolled by holding down "j" and hit "w" to open the task view frequently.

After doing this for about a minute, ranger froze up / crashed just as I opened the task view. It contained 9 files queued for preview.
i.e. -
Task View
"Getting preview of /Users/me/archive.tar.gz"
............ etc.

There were 3 gzip'd archives, 1 zip file, and the rest were assorted text based files.

[mihaibirsan]

This issue happens to me on Mojave with iTerm2. I noticed that hitting <Ctrl-C> when ranger is frozen unfreezes it. The status bar says "Canceling preview of <...>" or something along those lines.

I'm not able to alway replicate the issue, but it has happened enough times that I came googling.

[toonn]

Tbh this just sounds like sometimes generating a preview is slow. The only easy fix is to disable the previews you don't care about.

Please don't "+1" this issue unless you have useful information to add, like which of the programs scope uses to generate previews is most often at fault.

[klevvit]

Did some research on that problem. I rarely get a full freezing, but often encounter with non-quitting processes, and that's kinda annoying.

This line explicitly tells that we can send ^C if we encounter endlessly spinning throbber, for me it was very helpful. Thanks to @mihaibirsan for mentioning that.

Now I'm trying to localize the problem. I found that the code starts looping endlessly in these lines. The problem encounters when fast scrolling through large files, and when it appears and doesn't freeze ranger, these files can be seen on :taskview_open. It doesn't seem to be connected with CLI tools, because hardcoding cat instead of other preview instruments doesn't help much.

I suppose there's a deadlock somewhere that happens when preview hasn't been fully loaded & isn't required anymore. Hope I'll succeed in discovering the reason in the next few days.

BTW it seems not really useful to load all file content & show preview only after this. There has to be an opportunity for optimization somewhere here.

[klevvit]

Okay, I finally found a bug. Never use hard-coded numbers for signals, they may vary for different platforms (see signal(7), "Signal numbering for standard signals" section).

Kinda funny that the bug is 13 years old :)

But there's a problem with tests I have no idea how to fix for now: testing breaks for pylint==3.x.x because of an unsuccessful import, and everything's fine for pylint<3.0.0. Unfortunately this causes errors in PR, so github tests configuration has to be modified.

[klevvit]

Got it, we have to specify 2.x.x version for pylint in requirements.txt .
Made a PR for that: #2912
This will fix errors in the main PR #2911.

[klevvit]

@toonn can you review these two fixes, please-please-please? 🙂 They're really tiny and they'll allow OS X users to use ranger without troubles