3 ms·

> I'd be looking for an interactive prompt style buffer instead of per-command executions > given the ease of switching and copy-pasting between terminals, thi

> I'd be looking for an interactive prompt style buffer instead of per-command executions > given the ease of switching and copy-pasting between terminals, this seems superfluous. This really makes me think you are a prime candidate for a plugin that can easily open an interactive prompt or make the whole copy, switch terminal, paste, copy response flow one command. This is just repl-integration for db repls (interactive prompts if you prefer). Many people are used to this workflow: Open your editor, open a prompt in another terminal. Write the simple stuff in the prompt, the complex stuff in your editor and then copy/paste to the prompt. Write a simple query in the prompt that ends up pretty complex, so you copy it, switch to the editor and paste, fix it up then copy, switch to prompt and paste it back. Now you copy part of the query results, switch to editor and paste so you can extract some of the results for the next complicated query. A lot of us know this workflow, an many of us aren't aware that what we are looking for is repl integration in the editor. Same workflow, goes like this: edit query, eval, edit again, eval, etc. It is not a different way of working, it is the same way but much better. How do you know if you want this? If you use vim and set your readline config to use vi keybindings you want this. You already noticed that editing stuff in the prompt is worse than in vim, you just picked the wrong fix for that problem.

falcolas 9y ago
If you use tmux, the transmission of a command from Vim to another tmux pane is remarkably simple. It's just a shell out to the tmux binary with the appropriate arguments. My problem with vim-integrated shells, prompts - anything inherently interactive except for editing itself - is that it's always worse. Be it performance, integration between vim and the interactive prompt, or an impedance mismatch between vim's modal editing and an interactive prompt's non-modal editing. I'd rather switch windows and use a native shell than a kinda-working shell in vim. Same with a DB prompt. Same with pretty much every other tool I pull up in the terminal. Honestly, it's the same reason I don't use emacs with EVIL mode: it's not quite vim, and those speedbumps absolutely kill my "Flow". Any gains from a rich editing environment are lost (with interest) by trying to figure out how to get the non-editing part of that environment to behave correctly. And I even use emacs bindings in bash (no, not zsh or fish or...); because then when I go to remote servers, everything just works. That's my opinion, at least.
- freshhawk 9y ago
  But this plugin is, framed in terms you might be more familiar with, a plugin that wraps the "shell out to the tmux pane then copy the output into the buffer I'm in" step. That's it. This isn't a vim-integrated shell solution, it's a way to avoid those, for exactly the reasons you say. Repl integration isn't about embedding a prompt in your editor, it's about bypassing the interactive prompt because you already have a place to write and read text - an editor buffer. I should have used a different term obviously, that one is actually misleading. Part of the reason I'm curious is I regularly do Clojure training and see this pattern over and over: "I don't like working that way, that sounds bad. [hours later it clicks] Oh! I see what you mean, this is great. This is the way I like working but easier! I thought you meant something different".
  - falcolas 9y ago
    True, sorry, was just really wanting to point out how easy such a thing is, then got distracted on a tangent on why I don't want windows embedded in my vim.

falcolas 9y ago

If you use tmux, the transmission of a command from Vim to another tmux pane is remarkably simple. It's just a shell out to the tmux binary with the appropriate arguments. My problem with vim-integrated shells, prompts - anything inherently interactive except for editing itself - is that it's always worse. Be it performance, integration between vim and the interactive prompt, or an impedance mismatch between vim's modal editing and an interactive prompt's non-modal editing. I'd rather switch windows and use a native shell than a kinda-working shell in vim. Same with a DB prompt. Same with pretty much every other tool I pull up in the terminal. Honestly, it's the same reason I don't use emacs with EVIL mode: it's not quite vim, and those speedbumps absolutely kill my "Flow". Any gains from a rich editing environment are lost (with interest) by trying to figure out how to get the non-editing part of that environment to behave correctly. And I even use emacs bindings in bash (no, not zsh or fish or...); because then when I go to remote servers, everything just works. That's my opinion, at least.

freshhawk 9y ago
But this plugin is, framed in terms you might be more familiar with, a plugin that wraps the "shell out to the tmux pane then copy the output into the buffer I'm in" step. That's it. This isn't a vim-integrated shell solution, it's a way to avoid those, for exactly the reasons you say. Repl integration isn't about embedding a prompt in your editor, it's about bypassing the interactive prompt because you already have a place to write and read text - an editor buffer. I should have used a different term obviously, that one is actually misleading. Part of the reason I'm curious is I regularly do Clojure training and see this pattern over and over: "I don't like working that way, that sounds bad. [hours later it clicks] Oh! I see what you mean, this is great. This is the way I like working but easier! I thought you meant something different".
- falcolas 9y ago
  True, sorry, was just really wanting to point out how easy such a thing is, then got distracted on a tangent on why I don't want windows embedded in my vim.