So very quickly following my last post here on my initial thoughts with starting Vim, I proceeded to learn tmux first to immediately replacing my habit of constant spawning of new terminals in i3. So far, I’ve found this to be a nice, gentle introduction to the concepts and the commands before I move onto denser reading.

However, I’ve so far found some of the default keybindings to be really horrible to remember. Though one could say I should just rebind everything to suit my needs, I think the issue of whether to keep with defaults or to customize is actually a bit more complicated than it might first seem.

A few keybindings I’ve disliked so far

Why does tmux’s vertical splitting have to be C-b + " and horizontal splitting be C-b + %? At least i3 uses $mod-v and $mod-h, which make lots of intuitive sense and meant it took no time at all to get comfortable with them.

Another issue I have is the extremely strange choice for Vim to have the HJKL as the default directional keys, which is something I mentioned in my previous post. Of course, the reason these keys were chosen in the first place was historical, and standards such as this can get so settled that changing them will only cause anger, confusion, and broken software (as I imagine some things such as plugins and scripts can rely on them). I’m not saying we should get everyone together and devise a new standard to change the defaults to (though if needed, making a new widely recognized standard in which people optionally configure to, or even have things officially support might be cool).

i3 however has it right by assigning JKL; as the direction keys, as it should’ve been in the first place (at least in my opinion). This one’s understandable since default $mod-h is used to make a horizontal split container, though it only further complicates things. If I kept HJKL for Vim and everything else, should I just keep i3’s JKL; and remember to right-shift my hand each time? Or should I rebind i3 to maintain parity between all my keybinds? If I rebind, what do I rebind $mod-h and $mod-v to now?

Perhaps I should maybe just save myself the pain and rebind everything. Hell, maybe I should change the direction keys to IJKL (which makes a tonne of intuitive sense, being T-shaped), though that would mean I’d need to rebind Vim’s insert mode key.

I could perhaps get into more, but I think that would be for another blog post (if I choose to discuss this further), or perhaps it might be best if I learn tools first before criticizing their specific choices.

Arguments for rebinding keys

In favour though of rebinding is the reduced complexity of completing many tasks as my brain would have less mental overhead when switching between contexts of controlling Vim, tmux, i3, and whatever other program such as ranger. If I had to switch from Vim’s HJKL to i3’s JKL;, I might first have to consciously reframe my mind to switch keys. In Vim, if I wanted to move in a direction (one step at a time at least), my mind would be automatically translating my intention to unconscious mechanical movement of my fingers to strike HJKL for their respective directions. By switching to i3, I’d have to “reconfigure my mind on-the-fly” to instead translate direction into finger movements that hit the JKL; keys. The solution would clearly be switching everything to use the same direction keys.

Similarly can be said with different pane-splitting in tmux (C-b + " and C-b + %) vs i3 ($mod-v and $mod-h).

Rebinding can also optimize hand movements if done correctly. Sure, I could one day get used to the different controls, but if I optimized my bindings to make the most common operations require the least travel time or contorted hand gestures, the long-term comfort could be worth it.

Some keys can also lack any mnemonic connection. How do C-b + " and C-b + % have anything to do with horizontal and vertical splits? If I end up taking a break from using tmux (such as a long holiday), or during any “brain farts” where I randomly forget my keys for a second, being able to work backwards from mnemonics could make things easier to ease back in.

Arguments for keeping default keys

The first and most important issue I think with whether or not to rebind is that getting used to my own weird keybinds will mean I’ll have a lot of trouble using systems that aren’t mine. If I’m pair-programming, I’d like to know that my partner would be able to use my machine, and likewise I’d like to know that I’d be able to use their machine. Or perhaps if I’m working on a company machine, if for whatever reason I’m stuck with default Vim, I’d like to know that I’m still capable of using it. Or perhaps I’m just quickly connecting to a web server to make a few adjustments, only to find I have to spend a quick minute making some large changes to a config file which would be much easier with Vi. Being able to just jump right into everything with no issue would ultimately make me more efficient and productive.

I’d also be able to use Vim emulators in IDEs and such out of the box.

But what if I could just get used to it? After maybe a year of constant daily use, I’d likely no longer be hindered by these context switches; I’d just do it like it’s second nature. Additionally, if I learnt how to switch contexts like that, I could likely pick up more programs that differ in similar ways much more easily without further being dependent on having to rebind everything to be the exact same. Overall, I’d become a more versatile computer user.

Emphasizing cognitive flexibility might also have an advantage if I choose to pick up a new keyboard layout, such as if I had to work on a German keyboard, or a DVORAK keyboard. With the explicit ability to reframe my mind as needed and rely less on positional motor memory, keyboard layout switches might be easier in the future.

My verdict

I think I might choose to roll with defaults for the meantime, and only after getting proficient with them will I consider reconfiguring controls.

If I find the controls to be acceptable by then and not inefficient, I think I’ll keep using defaults after that (due to the advantages of everything being readily usable out-of-the-box), but if I choose to remap, at least I’d then have a better understanding of how I use the program to optimize my usage. Only by then will I know my common-cases and other habits.

So over the past few days, I’ve been thinking of starting off with Vim. I really can’t pinpoint the exact moment or thought process that led me to start down this route, but it continued on to become my current course of action: To force myself to use Vim for all my text editing (or at least within my Linux VM).

Along with that, I’ve also decided to further “Vimmify” my life by using more terminal-based tools (especially if they have Vi keybindings or they synergize well with Vim), using Vim emulator plugins for IDEs and graphical editors, and maybe rebinding keys on various programs to conform to Vi. I’m still in the process of exploring what exactly I can do, but for now, I’ve decided to also use tmux and ranger.

Rather helpfully though, I’ve been using exclusively i3 for the past 2 months, and at this point, I’m actually quite comfortable with it. Not that it took long. There actually isn’t much complexity in the way of being productive with it at a basic level, maybe taking only 5 minutes to learn how to spawn terminals, set orientations, move things around, and use workspaces.

After getting comfortable with Vim, I’m interested in then moving on to Emacs, using Evil. However, that’s an almost completely different rabbithole that I think I’ll head down after achieving my current goal of becoming a Vim user.

That’s my full plan. So what do I expect to get out of it?

1) I see this as a way to explore different workflows to improve how I do my work, along with learning a command-based editor and seeing how it fits for me.

