Feature: Show file content in real-time with QuickOpen

[bryphe]

Came from @chenglou's feedback on twitter: https://twitter.com/_chenglou/status/939309997560807424

Just found out that Sublime Text show's file content in real-time when you're navigating through their file open / C+P experience. This sort of instant feedback is very helpful in terms of orienting in a large project, and cuts down on mistakes where we navigate to the wrong file - would be great to incorporate into Oni.

It seems doable as Neovim is so quick to open files - even large files.

The easiest way to approach this would be to simply open the file in the background (potentially hide the tab while the user still has QuickOpen up, so that it is not a jarring experience), and close it if the user changes selection or cancels the QuickOpen session.

We'd also want to gate this with a configuration setting, like editor.quickOpen.instantPreview - I'd be curious if the above strategy could interfere with any vim plugins, and if it did, it'd be important to be able to turn this off.

[chenglou]

Thanks! Additionally, ST also allows you to refine the selection through foo.md:10 or foo.md@myTitle. The former goes to that line, the latter goes to the context item (e.g. outline view's items, from language-server). No clicking around required. Still a temporary file buffer

[bryphe]

Cool, didn't know about those either! Inspired me to check out: http://docs.sublimetext.info/en/sublime-text-2/file_management/file_management.html

There's also a foo.md#someSearchString which does a search. Could definitely see these being useful for my workflow.

[manu-unter]

I would love to have this feature and I would also directly start working on it, but I think we need to agree on some more detailed acceptance criteria for a few trickier cases beforehand:

I agree that there should not be a visible new tab as long as the quick open menu is open. My first naive approach would be to open the highlighted file as a new buffer, internally also in a new tab so that we don't have to worry about existing splits (Or should we?). Depending on the user's tabs.mode setting, we would then need to hide the corresponding buffer or vim tab, respectively, from the oni tab bar. I have no clear idea how we could handle that right now, but I guess that should be feasible. Maybe also relevant: How will this play with the new oni mode that is currently in development? If the user submits the selection, we open the file in the regular way. If the user cancels the process, we will need to close the buffer as well as the vim tab again, right?

As for the more advanced scenarios with :, # and @: Wouldn't ctrlp.vim need to support those features before we can use them?

[CrossR]

As for the more advanced scenarios with :, # and @: Wouldn't ctrlp.vim need to support those features before we can use them?

We don't actually use ctrlp.vim, we use our own search powered by ripgrep. So we could probably add that as well by running ripgrep on the selected file for #, scroll the buffer to the line for : and not sure about @. Though that said, they could be added on after the fact so the basic feature can be added quicker and get tested quicker.

All the stuff you've said sounds reasonable though. If we "open" the file in the current container of any form with a simple :e, we wouldn't have to mess with dealing with splits/Oni split mode etc I think?

[manu-unter]

Ah, nice! Thanks for clarifying! I agree though that we should split up the preview and the advanced search directives into separate issues.

OTT: Sublime has a concept of "transient views" which they apply in the quick open scenario ("goto anything" in sublime) but also when single-clicking a file from the file explorer or selecting it with the keyboard. Maybe we should think about adopting both these behaviors and introducing a smoothly integrated solution for such transient views?

[bryphe]

I like the idea of supporting a transient view feature to cleanly implement this - that way other features could opt-in and leverage a common foundation.

From an API perspective, I could see a couple ways of exposing this 'transient view':

• On the Editor API, as a first-class method:
  • Oni.editors.activeEditor.startPreview(filePath: string)
  • Oni.editors.activeEditor.endPreview()
• As a separate object, that depends on an Editor object:

  const previewer = new TransientView(Oni.editors.activeEditor)
  previewer.start(someFile)
  ...
  peview.end()

As far as the actual implementation, I don't think it has to be anything too fancy - but we probably don't want to load the file directly (in case the user has it loaded in a separate buffer, has edits, etc) - a potentially safe approach would be to create a scratch buffer like 'oni-transient://path/to/file.ext', load the file from the filesystem external to Neovim, and set the buffer contents directly. When the preview session ends, we'd close all the oni-transient buffers.

[CrossR]

Just seen https://github.com/dyng/ctrlsf.vim on reddit, that looks to do some of this sort of stuff, but obviously in a Vim UI way. Still, could have some useful tips for implementing in Oni.