File Preview Support about joshuto HOT 10 CLOSED

dev @ f26fc0c

from joshuto.

Added some boilerplate code for preview configuration in dev branch: 92bcbb9

Still need to:

• spawn preview process
• receive signal preview process done
• process preview output
• display preview

from joshuto.

And just some resulting thoughts:

tl;dr: Joshuto could start with a stripped down ranger approach.

• configuration format / passing files
  Ranger just uses one bash file, giving it the full path and the geometry as arguments and taking the preview content from it's stdout and return code. Ranger's config description:

  # Meanings of exit codes:
  # code | meaning    | action of ranger
  # -----+------------+-------------------------------------------
  # 0    | success    | success. display stdout as preview
  # 1    | no preview | failure. display no preview at all
  # 2    | plain text | display the plain content of the file
  # 3    | fix width  | success. Don't reload when width changes
  # 4    | fix height | success. Don't reload when height changes
  # 5    | fix both   | success. Don't ever reload
  # 6    | image      | success. display the image $cached points to as an image preview
  # 7    | image      | success. display the file directly as an image
  
  # Meaningful aliases for arguments:
  path="$1"            # Full path of the selected file
  width="$2"           # Width of the preview pane (number of fitting characters)
  height="$3"          # Height of the preview pane (number of fitting characters)
  cached="$4"          # Path that should be used to cache image previews
  preview_images="$5"  # "True" if image previews are enabled, "False" otherwise.
  

  I like the simple and flexible approach. It would even be possible to let the user configure the script's/program's name and let him choose his preferred language. I think this sub-process call must anyway happen in a separate thread, so the performance shouldn't be problematic.
  At least in a simple first approach, the exit codes 2 – 7 could be left out (the user could just “cat” the file to stdout), as well as the two last call arguments (which are for image previews).

  The only configuration option in joshuto would be a boolean enable/disable flag or a "preview script name" string.

  Open question would be: shall joshuto cache the output in case the geometry changes or is it ok to just invoke the preview script again each time the geometry changes?

• overhead costs (mime types)
  Ranger leaves that to the preview script, too:

  # Find out something about the file:
  mimetype=$(file --mime-type -Lb "$path")
  extension=$(/bin/echo "${path##*.}" | awk '{print tolower($0)}')

  Unless joshuto pre-calculates the mime type for other purposes anyway later on and can pass it as an extra call argument, I think joshuto could also leave that to the preview script.

• showing previews

  • Colors: Maybe its fine to just ignore that in the beginning. Colors are great but without colors, the preview gives already more than 90% of the value for users, I guess.
  • Rendering: I don't know tui-rs, but I saw in the code that writing strings to the buffer doesn't seem that hard. Joshuto could just cut each line of the preview text after the width of the preview pane and be pretty ignorant otherwise.

from joshuto.

Interesting!

This can definitely work I think.

from joshuto.

Rudimentary file preview support has been added in dev @ a11ed19

It currently only shows a single line of preview and does not do proper line break processing.
It also only works with text files currently.

Inner workings:
The previews are cached in a hashmap internally.

1. A preview thread is spawned whenever the cursor moves to a file.
2. The thread will call some scope.sh file to generate a preview and send the results back to the main thread once its done.
3. Main thread receives results, stores it inside hashmap and triggers a re-render, displaying the preview.

Not sure if this is the best approach, but its what I came up with for now xd

TODOs

• work on src/ui/widgets/tui_file_preview.rs more to get text previews to look nicely
• get image previews to work...

from joshuto.

Amazing! Great to see such progress on this feature!

Not sure if this is the best approach, but its what I came up with for now xd

Hm, if a thread (with a sub-process inside) is spawned for each cursor change, that might be a bit problematic when scrolling fast and having a hungry preview script.

Just an idea:

For each tab:

[On cursor move] → 
   Check if preview thread is working for this tab, 
   if not, spawn it for the new selection
[On preview thread done (for a certain tab)] → 
   Check if the selection has changed (for this tab),
   if not, set the preview,
   if yes, spawn a new thread for the current selection

That would assure that only one preview process is running per tab, no matter how long it takes or how fast a user scrolls the selection.

Anyway, great that this is progressing, I need to try it soon! :)

from joshuto.

Question: I put an executable preview.sh in my joshuto config dir and took the latest joshuto.toml from dev, but I don't get any preview output. I touch a test file from within the preview script, which does not happen. So it seems that joshuto doesn't call the preview script at all.

Any trick necessary at the moment to enable it?

(I also created a scope.sh copy of it, which was mentioned above, in case the config option is not used, yet.)

BTW: Using current latest dev: 1b4c4b0

from joshuto.

Yeah, I haven't added variable expansion to the code. So using ~/ doesn't actually work. You will need to provide the full path. xd

from joshuto.

That did the trick. 👍

from joshuto.

Implemented 👍
Closing

from joshuto.