hx freezes on file picker selection

[ondrej-ivanko]

Summary

Execturing hx from certain folders seems to freeze file picker (SPC f). I tried to run hx from directory one level lower than /home dir (/home/Downloads) and when trying to run file picker with space + f it froze hx and I couldn' t do any action besides shutting down terminal.

This issue is resolved by putting the folder that's in hx logs (/Games) to .gitignore. My theory is that path is just too long for hx to handle (Input/Output Err in logs). Or that there is problem with permissions, as some files in my /home dir are owned by root. Not sure why they are owned by root, but they're managed by wine application, so I'm not going to change the owner to not mess up with wine.

Reproduction Steps

I tried this:

1. hx
2. press space and f

I expected this to happen:
file picker pops up with no issue

Instead, this happened:
hx froze and stops responding

Helix log

~/.cache/helix/helix.log

2023-02-07T12:47:56.800 helix_term::commands [ERROR] Global search error: /home/oji/Games/origin/dosdevices/z:/sys/module/snd_pcm_dmaengine/holders/snd_soc_core/drivers/platform:snd-soc-dummy/snd-soc-dummy/subsystem/drivers/tigerlake-pinctrl/INTC1055:00/firmware_node/subsystem/devices/ACPI0007:0e/physical_node/subsystem/drivers/processor/cpu0/node0/cpu13/firmware_node/thermal_cooling/subsystem/thermal_zone11/hwmon4/subsystem/hwmon1/device/subsystem/ADP0/wakeup29/subsystem/wakeup8/device/iommu/subsystem/dmar0/devices/0000:00:02.0/drm/controlD64/card0-DP-1/i2c-12/subsystem/drivers/i2c_hid_acpi/i2c-MSFT0001:01/0018:06CB:CE78.0005/input/input11/subsystem/event2/device/device/input/input2/power/autosuspend_delay_ms, Input/output error (os error 5)

2023-02-07T12:47:56.735 helix_term::commands [ERROR] Global search error: /home/oji/Games/origin/dosdevices/z:/sys/module/snd_pcm_dmaengine/holders/snd_soc_core/drivers/platform:snd-soc-dummy/snd-soc-dummy/subsystem/drivers/tigerlake-pinctrl/INTC1055:00/firmware_node/subsystem/devices/ACPI0007:0e/physical_node/subsystem/drivers/processor/cpu0/node0/cpu13/firmware_node/thermal_cooling/subsystem/thermal_zone11/hwmon4/subsystem/hwmon1/device/subsystem/ADP0/wakeup29/subsystem/wakeup8/device/iommu/subsystem/dmar0/devices/0000:00:02.0/drm/controlD64/card0-DP-1/i2c-12/subsystem/drivers/i2c_hid_acpi/i2c-MSFT0001:01/0018:06CB:CE78.0005/input/input11/subsystem/input18/device/device:18/physical_node/subsystem/card1/device/i2c-19/delete_device, Permission denied (os error 13)

Platform

Linux - Fedora 37 86_64

Terminal Emulator

Alacritty 0.10.1

Helix Version

helix 22.12-223-g9c98043c (9c98043)

[pascalkuthe]

The log entry you attached is related to global search <space>g. Not the file picker <space>f. However it sounds like you got an entire filesystem under that directory. There could simply be a lot of files there which take a long time to transverse.

However it's a bit odd that this occurs here since we limit the number of files outside of git repos to 100k currently. Perhaps that specific subfilesystem is somekind of fuse filesystem that is responding very slowly.

[ondrej-ivanko]

Hi pascal,

thank you for the swift response. In that case, I can only assume hx freezes on <space>f and does not write any useful information to logs, if as you say, those logs are related to global search (which in my case is assigned to <space>/). I also tried to run it with RUST_BACKTRACE=full hx. Makes no difference. Nothing in logs.

I remember global search also froze at least once, but I cant reproduce that situation again.

[CptPotato]

I can somewhat reproduce this if I try <space>f or <space>/ on a network drive (with a ton of subfolders). I assume walking the files is simply too slow in this case.

If walking the files takes more than a few seconds, it might be neat to have some visual feedback and be able to C-c to cancel:

Though there might be another issue besides slow file access that @ondrej-ivanko is experiencing.
I tried to see if access rights could cause this, but the file picker handled this just fine (tested on Windows).

[pascalkuthe]

I can somewhat reproduce this if I try <space>f or <space>/ on a network drive (with a ton of subfolders). I assume walking the files is simply too slow in this case.

If walking the files takes more than a few seconds, it might be neat to have some visual feedback and be able to C-c to cancel:

