5 ms·

Ten years ago I threw out my massive multi-file, multi-package vim config and have been slowly building up a much simpler vimrc about 1-2 lines a year. I comple

Ten years ago I threw out my massive multi-file, multi-package vim config and have been slowly building up a much simpler vimrc about 1-2 lines a year. I completely agree, defaults in old software are almost always there for a reason and you should try to understand that before changing them.

codyb 1y ago
I also find creating my own little shortcuts to be super satisfying and of course very transferable since they work out of the box. ```some examples " Quick access to commonly edited config files (and a directory for my Shell scripts!) map <leader>v :e ~/.vimrc<cr> map <leader>V :source ~/.vimrc<cr> map <leader>w :e ~/Workspace/myCo/tmuxp-session.yaml<cr> map <leader>W :e ~/.tmux.conf<cr> map <leader>z :e ~/Shell<cr> " Super simple in editor note setup, amazing map <leader>x :vs<cr>:e ~/Documents/notepad.txt<cr> map <leader>X :vs<cr>:e ~/Documents/notes<cr> " Quick terminal pane map <leader>t :vs<cr><c-w>l:term<cr><c-w>j:q<cr> " Pull file path into clipboard nmap <leader>b :let @+ = expand("%")<cr> " Pull current line into clipboard nmap <leader>B "*yy ``` Quick disposable terminals, tons of short cuts to get me into the config files that make it all happen (vimrc, zshrc, tmux.conf, a tmuxp session file) and to reload them, and super quick access to a well organized directory of notes are all huge boons during my workday.
kannanvijayan 1y ago
I haven't had to in a while as I've lapsed into IDE usage as of late, but my vimrc is something I committed to memory a long time ago. set tabstop=4 set shiftwidth=4 set expandtab set showmatch set nohlsearch set background=dark syntax on Typing that config into a file is emotionally associated with a system feeling "ready" for me. "ah, now I can _do_ things".
- deathanatos 1y ago
  … why `memory commit` what you can `git commit` and then just `git clone`. (I keep most of my dotfiles in a repository called "dotfiles".) I get the emotional value/desire for a minimalistic .vimrc, but I also need the usefulness, and that necessitates, e.g., pulling in some plugins. E.g., lang-servers are just so valuable for immediate feedback in the editor. Over time, someone of my vimrc has been pruned away just by development that has happened in/on vim itself, which is always lovely to see.
  - appcustodian2 1y ago
    spoken like someone who has never had to operate on someone else's machine that they provisioned for you on an isolated network
    - bravesoul2 1y ago
      Operate yeah. But write lots of code?
      - esseph 1y ago
        Yep. Some orgs require it. I'm not arguing for it, just saying I've seen it at multiple billion-dollar+-a-quarter companies.
        bravesoul2 1y ago
        Oh that sucks.
        deathanatos 1y ago
        I've done it. It was terrible. I'm glad the project ended. There's no fixing it, though. I can know the "base tooling with zero config" … and I'm just less productive, that's all there is too it. Customized tooling makes me faster than the base tooling. (I did start trying to find "inventive" ways to try to work around the problem, of course. My case wasn't like military air-gapped or anything, just the only connection was via RDP. So for example, copy & paste is a communication channel.)
    - marcthe12 1y ago
      I mean there is a middle ground. LSP is good for coding a project. But I do agree with your point. What I generally do (as nvim user) reduces plugins to the bare minimum and try as much as possible to do progressive enhancement (atleast I try). Maybe as nvim improves LSP, I hope the diff between LSP and native methods are close enough that they both work.
- mtlmtlmtlmtl 1y ago
  No accounting for taste, but my similarly terse vim config includes relativenumber and number. Relativenumber is just so damn useful for doing things to larger chunks of code without having to count lines or anything. I'm also an IDE user though. I tend to maintain a dichotomy between emacs(with evil-mode, of course) as the "kitchen sink" set up, with all the fixings, and vim with a config so short I can type it in as commands if I need to. Vanilla vim is really perfect for quick edits to config files, scripts on random servers/VMs etc. Bigger projects, at least for my usage, all happen on the same system , and having a bit more involved of an emacs set up makes sense there. I suppose one could do a similar dichotomy with vim/neovim, if one had a distaste for emacs.
jmbwell 1y ago
A wise elder once advised me that if I learned to work quickly and comfortably with an application’s defaults, I would be just as quick and comfortable on any system I would likely encounter. Very zen. Great advice.
- deathanatos 1y ago
  Is it? I should just purposefully bind myself? Seems like using a tool to its fullest potential to get more work done is better advice. > I would be just as quick and comfortable on any system I would likely encounter. How often are we encountering other systems…? And even where I am rarely ssh'd into something else … are we doing so much editing of code (live in production…?) that it matters? (I heavily customize my vim, but it isn't like I'm lost on a remote system with stock vim, or nano. ed is another matter.) But if I need tons and tons of editing, … sshfs+local vim/terminal? But this just such a rare case, it seems like one of those "we should optimize for the common case" — which this is not.
  - kjellsbells 1y ago
    I see it more as like understanding how to use a hammer even if most of the time in your job you use a nailgun. For me personally it's a classic old timer habit from the days when you had to be prepared to fix a system using only the tools in /sbin. That doesn't mean you should operate like that all the time, but you should certainly know how to do so and be comfortable doing it.
  - msgodel 1y ago
    Isn't the author likely to know the tool's potential best? I get that there are special cases but those should be few and ones you know well enough to memorize the exceptions for.