Currently, I use Sublime Text as my main editor, usually on my host Windows/OSX system, and using shared folders used within a Linux VM running on Virtualbox. And within Linux, I’ll tend to have many terminal windows open, flick between them in i3, and do any filesystem heavy lifting in a graphical file manager (usually on the host system since I do a lot of work in the shared folder; I don’t remember the last time I opened Thunar since I’m fairly comfortable with a plain terminal). However, since Sublime Text on the host is limited to the shared folders, if I need to edit anything else in the Linux VM, I use nano.

Within Sublime Text, I am a very point-and-click-heavy user, though I still navigate short distances with a flurry of direction-key keypresses. And if I need to delete a large section, I’ll either rapidly hammer backspace (usually if it’s about a word long), hold backspace (usually up to about a long line long), or just use the mouse.

Having seen videos and people move around and edit super-quickly with Vim, and having done a bit of vimtutor on the train (I’m roughly halfway), it’s hard not to be curious as to whether or not I’m capable of achieving the same level of efficiency in text editing, especially considering the very command-based nature of Vim (as opposed to the graphical nature of Sublime Text without plugins). Instead of extremely repetitive keypress spam, awkward hand movements to reach the direction keys, and slow yet imprecise mouse point-and-click action, Vim appears to trade much of that for highly efficient key combinations and hand movements, albeit at the cost of requiring the user to memorize and commit them to muscle memory. Similar can maybe be said with Vim-inspired tools such as ranger.

And in addition to making text editing more efficient, I’m also interested in becoming familiar with more advanced features and extensions, and simply exploring more tools and seeing what fits.

Of course, I could’ve already started using such things with Sublime Text by exploring unused features and adding extensions. However, keeping access to the convenience of simply pointing and clicking or copy pasting content around instead of using the editor’s features and finding cool plugins is a tempting escape route from the steep learning curve of becoming more efficient. I suppose you can say that imposing restrictions is a way of breaking out of my current local maximum in efficiency, with the hopes of finding a better local maximum.

2) Learning command line tools allows me to be versatile, with Vi and Vim being particularly ubiquitous on *nixes.

Even if I never ultimately pick up Vim, Vi/Vim could make simple text editing tasks over command line more comfortable than nano. But if I do pick up Vim and such tools, it’ll open up the possibility of doing a large amount of work over SSH rather than forcing me to form awkward workarounds such as file transfers and local file editing, and I can immediately work comfortably on many machines since I’d likely just pick up tmux and Vim.

Additionally, a CLI-based workflow will keep me in the command line. Considering how much work is done there, I’m expecting that this will make things smoother as I’d simply stay where I am and use all the same tools rather than switching between windows.

3) Vim appears highly standardized and well-supported, open-source, and will probably not change in unnecessary ways for a very long time.

I can’t quite verify the truth of that just yet since I haven’t explored Vim yet nor am I good with future projections, but having workflows be highly standard/supported and enduring like this is always a plus, ensuring what you learn and the extensions you write for something will remain relevant for a very long time.

