104 lines
5.4 KiB
Plaintext
104 lines
5.4 KiB
Plaintext
|
||
|
||
<p>I no longer use plugins in my <code>.vimrc</code>. I have been running this
|
||
experiment for a while now. I had already reduced the list of plugins
|
||
to less than five and was actively trying to work without them prior to
|
||
disabling them altogether.</p>
|
||
|
||
<p>I like my new setup and consider it superior to what I had before,
|
||
because I adapted my workflow to make better use of other CLI programs.<br />
|
||
In general, I think all one needs for a decent Vim experience is a
|
||
sensible configuration file. Everything else should be taken care of by
|
||
external tools.</p>
|
||
|
||
<h2>Letting go of the IDE mentality</h2>
|
||
|
||
<p>My first code editor was Atom on a Mac. It shaped my expectations about
|
||
what coding is about and what tools should be incorporated in the
|
||
development environment. I knew nothing about GNU/Linux, the UNIX
|
||
philosophy, the CLI, etc. so I got this notion that the editor must
|
||
include virtually everything that is needed for the task at hand.</p>
|
||
|
||
<p>I gradually learned about Vim and started using it, slowly leaving Atom
|
||
behind. This happened for good after I switched to the libre software
|
||
side full-time some 2+ years ago. I still did not know much though, so
|
||
I retained this IDE mentality: Vim should be able to replicate all sorts
|
||
of functions that the console could otherwise provide unbeknownst to me.</p>
|
||
|
||
<p>As such, I would have a plugin for browsing the files in my current
|
||
working directory and its subdirectories, another for showing me the git
|
||
changes, and so on. There is no denying that these make Vim a better
|
||
tool overall, <em>if you only rely on Vim</em>, without support from the rest
|
||
of the operating system. If, however, you start leveraging what the OS
|
||
provides, Vim’s plugins become largely redundant.</p>
|
||
|
||
<p>Not only that, but some of Vim’s built-in features turn out to be
|
||
useless, perhaps some edge cases notwithstanding. For example, I find
|
||
no need to ever use splits (or however the tiles are called), when
|
||
<code>tmux</code> can handle that splendidly. Similarly, I have never encountered
|
||
a situation where <code>:terminal</code> would genuinely improve my workflow. If I
|
||
need to run some command I can just as easily fire up a new instance of
|
||
my terminal or use <code>tmux</code> again to achieve the same result.</p>
|
||
|
||
<h2>“Do one thing and do it well”</h2>
|
||
|
||
<p>This means operating in accordance with the UNIX way. Vim becomes
|
||
another specialised instrument that helps you get things done. It has a
|
||
small footprint, is quick and nimble, plus you get to learn the rest of
|
||
your toolkit better.</p>
|
||
|
||
<p>In my experience, plugins have the unintended yet major downside of
|
||
offering disincentives to learning other CLI programs. A plugin is akin
|
||
to a black box. It does things in ways that the user does not fully
|
||
comprehend, unless they have prior knowledge of similar tools—which they
|
||
most likely acquired by not using the plugin equivalent.</p>
|
||
|
||
<p>Take some of the Git-related offers for example: they are cool and
|
||
convenient, but then you learn that plain <code>git</code> can show diffs, status,
|
||
and a whole host of information. Just spend some time on <code>man git</code>.
|
||
The plugin is just a wrapper that obfuscates the underlying utility.</p>
|
||
|
||
<p>You may be thinking: why bother with the command line when the plugin
|
||
works just as well, if not better in terms of convenience? For me, the
|
||
superiority of doing things the UNIX way is about being able to solve
|
||
problems through <em>shell scripting</em>. Once you learn the commands for
|
||
running common file operations, manipulating streams, and the like, you
|
||
begin to see new possibilities that are not immediately apparent in a
|
||
Vim-centric setup.</p>
|
||
|
||
<p>Granted, I am no shell guru myself—I am not even a programmer. Yet I
|
||
can already see how such a workflow benefits my computing.</p>
|
||
|
||
<h2>The right tool for the job</h2>
|
||
|
||
<p>For me part of using GNU/Linux on a daily basis is learning new things,
|
||
which basically comes down to improving your knowledge of the CLI tools
|
||
on offer. It is why I also enjoy customising <a href="https://gitlab.com/protesilaos/dotfiles">my working
|
||
environment</a>. No, I do not do
|
||
it for the sake of ‘ricing’, as per Reddit parlance, but to develop a
|
||
deeper understanding of what is going on and how things work together.</p>
|
||
|
||
<p>I am aware that there are people whose needs are profoundly different
|
||
than mine and who must maintain a long list of plugins to make Vim meet
|
||
their requirements. That is just fine. I did it, it works. The beauty
|
||
of free software is that you can make those decisions yourself: pick and
|
||
choose what caters to your needs, follow the beaten path or do things
|
||
out of the ordinary. Your call.</p>
|
||
|
||
<h2>Portability and adaptability</h2>
|
||
|
||
<p>On another note, the upside to removing all plugins from my Vim setup is
|
||
that my dotfiles are ever more portable. This is consistent with my
|
||
reasoning for switching from <a href="https://protesilaos.com/codelog/2018-11-23-bspwm-lemonbar/">Polybar to Lemonbar for my system
|
||
panel</a>.</p>
|
||
|
||
<p>It also puts me in a better position with regard to being able to
|
||
operate in an unknown environment, say, a remote machine where my
|
||
dotfiles cannot be deployed or a custom <code>.vimrc</code> is not an option.</p>
|
||
|
||
<p>Adaptability is a huge asset. I still have to do some work on that
|
||
front: simplify my key bindings and the like. The idea is to reach a
|
||
state where I can be vimrc-agnostic, or at least know how to do
|
||
everything without my configurations in place.</p>
|
||
|
||
|