simonmclean / triptych.nvim

Directory browser plugin for Neovim, inspired by Ranger
Apache License 2.0
201 stars 4 forks source link

Switch from manual buffer reading and highlighting to netrw preview #35

Closed theKnightsOfRohan closed 7 months ago

theKnightsOfRohan commented 8 months ago

Describe the problem you're having I've noticed that sometimes, triptych can lag significantly when previewing a large file or nested directory, to the point of requiring me to restart my terminal. It happens somewhat sporadically, but often enough that I remember what's causing it. I've looked at netrw, because it also has a preview feature which applies syntax highlighting, and I noticed that it doesn't cause any lag when I preview a file.

Proposed solution(s) I was thinking that the backend for triptych's previewer could become netrw, rather than manually reading and applying syntax highlighting, with the ui being a float with netrw's contents. This would also be more accurate, as netrw's previewer also applies syntax highlighting by the LSP, and not just treesitter. However, I recognize that this would be a rather large refactor, and I'm not familiar with netrw and any possible API to make use of it.

Additional context To see previews in netrw, you simply type "p" on the file you want to preview. Note that it will get mad at you if you try to preview a directory, so that functionality could probably remain handled by triptych.

simonmclean commented 8 months ago

As far as I can tell, the preview feature in netrw just opens the file in a new split. It's literally the same as doing :vsplit ./path/to/file. So there isn't anything to leverage from netrw in that respect.

The reason Triptych has a more convoluted way of showing the preview is to avoid (for performance reasons) triggering any autocommands which normally occur when opening a file in vim. So instead Triptych does this:

There is definitely room for improvement though. Some things that come to mind:

A lot of the above could be configurable as well.

Can you give me a bit more information about what kinds of files and directories are causing you problems? For files: the size in kb, and number of lines. For directories: the size and number of files contained. And anything else you think might be relevant. If there's open source code you can link me to, that would be ideal, so I can try and reproduce what you're experiencing

theKnightsOfRohan commented 8 months ago

Here's one of my projects where this occurs. If I open the project by typing nvim in cwd, then open triptych, it opens up the preview of the assets folder with only a singular large pdf inside it, and there will immediately be lag. This shouldn't occur, as the file contents are not being previewed, just the names of the contents of the directory. Navigating down through the lib directory will also cause lag, even though the actual amount of files seems not that high. Navigating into the lib directory will also cause lag to occur again, and previewing the nested macosx64 directory can also cause the lag to occur again.

One wrinkle I've seen with this, after some further experimenting, is that either neovim, plenary, or my terminal emulator seems to perform some sort of caching of the files after it's read them. Thus, in subsequent openings of the same directory, even between terminal instances, lag seems to be greatly reduced. However, this caching should be removed after a set amount of time(a week?), and the lag will begin again. Unfortunately, I didn't think to record the lag the first time, as I didn't notice this caching immediately.

Here are some specific specs on the repo:

pwd:
1.4K Feb  6 12:11 .gitignore
525B Feb 15 13:19 Makefile
 79B Feb  5 10:45 README.md
128B Feb 16 10:26 assets
480B Feb 16 10:26 bin
864B Feb 16 10:26 lib
320B Mar  6 08:11 src

assets:
651K Feb  5 10:45 OfficialOMRSampleDoc.pdf
160B Feb 27 12:31 output

lib:
858K Feb  5 10:45 bridj-0.6.2.jar
998K Feb 15 12:31 core.jar
338K Feb  5 10:45 gluegen-rt.jar
508K Feb  5 10:45 gst1-java-core-0.9.1.jar
782K Feb  5 10:45 gstreamer-java.jar
104K Feb 13 11:08 javapoet-1.13.0.jar
1.0M Feb  5 10:45 jna.jar
3.2M Feb  5 10:45 jogl-all.jar
 77K Feb  8 13:06 json-20240205.jar
1.6M Feb 13 13:37 kotlin-stdlib-1.9.22.jar
194K Feb 14 19:37 kotlin-stdlib-common-1.7.10.jar
 19K Feb 14 18:46 kotlin-stdlib-jdk8-1.7.10.jar
3.1K Feb 16 10:26 macosx64
 10M Feb  5 10:45 pdfbox-app-1.8.1.jar
 50K Feb 13 11:08 pkl-codegen-java-0.25.2.jar
6.6K Feb 13 11:08 pkl-commons-0.25.2.jar
385K Feb 14 10:13 pkl-config-java-all-0.25.2-javadoc.jar
 10M Feb 14 10:11 pkl-config-java-all-0.25.2.jar
4.4M Feb 14 10:19 pkl-core-0.25.2-javadoc.jar
2.9M Feb 13 11:09 pkl-core-0.25.2.jar
 25K Feb  5 10:45 slf4j-api-1.7.2.jar
4.0K Feb  5 10:45 slf4j-nop-1.7.2.jar
 26K Feb  5 10:45 video.jar
399K Feb  5 10:45 webcam-capture-0.3.10.jar

why the fuck is .DS_Store 10kb

simonmclean commented 8 months ago

Just to keep you updated - I am working on a fairly large change that will make directory and file reading completely async. Of course this won't speed up how quickly/slowly files and directories are read, but it should prevent any slowness from locking up the UI , and thereby improve the performance "feel"

simonmclean commented 7 months ago

@theKnightsOfRohan I think this is ready now. There's branch async if you want to try it out.

theKnightsOfRohan commented 7 months ago

Thanks! I've been using it for a couple days, and it seems to work great for files. However, I have been noticing some lag when moving to hover over a directory which contains nested directories, and there is still some startup lag when opening triptych for the first time in a neovim session. It's not too noticeable though, and is definitely a lot faster than before. Thanks for your work!

simonmclean commented 7 months ago

Finally merged the async branch https://github.com/simonmclean/triptych.nvim/pull/36 😅 I think we can consider this resolved?