patcon 1y ago
I would love a generative llm script that looks at my command history (or something comparable), and adds a new zsh config (or other dotfile) every day, explaining itself via a reliable motd-type screen that flashes on-screen during the first session of the day, explaining what was added and allowing me to play with it and decide to keep it or not by the end of the day :) Basically, slowly "evolving" my environment by forcing me to try new things daily, without my doing massive "learning" runs where I try batches of new things at once
- safety1st 1y ago
  Closest thing you'll find, I think, would be some creative use of ShellGPT features...
eviks 1y ago
That would be true if you had universally great designers back then, which wasn't the case, thus the defaults are universally bad, so it's a bad heuristic to stick to them and force a waste in trying to understand them. For example, why is the default vim cursor hjkl? Well, it's just that the arrows on the physical keyboard of one of the vim designers were drawn there. That's it. There is no deep thought in search of the best cursor position, and understanding the why is just learning a useless piece of trivia.
- sakjur 1y ago
  That seems quite harsh. Just because the designers aren’t perfect doesn’t mean the design is universally bad. To address your example: Why were the arrow keys on those particular keys? Who put them there? hjkl are on the home row, and touch typists end up having the movement keys under their right hand’s resting fingers. That’s suddenly quite convenient.
  - eviks 1y ago
    > and touch typists end up having the movement keys under their right hand’s resting fingers. This is false, h isn't in the resting place. So go back and spend more time trying to explain that historic tidbid of design before trying to defend it (I'd also be curious to know why they shifted left instead of using resting places)! Or don't and use this obvious principle directly and change keybinds to jkl; Or go with the muscle memory of inverted T and use ijkl But whatever you do, prioritizing the original design is a common bad heuristic because there is no reason to think that the original designer was great (not perfect!, don't twist it), so trying to understand the original reasons is a waste of "productivity" time (but if you're curious, it's not a waste of regular time)
  - bluebarbet 1y ago
    As pointed out, this is wrong. What touch-typists want is jkl;, because the right home key is j. This is an absolutely necessary config change in vanilla vim, unfortunately.
    - 1y ago
baby 1y ago
Some defaults suck massively, emacs in tmux basically doesn't work due to hijacking C-b. The one that catches me every time is whatsapp that hijacks C-p.

codyb 1y ago

I also find creating my own little shortcuts to be super satisfying and of course very transferable since they work out of the box. ```some examples " Quick access to commonly edited config files (and a directory for my Shell scripts!) map <leader>v :e ~/.vimrc<cr> map <leader>V :source ~/.vimrc<cr> map <leader>w :e ~/Workspace/myCo/tmuxp-session.yaml<cr> map <leader>W :e ~/.tmux.conf<cr> map <leader>z :e ~/Shell<cr> " Super simple in editor note setup, amazing map <leader>x :vs<cr>:e ~/Documents/notepad.txt<cr> map <leader>X :vs<cr>:e ~/Documents/notes<cr> " Quick terminal pane map <leader>t :vs<cr><c-w>l:term<cr><c-w>j:q<cr> " Pull file path into clipboard nmap <leader>b :let @+ = expand("%")<cr> " Pull current line into clipboard nmap <leader>B "*yy ``` Quick disposable terminals, tons of short cuts to get me into the config files that make it all happen (vimrc, zshrc, tmux.conf, a tmuxp session file) and to reload them, and super quick access to a well organized directory of notes are all huge boons during my workday.

kannanvijayan 1y ago

I haven't had to in a while as I've lapsed into IDE usage as of late, but my vimrc is something I committed to memory a long time ago. set tabstop=4 set shiftwidth=4 set expandtab set showmatch set nohlsearch set background=dark syntax on Typing that config into a file is emotionally associated with a system feeling "ready" for me. "ah, now I can _do_ things".