Though there might be another issue besides slow file access that @ondrej-ivanko is experiencing. I tried to see if access rights could cause this, but the file picker handled this just fine (tested on Windows).

Yeah that would be nice. Some prior discussion/work #1987, #1543 and #1707.

I am also working on a watchmen like filewatcher in rust we could use for helix which would keep a cached a copy of the workspace filetree in memory (and update it automatically either based on native os events or polling as a fallback). So that would mean that this slow task is atleast only performed once and in the background.

That being said even such a background indexer could stall and therefore not return anything for a longtime. There will also be options/heuristics to disable this indexer. In both cases an iteractive hint like you showed there would be very nice.

We could probably compute pickers in a job to make that happen.

[CptPotato]

What I had in mind is keep the call blocking, i.e. you can't continue to edit text, but provide visual feedback and an option to cancel/continue with partial result.

I think fully async tasks can be pretty confusing in the editor when they finish at an unexpected time or with output that isn't consistent with the current state (since you can make edits during that time).
Even now I'm sometimes caught off guard when I get a random request timed out/etc., or a goto references I tried to open while the LSP started pops up when I'm already in a different source location.

[pascalkuthe]

To allow the option to respond to keyevents (C-c) or even just show this stuatus you must run the task in the background as only the main loop is the only thing that can render or respond to key events. It's also important to keep the mainloop running so we can respond to other async events like signals or resizing the window.

Freezing the editor while waiting on certain jobs would be more of a followup feature in my opinion and could also be used for other async tasks like goto_reference to make it less confusing. So this would be thtree seperate features:

• Make the file picker/global search async
• Optimize the file picker/global search by using a filewatcher and an in memory fs tree
• softlock the editor (with the option to cancel) while waiting for async requests (like filepicker, globalsearch and goto_reference) that are needed to fullfill user actions

[ondrej-ivanko]

I agree with the proposition to allow the user stop the file picker process with some key-event. There should be option to cancel long running threads. Another option would be some sort of short timeout to load files to file picker, but user should be informed about this timeout being in effect. If it would be really short, than I guess user wouldn't care waiting like 2s.

The solution should most importantly not force the user to shut down the whole terminal. I'm using zellij multiplexer and running hx in one of two tabs. The terminal froze and I couldn't even switch to different tab and had to force shut terminal or kill hx process from gnome-terminal.

[kristian-clausal]

Global search (space /) also freezes when I forget to specify the right working directory (I assume it would finish at some point), it would be really nice to not have to kill the terminal or the pane to cancel it.

[catdevnull]

i believe this happened for me because i had a .git in my projects folder which caused it to try and search through all of my projects. deleting it fixes it

[mway]

There are times, though, where it's unavoidable to have a large tree (e.g. monorepos) - maybe it's worth adding an option to only lazily search based on input, instead of pre-traversing everything when the modal opens?

In my case, if I type quickly enough (so as to immediately begin filtering), the picker is responsive; if I just cmd+f and type nothing, it will take many seconds (sometimes up to 20) to finish loading, because it traverses the entire monorepo. This isn't a huge deal because you can cmd+F as well, except when I typo and think that I've hit cmd+F but have actually hit cmd+f. (Personally, I think the two shortcuts should be reversed by default: cmd+f for rooting at pwd, cmd+F for rooting at the project root).

I haven't had a chance to dig yet, but assuming there's more going on behind the scenes than just stat'ing files (e.g. if they're eagerly being loaded into memory for previews), maybe an option to disable some of that work would be enough?

[webbb82]

I have this same error/freeze. As far as i can tell it only happens when trying to find when you are in the space menu the space f and space F command the second f/F is pressed helix will lock up. only way to get out of it is to force close the terminal. This started happening recently maybe a update ago. I use helix everyday so Im pretty sure its only been a week or so of this issue.
Im not sure if this is related but i also started seeing these ilttle red lines on the left hand side. seem to be connected to the re circles that have to do with maybe compositor ? i cant be sure. prob not related.
a few other issues i have noticed in this past week ish of issues. My config file stopped working. I can set the theme but once I close helix the theme just goes back. I have a config file that I have custom binds, a theme, and many helix settings in and none of them work anymore. This im pretty sure is tied to the key bind issue or space F/f I have doubts its software issue and possible a keybind issue in how key presses and helix are married at runtime? just a guess but just my 2 cents @mway @catdevnull @kristian-clausal have you noticed your keydinds/theme or anything in config file if you use one working still? (im sure there is more of you these people were the most recent comments)
Im running arch linux

• with wayland Hyprland
• Nvidia graphics card
• intel chick
• zen kernel
  hope this helps as i would like to see this resolved.