ionide / Ionide-vim

F# Vim plugin based on FsAutoComplete and LSP protocol
MIT License
178 stars 21 forks source link

Enhance Alt-Enter to send multi-line expressions #65

Open greggyb opened 1 year ago

greggyb commented 1 year ago

Is your feature request related to a problem? Please describe.

The current behavior of the Alt-Enter shortcut will only send a single line at a time, unless in visual mode. Many common expressions span multiple lines and in interactive development it is convenient to write an expression and immediately send it to the interpreter. Right now, if one writes a multiline expression, one must

  1. Write it
  2. Exit insert mode
  3. Enter visual mode
  4. Highlight the whole expression
  5. Alt-Enter

Describe the solution you'd like

Alt-Enter should find the beginning and end of the expression where the cursor is and send the entire expression. This should find the surrounding top-level let-binding, module definition, or the beginning and end of a top-level pipeline.

Describe alternatives you've considered

I am wondering if it is worth the time to try to write the 'find expression bounds' logic in vimscript and use that to bind a custom shortcut to do the actions described above. This feels like functionality that should be core to the plugin, though, and not the domain of user customizations.

tonyjthomas commented 1 year ago

Chiming in to say I'm also looking for a similar capability - being able to send blocks of code to FSI without having to use visual mode.

I think zepl.vim has an elegant strategy for this. It provides an operator gz which takes a motion and sends the results to your configured REPL without leaving normal mode. This lets you gzip to send a paragraph, for example. For languages with treesitter textobject support, this becomes really powerful (gzac to send a class, gzif to send a function body, etc).

cannorin commented 1 year ago

The main challenge here is that it is difficult for (neo)vim to know where the expression ends. VimL and Lua with the neovim library are too poor languages to implement this on our own. I thought FSAC has supported textDocument/selectionRange (which would be used to suggest the selection range to the editor), but it seems to be removed in the current version of FSAC for some reason.