deathanatos 1y ago
… why `memory commit` what you can `git commit` and then just `git clone`. (I keep most of my dotfiles in a repository called "dotfiles".) I get the emotional value/desire for a minimalistic .vimrc, but I also need the usefulness, and that necessitates, e.g., pulling in some plugins. E.g., lang-servers are just so valuable for immediate feedback in the editor. Over time, someone of my vimrc has been pruned away just by development that has happened in/on vim itself, which is always lovely to see.
- appcustodian2 1y ago
  spoken like someone who has never had to operate on someone else's machine that they provisioned for you on an isolated network
  - bravesoul2 1y ago
    Operate yeah. But write lots of code?
    - esseph 1y ago
      Yep. Some orgs require it. I'm not arguing for it, just saying I've seen it at multiple billion-dollar+-a-quarter companies.
      - bravesoul2 1y ago
        Oh that sucks.
      - deathanatos 1y ago
        I've done it. It was terrible. I'm glad the project ended. There's no fixing it, though. I can know the "base tooling with zero config" … and I'm just less productive, that's all there is too it. Customized tooling makes me faster than the base tooling. (I did start trying to find "inventive" ways to try to work around the problem, of course. My case wasn't like military air-gapped or anything, just the only connection was via RDP. So for example, copy & paste is a communication channel.)
  - marcthe12 1y ago
    I mean there is a middle ground. LSP is good for coding a project. But I do agree with your point. What I generally do (as nvim user) reduces plugins to the bare minimum and try as much as possible to do progressive enhancement (atleast I try). Maybe as nvim improves LSP, I hope the diff between LSP and native methods are close enough that they both work.
mtlmtlmtlmtl 1y ago
No accounting for taste, but my similarly terse vim config includes relativenumber and number. Relativenumber is just so damn useful for doing things to larger chunks of code without having to count lines or anything. I'm also an IDE user though. I tend to maintain a dichotomy between emacs(with evil-mode, of course) as the "kitchen sink" set up, with all the fixings, and vim with a config so short I can type it in as commands if I need to. Vanilla vim is really perfect for quick edits to config files, scripts on random servers/VMs etc. Bigger projects, at least for my usage, all happen on the same system , and having a bit more involved of an emacs set up makes sense there. I suppose one could do a similar dichotomy with vim/neovim, if one had a distaste for emacs.

jmbwell 1y ago

A wise elder once advised me that if I learned to work quickly and comfortably with an application’s defaults, I would be just as quick and comfortable on any system I would likely encounter. Very zen. Great advice.

deathanatos 1y ago
Is it? I should just purposefully bind myself? Seems like using a tool to its fullest potential to get more work done is better advice. > I would be just as quick and comfortable on any system I would likely encounter. How often are we encountering other systems…? And even where I am rarely ssh'd into something else … are we doing so much editing of code (live in production…?) that it matters? (I heavily customize my vim, but it isn't like I'm lost on a remote system with stock vim, or nano. ed is another matter.) But if I need tons and tons of editing, … sshfs+local vim/terminal? But this just such a rare case, it seems like one of those "we should optimize for the common case" — which this is not.
- kjellsbells 1y ago
  I see it more as like understanding how to use a hammer even if most of the time in your job you use a nailgun. For me personally it's a classic old timer habit from the days when you had to be prepared to fix a system using only the tools in /sbin. That doesn't mean you should operate like that all the time, but you should certainly know how to do so and be comfortable doing it.
- msgodel 1y ago
  Isn't the author likely to know the tool's potential best? I get that there are special cases but those should be few and ones you know well enough to memorize the exceptions for.

patcon 1y ago

I would love a generative llm script that looks at my command history (or something comparable), and adds a new zsh config (or other dotfile) every day, explaining itself via a reliable motd-type screen that flashes on-screen during the first session of the day, explaining what was added and allowing me to play with it and decide to keep it or not by the end of the day :) Basically, slowly "evolving" my environment by forcing me to try new things daily, without my doing massive "learning" runs where I try batches of new things at once

safety1st 1y ago
Closest thing you'll find, I think, would be some creative use of ShellGPT features...

eviks 1y ago

That would be true if you had universally great designers back then, which wasn't the case, thus the defaults are universally bad, so it's a bad heuristic to stick to them and force a waste in trying to understand them. For example, why is the default vim cursor hjkl? Well, it's just that the arrows on the physical keyboard of one of the vim designers were drawn there. That's it. There is no deep thought in search of the best cursor position, and understanding the why is just learning a useless piece of trivia.

sakjur 1y ago
That seems quite harsh. Just because the designers aren’t perfect doesn’t mean the design is universally bad. To address your example: Why were the arrow keys on those particular keys? Who put them there? hjkl are on the home row, and touch typists end up having the movement keys under their right hand’s resting fingers. That’s suddenly quite convenient.
- eviks 1y ago
  > and touch typists end up having the movement keys under their right hand’s resting fingers. This is false, h isn't in the resting place. So go back and spend more time trying to explain that historic tidbid of design before trying to defend it (I'd also be curious to know why they shifted left instead of using resting places)! Or don't and use this obvious principle directly and change keybinds to jkl; Or go with the muscle memory of inverted T and use ijkl But whatever you do, prioritizing the original design is a common bad heuristic because there is no reason to think that the original designer was great (not perfect!, don't twist it), so trying to understand the original reasons is a waste of "productivity" time (but if you're curious, it's not a waste of regular time)
- bluebarbet 1y ago
  As pointed out, this is wrong. What touch-typists want is jkl;, because the right home key is j. This is an absolutely necessary config change in vanilla vim, unfortunately.
  - 1y ago

baby 1y ago

Some defaults suck massively, emacs in tmux basically doesn't work due to hijacking C-b. The one that catches me every time is whatsapp that hijacks C-p.