[HN Gopher] Automating the Vim Workplace (2020)
       ___________________________________________________________________
        
       Automating the Vim Workplace (2020)
        
       Author : leonry
       Score  : 65 points
       Date   : 2025-02-09 14:12 UTC (4 days ago)
        
 (HTM) web link (sharats.me)
 (TXT) w3m dump (sharats.me)
        
       | porridgeraisin wrote:
       | > sorting and reversing over motion
       | 
       | Vim can run shell commands as filters over selections as well.
       | 
       | Although vim does provide its own `:sort`, you can also sort the
       | current selection like                 v{motion}!sort
       | 
       | Which uses the external sort command (coreutils)
       | 
       | For reversing,                 v{motion}!tac
       | 
       | Which uses `tac` to reverse the order of the lines.
       | 
       | This general concept is quite useful in many other ways, since it
       | is quite universal - selection goes to stdin of arbitrary
       | program, stdout of that program replaces selection.
       | 
       | For example, if you want to quickly test a function that takes a
       | json string, and you're in a language where instantiating good
       | mock objects and serialising it takes quite a bit of code, you
       | can quickly make a mock by writing JS code within the string
       | quotes and have the code console.log json and then `vi'!node`
       | will replace it there.
        
         | billfruit wrote:
         | What if those external utilities are not available? Which might
         | very well be the case if you run Vim on Windows.
         | 
         | It is better to have atleast some fall back capabilities(for
         | searching across files, searching within files, sorting etc)
         | build in.
        
           | wruza wrote:
           | https://www.msys2.org/
           | 
           | Edit: just realized it always posed itself as a "building
           | platform", lol. It really is a full-blown GNU system that
           | works on windows. As in GNU/Linux, but there's no linux
           | kernel. All the /usr/bin tools are there, including pacman as
           | a package manager (from Arch). You can install virtually
           | everything from there.
        
             | billfruit wrote:
             | Now you need a whole userland to get basic functionality of
             | the editor. Who will vett the correctness and suitability
             | and efficiency of the 3rd party user-land?
             | 
             | Notwithstanding that the third party userland is possibly
             | not necessarily, since the windows userland most likely has
             | all the features needed for Vim to make these
             | functionalities work.
             | 
             | Since the editor is intended to be a multi-plaform product,
             | it is better if atleast a windows userland based mechanism
             | could be provided on windows platform, if the mechanisms
             | could not be achieved through an inbuilt platform-agnostic
             | manner.
             | 
             | What if you need a "portable" ( in the windows sense of the
             | term, it means that the program can be used without need
             | for an installation process) version of the editor?
             | 
             | I think it all is a huge time sink on the end user, who
             | would instead get some usefull progress done on their
             | projects.
        
               | wruza wrote:
               | Agreed, ideally a multi-platform editor should include
               | all the features an OS might have, or at least use a
               | compatibility layer that equalizes all functionality and
               | paradigms over all supported platforms.
        
               | tcoff91 wrote:
               | If you do dev on windows you should mostly use WSL.
        
               | BeetleB wrote:
               | I'm a Linux guy. Have had that as my primary OS for over
               | twenty years.
               | 
               | At work, though, I've been doing dev work primarily in
               | Windows for over a decade.
               | 
               | Never needed WSL.
               | 
               | (Maybe because I use Emacs? I dunno)
        
           | ttyprintk wrote:
           | I don't think that effort is necessary.
           | 
           | The author likely has git, which provides a userland. And
           | she/he is talking about gvim.exe, so is not restricted in
           | what she/he can choose to install, and by now, might be using
           | nvim-qt.exe.
        
         | wruza wrote:
         | I use `:'<,'>!html-to-m` to convert arbitrary html snippets
         | into mithril.js m() hyperscript.
        
         | qazxcvbnm wrote:
         | This is very powerful. Unfortunately, as an Ex command, `!`
         | only works on full lines. One can of course also teach vim to
         | operate `!` over any motion (or visual selection), whether it
         | is part of a line, a full line, or a block
         | https://vi.stackexchange.com/a/46304/48750.
        
           | PhilipRoman wrote:
           | It always infuriates me how well nano handles this out of the
           | box as opposed to vim. I don't see any reason why this
           | shouldn't be the default. If you're in visual mode and want
           | the whole-line behavior, it takes just 1 extra key press (V).
        
           | robenkleene wrote:
           | I also have a plugin that has commands for this
           | https://github.com/robenkleene/partshell.vim?tab=readme-
           | ov-f...
           | 
           | There's `Psh` that pipes part of a line through a shell
           | command, and `P` which takes any `ex` command and does the
           | same (this means `P !` is the same as `Psh` but the latter
           | supports tab completion for shell commands).
        
       | rgomez wrote:
       | The Vim configuration is something deeply personal, but I'd
       | recommend as a wise choice always explore first the default
       | settings because assuming those in your workflow gives an huge
       | advantage using any new unconfigured vim environment eg to get
       | out of any of the edit modes <C-c> works by default and is a
       | great choice. To use CUA alike shortcuts there's already: ```
       | source $VIMRUNTIME/mswin.vim ``` And finally, is also a good idea
       | to get used to use <Leader> as a prefix for your own shortcuts,
       | in my case I use the space bar as <Leader>.
        
         | windward wrote:
         | Strong agree. Failure to grok what comes with Vim often results
         | in a permenent Nerdtree pane.
        
           | kombine wrote:
           | I've been using Neovim for about 6 months now but as a former
           | VS Code user I was mostly investing into the various plugins.
           | Fairly recently I started digging deeper into vim's built-in
           | features such as vimgrep and quickfix and they are incredibly
           | powerful. It will take me probably another year to learn to
           | use all these tools effectively.
        
             | ttyprintk wrote:
             | In its contrib directory, git comes with jump. `git jump
             | grep` will load grep results into quickfix.
        
           | curioussavage wrote:
           | Eh. I tried to buy into this for years but I think my poor
           | working memory just pushes me towards having something like
           | it open.
           | 
           | Maybe a little less now that I've become a heavy user of
           | tabs. When I start working on a unique task I create a new
           | tab with a few splits with the files I'm interested in. In a
           | way tab views are how I externalize my working memory. But a
           | file tree is still useful to me because file names don't
           | stick so using a command or picker to swap is often slower
        
         | ulbu wrote:
         | note that exiting a mode with <c-c> prevents autocmd events
         | from firing. (so I have inoremap <c-c> <esc>)
        
       | usrme wrote:
       | I had no idea Vim had a terminal mode with ':ter|:terminal'!
       | Definitely something I'll look into to improve my own Vim + Git
       | workflow. I've usually just moved Vim to the background with
       | Ctrl+Z, done my committing, and then moved Vim back to the
       | foreground with 'fg'.
        
         | lelanthran wrote:
         | I tend to use it as `:vert terminal`, then start up mysql/psql
         | in that terminal, and use <C-c> in the other pane to send SQL
         | statements to the 'terminal'.
         | 
         | Works better than MySQL workbench and other things like that,
         | for me, because it works in a terminal over ssh too.
        
         | kmarc wrote:
         | I found that once you use tmux+vim, the built in terminal is
         | not much of use, it's even slowing me down
        
           | mythrwy wrote:
           | I don't even use tmux. I just have multiple tabs open in the
           | terminal (usually gnome terminal but I suppose others would
           | work) and toggle back and forth with keyboard shortcuts.
           | 
           | I usually develop full stack so will have a front end tab
           | (with multiple Vim buffers), a backend tab (again with
           | multiple buffers), dev servers, a database sql tab (if
           | needed) and a command line tab to grep and git and whatever
           | else.
           | 
           | Might sound kind of awkward but it's muscle memory by now and
           | blazing fast for my use case.
           | 
           | The one thing I have not figured out yet is how to cleanly
           | integrate AI tools into my workflow. A lot of cutting and
           | pasting which feels very clumsy. I don't want to give up Vim
           | nor my basic workflow. I never used co-pilot just GPT.
        
             | sejje wrote:
             | One main difference with tmux is that I can script the
             | startup of my "tabbed terminals", and I can background the
             | whole project and switch to another one (a new tmux session
             | is akin to a new desktop workspace full of your tabbed
             | terminals).
             | 
             | I used to use your setup, and I was fast. But tmux is much
             | better. (I'm also a full-stack dev btw)
             | 
             | Another advantage, I can ssh into the server, start a tmux
             | session, and work there the same way I do on my local.
             | Doing that your way would require a lot of ssh sessions.
             | 
             | > The one thing I have not figured out yet is how to
             | cleanly integrate AI tools into my workflow
             | 
             | https://github.com/Aider-AI/aider
        
               | mythrwy wrote:
               | Thanks. Checking Aider out!
        
               | sejje wrote:
               | No problem. I think aider is not just the terminal-nerd
               | goto here, but I believe it's the best tool for
               | programming with LLMs. It fits your ergonomics, though.
               | 
               | Tips: use `/ask` if you don't want it to make changes,
               | and try to use it for small incremental commits, instead
               | of broad sweeping changes. That may change soon with
               | these reasoning models, though.
               | 
               | It's also good for writing shell commands.
        
         | troyvit wrote:
         | Holy cow same! I use lazygit as my VC tool and now I can just
         | open it in a pane next to vim to make it simpler to interact
         | with git while I'm coding. Been using vim for way to long to
         | have missed this.
        
       | iammrpayments wrote:
       | The sort and reverse stuff is a bit overkill to me, maybe the guy
       | writing tables?
        
       | wruza wrote:
       | _I often use the :wa command to save all my open buffers. But it
       | has the nasty habit of throwing an error when it's not able to
       | save all buffers_                 nmap <F2> :silent! wa<CR>
       | 
       | _Copy to System Clipboard_                 if has('unix')
       | set clipboard=unnamedplus       else           set
       | clipboard=unnamed       endif
       | 
       | Also, to type word under cursor into command line:
       | cmap <M-w> <C-R>=expand("<cword>")<CR>
       | 
       | Paste without replacing clipboard (for the lazy):
       | vnoremap p P
        
       | toprerules wrote:
       | Can't really say enough good things about Vim. I retired early as
       | a staff software engineer because of the work I did using Vim.
       | From hacking silly games in C in high school to now, I've always
       | been able to use Vim and run circles around any "modern" text
       | editor or IDE. I feel like I owe Vim as much public praise as I
       | can give so others can reap the rewards like I did.
       | 
       | What really frustrates me is how little people seem to want to
       | invest in their tools, or the outright lies they tell themselves
       | about how much configuration they need to use Vim on a daily
       | basis. My Vim config is 200 lines, and my last commit was 3 years
       | ago. I've invested maybe a few days of my life into configuring
       | Vim and I use it 8-16 hours a day.
       | 
       | Vim can do so much on its own. It has autocomplete, fuzzy
       | finding, integration with build systems, file search, navigation
       | using a directory browser, jump to symbol, parse compiler output
       | to jump to bugs, support for gdb and breakpoints, a built in
       | terminal, copy to and from the system clipboard, and with
       | literally 8 lines of code you can get support for every linter,
       | LSP, etc. known to man, fuzzy finding, and git integration that
       | let's you use native git commands with seamless editor
       | integration.
        
         | aadhavans wrote:
         | Could you share your config?
        
         | nop_slide wrote:
         | I've been rocking dual Pycharm w/ Vim bindings plus a neovim
         | setup and bounce between. The only thing preventing me from
         | going 100% neovim is Pycharm's python debugger.
         | 
         | I have setup neovim-dap[0] with all the related plugins, it
         | works for simple script but it bugs out and crashes when
         | running our Flask web app. I rely heavily on the Pycharm
         | debugger to step through our app.
         | 
         | Have you had a good experience with setting up a debugger in
         | vim/neovim or is that not part of your workflow?
         | 
         | 0: https://github.com/mfussenegger/nvim-dap
        
           | toprerules wrote:
           | I don't use DAP so I can't help you there. I use vim for
           | editing code. When I need to debug I run lldb or gdb in a
           | separate tmux window, if I need to see the code I enable TUI
           | mode. There are many wrappers including TermDebug,
           | Vimspector, termdbg, etc. to add visual breakpoints, but I
           | have never found them necessary - because again gdb/lldb can
           | already show you the code in various formats including
           | assembly. It sounds like you are using Pycharm in exactly the
           | same way you can already use a standalone debugger.
           | 
           | For Python I find a built in debugger especially unnecessary.
           | Most interpreted languages have a debugger that can be
           | triggered from the source code to drop into an interpreter,
           | and Python is no exception - see pdb and breakpoint().
        
             | nop_slide wrote:
             | A little ashamed that I have never used pdb directly, I'm
             | going to try to broaden my horizons and learn about it more
             | :) Appreciate your perspective.
             | 
             | Cheers
        
       | jmux wrote:
       | > This articles looks an awful lot like a list of Vim tips
       | 
       | honestly, I like articles that are "a list of vim tips". I can
       | usually find some really good ideas that I didn't consider. The
       | tip about remapping copy to system clipboard to something easier
       | than '"+y' is genius, definitely using that.
        
       ___________________________________________________________________
       (page generated 2025-02-13 23:02 UTC)