Counter to this include proprietary and poorly supported tools. As nice as Word is, it’s still subject to Microsoft’s whims. The GUI changes over time, it’s terribly unstable, Linux support is non-existent, and while compatibility from older files will probably be excellent for some time thanks to the popularity of Word, I feel I can trust Latex more for files to remain compilable for a very long time, if not being much more easily solved by defining or refactoring commands than the more proprietary files of Word. Granted, Latex IDEs and text editor plugins can change or die by the dev’s hands, but at least Latex isn’t dependent on them to work. Stability might also be a mixed bag depending on your IDE/editor, but again, if something’s broke, just replace it.

(It should perhaps be clarified though that Latex is inherently different since it’s a typesetting system rather than a word processor, but let’s leave technicalities aside for now.)

4) It’s an exercise in learning technologies.

I unfortunately find that I get far too comfortable with what I know. Trying Vim out could help me be more comfortable breaking out of my comfort zone, which is something I think every tech professional must strive for to be competent at what they do.

And finally…

5) Dick-waving.

This one’s obviously absolutely non-essential, but as much as I’d like to say I’m much better than that… I’m probably not. In my simple mind, users of such high-skill-curve tools as Vim and Emacs get immediate street cred, their screens always look the most “cybery” (i.e. sorta like what you’d expect Hollywood 1337 h4x0r5 to have with cryptic text, fast-moving cursors, terminals, etc.), and editing looks impressively fast and efficient.

Of course, there are probably still a few potential issues with settling with Vim, the most evident being reliance on commands.

There will most certainly be times when Vi commands aren’t supported. An immediate example is that right now, I’m writing this post using wordpress.com’s post editor, and there will be times when I’d have to work with an IDE without my Vi emulation. Mistakenly using Vi commands and navigating with the HJKL keys everywhere else would almost certainly make me look and feel dumb while costing time to fix.

I also particularly dislike the design choice to stick with the HJKL keys for movement rather than JKL; since my typing style involves resting my right index finger on the J-key notch, and keeping roughly that amount of space between my hands. A suggested solution, however, is to not bother moving all four fingers over the HJKL keys and instead use the index, middle, and ring fingers on the JKL keys while multitasking the index finger to the H key when needed. That seems much nicer to me, so I guess I’ll give that a go.

Changing keyboard layouts (to different regional keyboards or even to something like DVORAK) is also made more problematic. Although command memorization by mnemonic is possible, I have a feeling some level of positional muscle memory might still be involved, especially with the HJKL movement keys. Though, it’s probably highly unlikely that I’d end up having to use a DVORAK or other exotic keyboard anyway, and the challenge of typing normally on them would be challenge enough.

So those are my current thoughts with adopting Vim and a more CLI-based workflow. While I have a few issues with becoming far too dependent on my tools, it’s probably still best to try going through the pain of the steep learning curve now with the hopes of adopting these new tools for a lifetime of high efficiency, or at least knowing I tried, being enlightened and inspired to continue improving my workflows, and simply for the fun of learning such a novel thing.

I’d like to think that I’m a good problem-solver. I really do. I’d like to think that when faced with complexity, I’m capable of calmly analyzing the situation in a logical manner, breaking it down, and figuring out what’s important. However, incredibly trivial things like this still slip past, potentially wasting hours of time in the most unproductive way imaginable. It’s never fun to realize that all your time just went down a black hole.

But you know what is fun? Reading about it. Maybe. Or at least writing about it, documenting the self-confidence kill chain with the hope that such mistakes never happen again (along with simply having something to look back to for a laugh). So for that, I decided to start a series of blog posts around these so-called “epic fails”, consisting of sporadic posts on cases such as this one. Or at least hopefully sporadic. If it were any more common, I’d never get anything done.

The cause of time wastage this time? A dead-simple command typo. Here’s the typo in action:

simshadows@norah volatility$ python2 vol.py -f ~/work/homework.vmem --profile=Win10x64_15063 --cache pcscan | tee ~/work/f_pcscan.txt
Volatility Foundation Volatility Framework 2.6
ERROR : volatility.debug : You must specify something to do (try -h)

Of course, I should’ve gotten the hint from the error that maybe I typo’d the plugin name but nope.

I believe the initial cause for me believing I had typed out the command correctly was that I was using a different installation of Volatility (the program I’m trying to use) perfectly fine up until that point. In particular, I was using the one installed by pacman. The fact that I got the error only after I switched over to one I cloned directly off Github was, to me, an indication that the Github version is somehow bugged.

