Closed theKnightsOfRohan closed 7 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
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
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"
@theKnightsOfRohan I think this is ready now. There's branch async
if you want to try it out.
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!
Finally merged the async branch https://github.com/simonmclean/triptych.nvim/pull/36 😅 I think we can consider this resolved?
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.