freeze when opening /tmp directory

[exastone]

Summary

when open /tmp (or /tmp/) from command line, hx will open a directory file picker as expected but will become unresponsive to any input, preventing you from interacting with the UI, selecting a file, quitting, etc. requiring the shell instance to be terminated.

I was thinking this might because /tmp is a symlink or dir permissions but I checked with other symlinks and root owned directories and they seem to behave as expected

Reproduction Steps

$ hx /tmp

file picker opens

Expected behaviour:

• hx continues operating as expected; i.e. selecting a file, opening in a buffer

Actual Behaviour:

• hx becomes unresponsive to user input, requiring the shell instance to be terminated/closed

Helix log

I cleared the log before reproducing (multiple times) to cut back on un related log messages from days/weeks prior. The log is empty after reproducing this event.

Platform

macOS

Terminal Emulator

wezterm 20221119-145034-49b9839f

Helix Version

helix 22.12 (96ff64a)

[the-mikedavis]

Do you have many files in your /tmp directory? This might be #1707

[exastone]

Do you have many files in your /tmp directory? This might be #1707

nope, only 12

[pascalkuthe]

Could you provide more details? I can't reproduce this locally with my /tmp directory (although there aren't really amy files there). Since there is no log messags/backtrace this is non-actionable for us. If it contains no sensitive information you could compress your /tmp directory as an tar archive an upload it so we can reproduce this?

[exastone]

Screen.Recording.2023-01-30.at.11.29.47.AM.mov

screen recording shows normal behaviour first, followed by unresponsive behaviour second.

Not shown in the screen recording but mentioned above, opening a particular file in a buffer directly without entering into the picker view as shown in the video results in expected behaviour. Unresponsive behaviour only occurs when accessing /tmp directory explicitly

[pascalkuthe]

Interesting so the freeze only occurs after the picker opens so it's unliekly to be realted to the FS transversal. Maybe this is a case of a specific file being too large and locking up the editor when trying to preview it. Like I said it's basically impossible for us to debug the exact cause without having access to the files in your /tmp directory.

[the-mikedavis]

Could you share that wezterm.nightly.json file? If it's a very large file this might be some poor tree-sitter performance from trying to parse and highlight in the preview

[exastone]

wezterm.nightly.json is actually just a one-liner from a failed build
{"message":"Bad credentials","documentation_url":"https://docs.github.com/rest"}

Additional info & testing

I'm suspecting there is a misbehaving file that is being generated in /tmp by some other application.

I cleared /tmp and tried the same thing again and it was still a no-go, except this time the file picker doesn't even open. (Shown in the clip) However, you'll see a couple files that were auto-generated shortly after emptying the directory the first time which i did not initially catch. This is shown when the file picker won't open on the first attempt of hx . while in /tmp

I then emptied /tmp again (notice the auto-generated files are absent this time).
I then make a txt file to test if the picker will open; on second attempt of hx . hx opens and behaves as expected. This is also demo'ed in clip below (watermark is from online compression tool).

screen-recording-2023-01-30-at-124406-pm_L7sBUYS2.mov

Prior to the above (clearing /tmp so the possibly misbehaving file should still be in /tmp) i did some more playing around testing other terminal emulators and found that the built-in macOS Terminal.app would behaviour on most profiles (build-in profiles seem to only differing in athestics). This is the case for wezterm, kitty, contour terminal emulators all refused to open the picker where Terminal.app seemed to be fine doing so for most profiles. you can me demo 2 different profiles in the clip below, but I tested with a half dozen profiles that are built-in to Terminal.app and all but one profile seemed to behave fine.

Screen.Recording.2023-01-30.at.12.20.44.PM.mp4

I played around with some of the setting in Terminal.app for a few of the different profiles, different fonts, opacity, colours, etc and I couldn't determine any particular thing causing inconsistent behaviour

Update
I also did a copy of everything in /tmp while hx was becoming unresponsive and moved it into a new dir. hx seem to be fine opening the /tmp\ copy folder i made and previewing/accessing the files in it

[exastone]

(sorry for the potato quality, i had to record and compress to super low quality to come in under the max attachment size)

i don't really care if this is fixed, you guys got better stuff to do i'm sure, this is a pretty niche issue that hardly impacts workflow but I thought it might worth flagging incase anyone thinks it's worth looking into since it's bit of weird one.

Overall this issue seems to be address by clearing /tmp, I'm good to close due to non-producibility

[pascalkuthe]

Thank you for sticking with us and providing detailed feedback.

From your description I think that Ihave a rough idea of what may be causing this (pipes or other types of weird files where reading them blocks) and how to fix it. I still need to do more testing later tough

[pascalkuthe]

I can reproduce, just go into your /dev directory and start hx . and keep scrolling. Previewing some of the files locks up your editor. The reason is that helix only excludes directories from the file picker. This is not the same thing as only showing files as there are other FS entries which we should not touch. For example pipes and block devices block the reader until enough data is available (which could be infinitely for an inactive pipe which I suspect is causing the issue here).

We actually already do the right thing in the global search. Just not in the file picker.
The funny thing is that I actaully ran across this bug recently (I just didn't realize it could freeze the editor) and fixed it and just didn't connect the dots until last night. The fix is included in #5658

[the-mikedavis]

Ah I think this might be #5210

[pascalkuthe]

You are right I didnt realize there was already an open issue. Should we close thisone as a dupliate then?