Naturally, I started by googling for anyone else who had the same issue before moving on to more drastic measures. Unfortunately, the pacman version didn’t have any of a necessary component of Volatility called a “profile” that I needed to analyze the homework memory snapshot for class. And from the last tutorial class, I overheard someone saying they used Win10x64_15063 and found that to work, and that profile happened to be on the Github cloned copy. Clearly, this meant I had to do something with the Github copy, so I tried various things such as using different options and in different ways (like switching between short and long command options), copying files to the pacman installed version from the Github version (and in different ways including copying the profiles files, all of which produced weird errors), and trying the program directly on my mac (my Arch installation is a Virtualbox VM).

I also tried different Volatility plugins than this so-called “pcscan”. imageinfo worked, though I tried the other process scanning commands such as pslist… except I typo’d them all again with commands such as pclist. At this point in this retrospective write-up, it’s clear that I kept mentally substituting “ps” with “pc” for some reason.

It was only when I went back to the Volatility command reference page hours later that I realized pcscan was meant to be psscan. Imagine the shock I felt right after finding that.

Challenge assumptions, kids.

So I mentioned in my blog intro post that I’m interested in learning Japanese, followed by “again…” in parentheses, so I’d like to take a quick 5 minutes to expand on that.

I actually had two points so far where I’ve sorta started but ended up just stopping fairly quickly afterwards, hence the “again”. The first point was during the early weeks of 2015 semester 2 (maybe around August?), and the second point was early this year, when I impulse-bought Genki I during Kinokuniya’s Japanese textbook sale.

The first time, I spent my downtime travelling to/from uni doing various kana-memorization apps. I don’t quite remember how long, but it took me roughly a week to be capable of recognizing all the kana with a fair amount of accuracy, though I’d usually still take a while (particularly for similar-looking kana). But in theory, if anything was written purely in kana, I’d be able to read the syllables. However, I can’t quite recall why I stopped there, but I suppose I just got a bit lazy.

The second time, Kinokuniya Sydney had textbooks on sale for 20% off, so I impulse-bought a copy along with a beginner’s grammar dictionary. I then went and did the first chapter that night. It was interesting, but I ended up picking up a new programming project, so I decided that while I’m still out of the habit, I may as well hold until I find time, and instead focus on programming. If I went too deep, then if I’m finding myself too busy to dedicate to learning, I’d still need to maintain what little I learnt of Japanese, which would’ve been an inefficient pain. The idea then was that I’d time my start to when I’m committed to spending regular time not just maintaining, but actually learning Japanese.

So I suppose that’s a somewhat fair justification. Right now, with my priority is learning tech and becoming as competent a computer and software engineer as I possibly can be. But on the other hand, couldn’t I just try to manage my time a little bit better to squeeze a tiny bit of Japanese each week? It didn’t even take long to finish the first chapter of Genki (maybe 2 hours?), so perhaps I could just spent about 3-4 hours a week, adding up over a period of a year. I’d also have the added benefit of reinforcement over time. Not that I’m well-read in the relevant fields of psychology, neuroscience, or the likes, but I’m thinking it might be advantageous to learn something over a very long period of time, albeit sparsely, compared to smashing through the same amount of content in a short amount of time.

So I suppose I should come clean a bit with a problem I’m having with starting off: I’m scared to shit by the concept of having to learn Kanji.

Rote learning has always been a problem for me. Rote is still very necessary for all learning though, as memorizing allows one to not have to refer to a textbook every time a thing is brought up. When having to do basic arithmetic, no decently educated person would have to look up a textbook to figure out the purpose of this concept of adding two numbers and how to apply addition; you sorta just know it already to enough of an extent. Memorizing words and spelling is especially necessary in language as it’s precisely how ideas are encapsulated and communicated (or at least as I understand natural human language).

Kanji, however, is incredibly intimidating. At least with English, the letters can roughly correspond to syllables. Same of course can also be said with kana when it’s used in Japanese, and similarly with many languages that use a Latin-derivative alphabet, Cyrillic (I think? I actually have no idea how Cyrillic works), or hangul when used in Korean. Kanji, on the other hand, rote-learning hell. Or at least, nothing I’ve read has really convinced me otherwise.

To illustrate the problem as I see it from an ignorant outsider’s perspective, I’m imagining each Kanji to be a unique character with multiple ways to pronounce and understand it. Even with Kanji being conjoined in some way to form compound words and other such things to express more complex ideas, sources tend to indicate some 2000 kanji for a high enough degree of fluency (~2000 for JLPT N1 if that’s any indication), or hundreds for basic comprehension (~100 for JLPT N5, up to ~650 for N3). Even mere hundreds alone sounds like insanity to have to learn the multiple unique pronunciations and meanings of each of them.

Though, it seems that I can at least expect some degree of consistency, with concepts such as radicals to maybe make things easier.

But who knows, maybe it might end up being easier than I’m currently imagining it to be. I suppose I can’t really say until I just dive right into it and actually learn rather than speculating. Once the semester finishes, I think I’ll give it another shot and actually follow through.