Fzf: Possible to use iTerm2's `imgcat` shell integration?

[mattbaker]

• Category
  
  
  
  • [x] fzf binary
  
  
  • [ ] fzf-tmux script
  
  
  • [x] Key bindings
  
  
  • [x] Completion
  
  
  • [ ] Vim
  
  
  • [ ] Neovim
  
  
  • [ ] Etc.
  
  
• OS
  
  
  
  • [ ] Linux
  
  
  • [x] Mac OS X
  
  
  • [ ] Windows
  
  
  • [ ] Windows Subsystem for Linux
  
  
  • [ ] Etc.
  
  
• Shell
  
  
  
  • [x] bash
  
  
  • [ ] zsh
  
  
  • [ ] fish
  
  

Is it possible to get iTerm2's imgcat shell integration working in an fzf preview?
https://www.iterm2.com/documentation-images.html

I'm guessing this is at the core of the issue:

iTerm2 extends the xterm protocol with a set of proprietary escape sequences. In general, the pattern is:
ESC ] 1337 ; key = value ^G
Whitespace is shown here for ease of reading: in practice, no spaces should be used.
For file transfer and inline images, the code is:
ESC ] 1337 ; File = [optional arguments] : base-64 encoded file contents ^G
The optional arguments are formatted as key=value with a semicolon between each key-value pair [...]

Right now I just see plain text (1337 followed by the relevant key-value pairs) which wasn't a shock, but I am curious if there's a way to get it working :) As you can imagine, piping images through imgcat in a fzf preview command would look really cool!

[Townk]

I was just trying to do the same and got the same result. If this is not possible, is there an alternative to preview images on MacOS?

[atsepkov]

I glanced at the preview function (https://github.com/junegunn/fzf/blob/master/src/terminal.go#L1018), I can see it's doing some parsing for the ANSI codes used to represent colors. I wonder if the problem is that it ends up stripping part of the escape sequence iTerm2 expects to see in the output to trigger the image rendering.

[atsepkov]

So I did some more digging around, extractColor in https://github.com/junegunn/fzf/blob/master/src/ansi.go is the function used to detect the color sequences, which are different, but start in a similar way. It does it like this:

• find ansi escape start (this sequence passes because it shares the same ESC code (0x1b)
• test against ANSI regex (https://github.com/junegunn/fzf/blob/master/src/ansi.go#L96) (this sequence fails here, so we never make it to the next step)
• ansi.go then populates offsets and fg/bg/attr information into a state variable and returns this back to the preview function
• preview function uses CFill to apply colors to output

So my takeaway (as a random developer who stumbled into this, not as any one who has experience with this project) is we can't reuse ansi functionality for this escape sequence because neither the state variable in ansi.go, nor CFill was designed to handle this case, and won't be able to handle it without significant changes to the logic (so to keep things clean, it's better to leave that alone).

However, what I would recommend (to the brave soul who decides to implement this, since I don't have time to do so myself, unfortunately), is the following:

• create a general fzf flag for handling additional escape sequences in preview window (including this one, and others - because this one is specific to iTerm, but other terminals have their own), so that this extra logic is off by default (pretty much the same way as --ansi flag works for color codes, here is a set of commits that added it as a reference: https://github.com/junegunn/fzf/pull/148/commits, which unfortunately seems to predate the preview window feature)
• update the tui.go (terminal ui?) (https://github.com/junegunn/fzf/blob/master/src/tui/tui.go) Window interface to include a new method (i.e. EFill/ extended fill) to be invoked by preview for rendering data with these escape codes, and add implementation of this EFill method in https://github.com/junegunn/fzf/blob/master/src/tui/tcell.go, the same way as Fill and CFill.
• this more generalized EFill can then be used for several other cases as well:
  
  
  
  • handling this iTerm image rendering
  
  
  • handling additional image rendering modes used by other terminals (https://sw.kovidgoyal.net/kitty/graphics-protocol.html)
  
  
  • allowing preview command to update window/pane title
  
  
  • additional terminal-specific escapes (i.e. https://www.proteansec.com/linux/blast-past-executing-code-terminal-emulators-via-escape-sequences/) (potentially dangerous)
  
  

[rien333]

Would other image protocols fare any better? Kitty's implementation seems fairly diffrent, though maybe not in the relevant ways. sixel aims at more universal support, see e.g.: https://github.com/hackerb9/lsix