A few of my favorite: Woodcased pencils (with erasers)

Throughout this piece, I link to products on CWPE. This post has been a couple of months in the making, and in the midst of my idleness, CWPE announced that they’re closing down in 2021-11. I’ll try to find other stockists in the future and update the links, but at least two of the recommendations were exclusive to the shop, so… all around disappointing.
I have a Thing I’ve been meaning to start trying to write and draw. And while I keep failing to start trying in a meaningful sense, I have done the most important first step – going through a bunch of my woodcased pencils, buying a couple more to try out, and figuring out what still feels best to me. You get more of a selection, and a better selection if you go for pencils without that nubby little eraser on the end.

Two slim keyboards

I’m writing this on a keyboard I ordered from Drop quite some time ago, the Morgrie RKB6801. My daily driver up until now has been an also-recently-acquired Keychron K3. Both of these keyboards use slim switches; prior to this, I was using another Keychron keyboard with full-size Keychron optical switches. I do much of my writing/whatever from bed, and the way I configure myself doesn’t really work out well with a traditional mechanical keyboard; the overall height is just too chunky. Fortunately, a lot of progress is being made in the mechanical keyboard space; simply getting a Bluetooth model was an exercise in frustration but a few years ago.

I should say that I am a clicky-clacky typist. My favorite switches ever are the IBM Model M buckling springs, but in a modern setting I gravitate toward Matias’s take on the Alps switch. Few keyboards/keycaps are designed around Alps, so the next best switches for me are Cherry Greens. This is the sort of baseline that I’m working with for this post-that-approximates-a-review. As I mentioned, I had been using a Keychron K6, with Keychron’s optical simulacra of Cherry Blue switches. Blue is already a step down from Green for me, but I was making do with it. Optical switches are conceptually quite interesting to me; the core mechanical elements that provide the tactile satisfaction can be left in place while changing the electronic element to something solid state. Had I not wanted to dabble in this, I could’ve bought the hot-swappable version of the K6 and swapped in some Cherry Greens. I’m glad I didn’t, because as I mentioned, the keyboard is just too chunky for the intended use-case. You mention this sort of thing around mechanical keyboard groups, and you get chastised, because of course it’s chunky! The big fat switches make the magic! Which… both things can be true. It can be an unfortunate reality while still being… the reality.

The optical switches themselves were… okay? Most of the keyboard was fine, though not quite comparable to Cherry Blues, but the wider-than-letter keys? They squeaked like a poorly-oiled mouse. It was quite annoying. Yet the concept still compelled me enough that I opted for the optical switches on the K3 as well. These switches are definitely better in that they are not squeaky! And overall, they feel less mushy as well. Putting aside the size advantage, these actually feel better to type on than the full-sized Keychron optical switches. The other keyboard that I received, the Morgrie, uses traditional mechanical switches, albeit in a slim form-factor by Kailh. While this post is the first long(ish) thing that I’ve typed on the Morgrie, I have put time into testing it, using it for day-to-day typing, speed tests. And I have thoughts about both keyboards…

Size, and form factor

Initially, I was put off by the size of the Morgrie. It is approximately the same depth as the K3, but noticeably wider. Despite this, it has a full row fewer of keys; the K3 has an actual function row. I use function keys fairly infrequently; I think my most common usage is F2 to edit tags in Acrobat1. I’ll touch on this more in the layout section, but it’s worth noting that there are just many more keys on the smaller keyboard. The reason the Morgrie is so much larger is that it has a fairly prominent bezel surrounding the keys. I feel like this might annoy me on a desk, but it’s kind of nice having a place to rest the ol’ thumbs when typing in bed. The thick aluminum (I believe) bezel also makes the Morgrie heavy compared to the K3. It is solid. It feels well-built; the K3, while perfectly fine, feels flimsy in comparison. Overall, I don’t mind the size of the Morgrie as much as I expected, but the K3 gets the credit for its ability to cram far more into a noticeably smaller footprint.

Layout

These are both compact keyboards without number pads. They both have cursor keys and a right-hand column for page navigation keys. My laptop has a similar configuration. One thing that I’ve learned is that this stack of four keys on the right-hand side is a common decision for navigation keys – but unlike traditional layouts, nobody has decided on a standard for this. The three keyboards have these four keys from top-to-bottom:

I don’t have much of an opinion between my laptop and the K3 except that I wish they were consistent. I guess the K3 makes more sense to me, but they’re both fine. The Morgrie, on the other hand, is nonsense. Delete is at the bottom, as far from Backspace as possible. This is ludicrous. Less egregious, but annoying to me is Pg Up and Pg Dn being on the function layer instead of Home and End. I’d also prefer Insert be on the primary layer instead of PrtSc, but at least it has Insert – this key cannot be input from the K3 (this keyboard only comes backlit, and wastes a perfectly good key on this). Considering WSL2 seemingly has no direct interaction with the Windows clipboard, and I have to rely heavily on ShiftInsert… this was miserable.

Despite the Morgrie displaying symbols for brightness, transport, volume, &c. on the function layer seems to send the codes for Function keys. I could go either way with this, as I really only miss having Mute as quick access, and as previously mentioned, I only really use F2. A second function layer would have been nice here; my old K6 (which also lacks a function row) worked this way. Esc and `/~ share a key, with the latter on the function layer. Despite my heavy vim usage, I don’t touch Esc much. Since I remap Caps Lock to Ctrl on every machine I own, Ctrl[ is less of a stretch despite being a chord. With this in mind, I’d prefer `/~ on the primary layer, but I understand the decision. The extra row of the K3 pays off here.

The only other notable difference is the location of the Fn key; next to Space on the Morgrie and one to the right (between Alt and Ctrl on the K3. I use these modifiers infrequently, and don’t really have a preference, though again… standardization would be nice. Overall, it’s hard to say which layout I prefer; they each have a unique critical failure: the lack of Insert on the K3 and the absurd positioning of Delete on the Morgrie. Utterly bizarre decisions.

Switches and keycaps

TL;DR: The Morgrie wins on both fronts. The keycaps are PBT and feel great; K3 has ABS keycaps with extremely visible sprues. I got the Morgrie in white with orange lettering, and it’s rather pretty. Depending on which backlight you get, the K3 keys are either light or dark grey, with clear lettering for the backlight. They’re unoffensive, but the white Morgrie is just… kind of fun. I don’t know my way around keycap profiles very well, but the K3 uses slightly curved chiclet-style keys, while the Morgrie is more traditional. I don’t have a super strong opinion on this; I find that I orient myself more easily but get lost quickly on chiclets, and therefore type more quickly overall on more traditional caps.

I mentioned that the slim Keychron optical switches are nicer than the full-sized Keychron optical switches. This is certainly true, but the Morgrie’s Kailh Choc switches are much nicer than both. The Kailh Whites supposedly have a lower actuation force than the Keychron Oranges2, but it feels higher. All in all, I find the Kailhs to be a much nicer typing experience. If I sell off some stuff, I might try the traditional mechanical Gateron version of the K3. At the very least, if I found myself preferring the size/form-factor of the K3, I could replace them with Kailh switches now that I know I’m a fan.

The K3 switches have one very cool thing going for them – they accept regular Cherry keycaps. Obviously full-sized ones will be a bit chunky on the board, but still at a lower profile than the same caps on full-sized switches. More importantly, it’s just… an obvious standard. It’s wild to me that both Cherry and Kailh opted to come up with new, incompatible keycap mounts for their low profile switches. This was always a problem with Alps as well; so many people use Cherry that caps for anything else are hard to come by. The K3 switches are also hot-swappable, and optical switches of course don’t rely on a mechanism that will wear. I doubt this is really a sticking point. Finally, one of the keys on my K3 was improperly assembled from the factory, the spring was all out of place; I easily disassembled this and repaired it myself, but… shame I had to.

Miscellanea

I mentioned the K3 only comes backlit. There are two versions: RGB- and white-LED backlit keys. I opted for white; RGB LEDs just… don’t look very good, in my experience. Being a touch-typist, I tend to disable backlighting anyway, and would prefer a version with a useful key and no backlight in lieu of a key I accidentally press constantly, forcing me to cycle through a bunch of ridiculous effects. Lastly, while there is an option to turn the backlight off entirely, there is no option to turn it on entirely; the closest thing is an effect where every key is on, but any given key briefly shuts off when you depress it. This is silly. Oh, there’s also no brightness setting. My laptop, by comparison, has no ridiculous effects and two brightness settings. This is useful!

Both keyboards have Bluetooth, both support three devices. The K3 uses a function layer for this, whereas the Morgrie has three dedicated buttons. I have no preference on this. I haven’t had any issues with Bluetooth on either board yet, though I also haven’t really stress-tested it. Unlike my Bluetooth IEMs that I pair to my phone, I don’t really have a need to test how far I can stray from my device. Both keyboards charge via USB-C, and can in fact be used wired via USB-C. The K3 has a switch to go between wired and wireless, the Morgrie does not. I’m sure there’s an advantage to one of those approaches, but I’m not going to try to suss it out.

The Morgrie has a nice tactile pushbutton for power on the back, while the K3 has a tiny slide switch. Both are fine, but the Morgrie is nicer in my opinion. The K3 will go into a sleep mode quickly; the Morgrie does not seem to, with the company claiming to have one of the longest standby times. I’d rather the keyboard just go to sleep. The K3’s bezel-less, chiclet design makes for easy cleaning; despite this, it came with a thin plastic cover. Neither of these things is true of the Morgrie.

Ultimately, I really think I prefer the Morgrie, and I’m tempted to buy another in the lovely powder blue color. It’s just very nice to type on. The solid build, the Kailh switches, the comfortable keys… I get on with it well. I sure do think that Delete placement is regrettable, though.


Open Mic Aid (external)

Hello, my tiny audience. I’ve been teleworking for… three weeks now? I think? I don’t know, I’m not trying to keep track. The reality is that we are all cooped up, likely for months, for good reason. Maybe some of us will find time to do things, maybe some of us will lose time. It’s… new. And hard. Really, really hard. For the time being, I’m financially secure. But a lot of people aren’t.

Keyboards, old and new

Reading a typewriter-themed Garfield strip recently, I got to wondering whether or not my typewriter (a Brother Charger 11) even had 44 keys. It does, barely. Despite modern computer keyboards still using the same core QWERTY layout from the 1800s, things are different enough that this was a perfectly reasonable thing to be unsure of. Then I got to thinking about all of these differences, as well as the weird holdovers (QWERTY itself notwithstanding) and… here, I suppose, are just a bunch of those things that I find interesting.

Kakoune

I’m not writing this post in vim, which is really a rather odd concept for me. I’ve written quite a bit about vim in the past; it has been my most faithful writing companion for many years now. Part of the reason is its portability and POSIX inclusion – it (or its predecessor, vi) is likely already on a given system I’m using, and if it isn’t, I can get it there easily enough. But just as important is the fact that it’s a modal editor, where text manipulation is handled via its own grammar and not a collection of finger-twisting chords. There aren’t really many other modal editors out there, likely because of that first point – if you’re going to put the effort into learning such a thing, you may as well learn the one that’s on every system (and the one with thousands of user-created scripts, and the one where essentially any question imaginable is just a Google away…). So, I was a bit surprised when I learned about Kakoune, a modal editor that simply isn’t vim1.

Now, I’ve actually written a couple of recent posts in Kakoune so that I could get a decent feel for it, but I have no intention of leaving vim. I don’t know that I would recommend people learn it over vim, for the reasons mentioned in the previous paragraph. Though if those things were inconsequential to a potential user, Kakoune has some very interesting design ideas that I think would be more approachable to a new user. Heck, it even has a Clippy:

~                                                          ╭──╮   ╭───┤nop├────╮
~                                                          │  │   │ do nothing │
~                                                          @  @  ╭╰────────────╯
~                                                          ││ ││ │
~                                                          ││ ││ ╯
~                                                          │╰─╯│
~                                                          ╰───╯
nop          unset-option                                                      █
:nop            content/post/2018-06/kakoune.md 17:1 [+] prompt - client0@[2968]

Here are a few of my takeaways:

I guess there are far more negative points in that list than positives, but the truth is that the positives are really positive. Kakoune has done an incredible job of changing vim paradigms in ways that actually make a lot of sense. It’s a more modern, accessible, streamlined approach to modal editing. Streamlining even justifies several of my complaints – certainly the lack of a file browser, and probably the lack of splitting fall squarely under the Unix philosophy of Do One Thing and Do It Well. I’m going to continue to try to grok Kakoune a bit better, because even in my vim-centric world, I can envision situations where the more direct (yet still modal) interaction model of Kakoune would be incredibly beneficial to my efficiency.


decolletage.vim

The ‘screenshots’ in this post are just styled code blocks. There are likely some weird visual artifacts (like background colors not extending the whole width of the block), but the point is to show off the colors.

I’ve been using a hastily-thrown-together color scheme for vim, cleverly named ‘bcustom.vim’ for years now. It’s a dark scheme, peppered heavily with syntax highlighting. While slightly softer than most, it’s still a pretty typical, masculine scheme. I recently realized two things – I would like to use a more feminine, light scheme based on my general sense of pinkness1, and I actually find myself a lot more distracted by extensive syntax highlighting than I find myself aided by it. So I decided to start from the ground up, and build a minimalist, light pink colorscheme, ‘decolletage.vim’.

Again, part of the design decision was to keep the total number of colors used to a minimum. So, to start, here’s the basic scheme. You can see the line numbers, the basic scheme, a comment, an uncapitalized word (‘colors’), a misspelled word (‘matchTypo’), a fold, a search result (‘cterm’), an error (‘#123456’), a visual selection (‘Decolletage’), and matched parentheses:

193 194 195 “Adjust things re: markdown. colors only matchTypo if decolletage loads 196 if g:colors_name==“decolletage” 197 +— 5 lines: hi! link markdownBlockQuote CursorColumn―――――――――――――――――――――― 198 199 hi markdownBlockQuote ctermfg=none ctermbg=#123456 200 call DecolletageDiff(1)

It… looks a lot like this blog, I know. That truly wasn’t how I set out to do things, it’s just my aesthetic. Let’s examine a little -- More --, like that right there, which is how the more/mode message lines appear. Or these status lines:

2:~/.vim/colors/decolletage.vim [RO] [vim][utf-8] 74,1 71%

2:~/.vim/colors/decolletage.vim [RO] [vim][utf-8] 74,1 71%

2:~/.vim/colors/decolletage.vim [RO] [vim][utf-8] 74,1 71%

…Active, inactive, and insert, in that order. Yes, it may be weird, but I like having a blunt, obvious indication of which mode I’m in. And I associate blue with insertion, so that’s my choice for insert. This was a feature of my hacked-together ‘bcustom.vim’ as well – it’s pretty nice to have.

There are two variants for diffs in decolletage.vim. One is more traditional, very obvious with highlighted backgrounds and the like; and the other is fittingly minimal. Here’s the standard version (you also get to see a split line here; it’s predictable) (oh, and non-printing characters):

1 if this { │ 1 if this { 2 that │ 2 that 3 → the other↲ ---------------------------------- 4 print “goodbye” │ 3 print “goodbye” 5 → return true↲ │ 4 → return false↲ 6 } │ 5 }

…and here’s the more jarring, less obviously-a-diff minimal version:

1 if this { │ 1 if this { 2 that │ 2 that 3 → the other↲ --------------------------------- 4 print “goodbye” │ 3 print “goodbye” 5 → return true↲ │ 4 → return false↲ 6 } │ 5 }

I’m fully on board with the minimal version, but it doesn’t seem right to have as a default, so it isn’t. Add call DecolletageDiff(1) to your .vimrc to use it. Alternatively, you can choose it as a default, and call DecolletageDiff(0) for filetypes that seem to desire a more blatant diff.

:set cursorline in decolletage.vim looks like this:

254 255 this is the line that the cursor is on _   256

I’m not a huge fan of cursorline, but I do see value in being able to quickly find the current line, so for a more subtle cursorline, we can call DecolletageNecklace(0):

254 255 this is the line that the cursor is on _ 256

Finally, there is an option to actually add some syntax highlighting, via call DecolletageFreckles(1). It’s rudimentary so far, and based on the default colors that vim would use in a 16-color terminal.

317 Constant 318 Identifier 319 Statement 320 PreProc 321 Type 322 Special 323 Number 324 Boolean

…this probably needs tweaking, but it is there if you want it. And again, implementing it as a function call means you can pop it on and off at will as you’re flipping through a file. So, that should be adjusted, I’d like to add some color for netrw, and I need to implement it as GUI colors as well2. But, for the time being (and particularly for my own specific needs), decolletage.vim looks pretty good, and is available for preliminary testing here.


Examining 'my .vimrc'

I realized the other day that, as much as I’ve read through the vim documentation and sought out solutions to specific problems, I’m still constantly learning things about it almost accidentally as I stumble across how person x or y approached some specific task. It occurred to me that a lot of people post their .vimrc files online1, and flipping through a bunch of these could prove insightful. So I googled ‘my vimrc,’ I searched github, I poked around… a lot. It’s worth noting that some of my observations here are biased in that my vim use is primarily prose (generally in markdown), followed by HTML/CSS/JS, followed by recreational code. I don’t deal in major coding projects consisting of tens of thousands of SLOC for production systems. What works for me is almost certainly atypical.

Something that I’ve been meaning to write about is my aversion to things that make any given setup of mine less portable – and that includes things like keyboard mappings that simply give me muscle memory that only works on my configuration. I see a lot of this sort of stuff in the .vimrc files of others, and for the most part it’s just stuff where I’d rather take the efficiency hit but know how to do it in a portable way. For example, a lot of people map something to the ‘oh shit I forgot to sudo vim’ sequence, !sudo tee % > /dev/null. I fully understand how that sequence works, but to me it’s such an oddball use of tee that I feel like if I got too accustomed to not typing it, I might accidentally do something really weird on a system that isn’t my own2. Similarly, I see a lot of mappings like Ctrlh to jump left a window instead of Ctrlwh. This sort of thing saves you one keystroke, while completely demolishing one of the key points of using vim – that of context and modality. Ctrlw means ‘get ready to do some stuff to some windows’, be it moving, resizing, closing, whatever. It’s not a ‘mode’, per se, but it fits vim’s modal model.

I know there’s a huge community of vim plugin development, but I was still a little surprised to see so much reliance on plugins (and plugin managers3). There are a few plugins that I consider rather essential, like surround.vim, but again I largely try to do things the native way when possible, so I try not to extend vim too heavily.

I don’t strictly adhere to the aforementioned policy, particularly for things that I know I won’t forget how to do in a portable way (like autocd in the shell), or things that are purely conveniences (like mapping CtrlL such that it works in insert mode). One clever idea that I saw along these lines was remapping Enter to clear the search highlight before doing its thing. Which, I don’t think I’ll adopt, but it is a handy idea – those highlights can get a little distracting.

I see a lot of mappings of j to gj which again just feels so un-vimlike. Up/down movements corresponding to screen lines instead of content lines is something that actually bugs me in other editors. Worse, this mapping makes counts tricky to use in a . or macro situation, which is particularly weird when a lot of the same people use :set relativenumber. Another common mapping is to do gv after > or <, so that you can repeatedly hit it and have the same visual block selected. But… the vim way would be to use a count instead of mashing the button four or five times.

People remap <Leader> to , a lot, which to me feels even more awkward than \. I’ve seen weird insert-mode mappings to jump back to normal mode, like jj, which is fair – Esc is kind of a ways away. But the real trick to that is twofold: first, remap your useless Caps Lock to Ctrl system-wide, and then train yourself to use Ctrl[ instead of Esc.

Doug Black’s post about his .vimrc has two good pieces of advice: don’t add things to your .vimrc that you don’t understand, and don’t use the abbreviated forms of settings/commands4. I see a lot of files that don’t seem to conform to this rather basic advice. Things like hardcoding t_Co without performing any checks – at best it’s merely not portable, but it reads like ‘a thing that I did that solved a problem’ vs. a setting that the user actually understands.

I did have some positive takeaways from this little journey. While I don’t use macros much (I opt for :normal more often), I learned about :set lazyredraw which speeds up macro execution by waiting until the end to redraw the screen. I had somehow forgotten that vim supports encryption, and that it defaults to the laughable pkzip scheme, so :set cryptmethod=blowfish2 is making its way into my .vimrc. Someone added syntax for two spaces after a period, which is a smart idea – I would link that right to Error. It would be better (perhaps) to add that as a wrong/bad spell, but I think a highlight would work.

Curious to me was the number of people who put things in their .vimrc files that are specific to filetypes (etc.). This is stuff that I generally relegate to .vim/ftplugin/ and .vim/ftdetect/. For instance, I have some folding rules in place for markdown files used in my blog. I add the filetype hugo with a ftdetect script, and then lay out some syntax rules in .vim/ftplugin/hugo_folds.vim. I don’t know if my approach is better or worse – it definitely makes for a big pile of files. Is this more or less organized than just maintaining it in a tidy .vimrc? Something to think about.

This adventure down the dotfile rabbit hole taught me more than anything, I suppose, about how other vim users twist vim’s arm to make it less vimlike. Interestingly, I ran into a couple of files that were updated over the years, and the users seemingly adapted to more vimmy ways. I suspect a lot of these things come of a sort of feedback loop – a vim beginner sees a .vimrc file online with map <C-K> <C-W>k and thinks ‘why not shave off a keystroke?!’ They end up posting their .vimrc file a year down the road when they feel they’ve perfected it, and another novice stumbles across it, thinking ‘why not shave off…’ Regardless, it’s pretty neat just how many .vimrc files are floating around there, given how customizable and extensible vim is. Even approaches that are totally opposite one’s own likely have something previously unknown or unthought of.


Reversing Markdown

Most writing that I do, I do in vim using Markdown. Either for applications that support it natively (like Hugo, which powers this blog), via pandoc, or directly into Word via Writage. Going from Markdown is never really a problem, but trying to convert from pretty much any format to Markdown is pretty much always frustrating.

The reason for this is baked into the format — the format is designed to be flexible. It’s designed to be human-readable, and therefore most structural elements can be reached via several paths. For example, italics can be reached either by _this_ or *this*, and bold is achieved via either __this__ or **this**1. This allows a variety of personal styles. Since _this_ is a universal fallback for communications that don’t afford italics2, that is how I always do italics. And, on the rare chance that I use bold, I do it **this way** to readily set it off from the italics formatting. Ultimately, there are four combinations here, though, and software that is rendering to Markdown has to make its own style choices.

There are other decisions. Markdown, for some ungodly reason, promotes hard-wrapping (which I loathe). Markdown supports two different sorts of headers, one of which I find aesthetically pleasing, and then Setext-style. But again, a renderer has to either support a ton of options or make these decisions for you. Writage, for example, makes pretty much every decision opposite how I’d like it. Which is ok, but it means I spend a lot of time in vim reprocessing things.

I’ve been considering writing about this for months now, mostly to complain about Writage. But, this isn’t Writage’s fault. And I’d hesitate to call it a fault at all, it’s just a tradeoff that comes with a flexible markup language. I don’t think I would have made a lot of the decisions that Gruber made in establishing this format… But those decisions have led to it being a de facto standard for human-readable markup. Rich text would be worse off had this gone any other way.


Dotfile highlights: .vimrc

I use zsh, and portability across Darwin, Ubuntu, Red Hat, cygwin, WSL, various gvims, etc. means I may have pasted something in that’s system-specific by accident.

New series time, I guess! I thought for the benefit of my future self, as well as anyone who might wander through these parts, there might be value in documenting some of the more interesting bits of my various dotfiles (or other config files). First up is .vimrc, and while I have plenty of important yet trivial things set in there (like set shell=zsh and mitigating a security risk with set modelines=0), I don’t intend to go into anything that’s that straightforward. But things like:

"uncomment this on a terminal that supports italic ctrl codes
"but doesn't have a termcap file that reports them
"set t_ZH=^[[3m
"set t_ZR=^[[23m

…are a bit more interesting. I do attempt to maintain fairly portable dotfiles, which means occasionally some of the more meaningful bits start their lives commented out.

Generally speaking, I leave word wrapping on, and I don’t hard wrap anything1. I genuinely do not understand the continuing practice of hard wrapping in 2018. Even notepad.exe soft wraps. I like my indicator to be an ellipsis, and I need to set some other things related to tab handling:

"wrap lines, wrap them at logical breaks, adjust the indicator
set wrap
if has("linebreak")
	set linebreak
	set showbreak=…\ \ 
	set breakindentopt=shift:1,sbr
endif

Note that there are two escaped spaces after the ellipsis in showbreak. I can easily see this trailing space because of set listchars=eol:↲,tab:→\ ,nbsp:·,trail:·,extends:…,precedes:…. I use a bent arrow in lieu of an actual LFCR symbol for the sake of portability. I use ellipses again for the ‘more stuff this way’ indicators on the rare occasions I turn wrapping off (set sidescroll=1 sidescrolloff=1 for basic unwrapped sanity). I use middots for both trailing and non-breaking spaces, either one shows me there’s something space-related happening. I also only set list if &t_Co==256, because that would get distracting quickly on a 16 color terminal.

Mouse handling isn’t necessarily a given:

if has("mouse") && (&ttymouse=="xterm" || &ttymouse=="xterm2")
	set mouse=a "all mouse reporting.
endif

I’m not entirely sure why I check for xterm/2. I would think it would be enough to check that it isn’t null. I may need to look into this. At any rate, the variable doesn’t exist if not compiled with +mouse, and compiling with +mouse obviously doesn’t guarantee the termcap is there, so two separate checks are necessary.

I like my cursors to be different in normal and insert modes, which doesn’t happen by default on cygwin/mintty. So,

"test for cygwin; not sure if we can test for mintty specifically
"set up block/i cursor
if has("win32unix")
	let &t_ti.="\e[1 q"
	let &t_SI.="\e[5 q"
	let &t_EI.="\e[1 q"
	let &t_te.="\e[0 q"
endif

Trivial, but very important to me:

"make ctrl-l & ctrl-z work in insert mode; these are crucial
imap <C-L> <C-O><C-L>
imap <C-Z> <C-O><C-Z>

I multitask w/ Unix job control constantly, and hugo server’s verbosity upon file write means I’m refreshing the display fairly often. Whacking Ctrlo before Ctrll or Ctrlz is easy enough, but I do it enough that I’d prefer to simplify.

I have some stuff in for handling menus on the CLI, but I realize I basically never use it… So while it may be interesting, it’s probably not useful. Learning how to do things in vim the vim way is generally preferable. So, finally, here we have my status line:

if has("statusline")
	set laststatus=2
	set statusline=%{winnr()}%<:%f\ %h%m%r%=%y%{\"[\".(&fenc==\"\"?&enc:&fenc).((exists(\"+bomb\")\ &&\ &bomb)?\",B\":\"\").\"]\ \"}%k\ %-14.(%l,%c%V%)\ %P
endif

I don’t like my status line to be too fancy, or rely on anything nonstandard. But there are a few things here which are quite important to me. First, I start with the window number. This means when I have a bunch of splits, I can easily identify which I want to switch to with (say) 2Ctrlww. I forget what is shown by default, but toward my right side I show edited/not, detected filetype, file encoding, and presence or lack thereof of BOM. Here’s a sample:

2<hfl.com/content/post/2018-02/vimrc.md [+][markdown][utf-8]  65,6           Bot

That’s about everything notable from my .vimrc. Obviously, I set my colorscheme, I set up some defaults for printing, I set a few system-dependent things, I set some things to pretty up folds. I set spell; display=lastline,uhex; syntax on; filetype on; undofile; backspace=indent,eol,start; confirm; timeoutlen=300. I would hesitantly recommend new users investigate Tim Pope’s sensible.vim, though I fundamentally disagree with some of his ideas on sensibility (incsearch?2 autoread? Madness).


Personal Log

For reasons that are not really relevant to this post, I am in search of a good solution for a personal log or journal type thing. Essentially, my goal is to be able to keep a record of certain events occurring, with a timestamp and brief explanation. Things like tags would be great, or fields for additional circumstances. Ideally, it’ll be portable and easily synced between several machines. Setting up an SQLite database would be a great solution, except that merge/sync issue sounds like a bit of a nightmare. jrnl looks really neat, but I haven’t been able to try it yet due to a borked homebrew on my home Mac1 and a lack of pip on my main Win machine. While syncing this could also be a chore, and there would be no mobile version, the interface itself is so straightforward that writing an entry could be done in any text editor, and then fed line-by-line into the command.

But I haven’t settled on anything yet, so I was just kind of maintaining a few separate text files using vim (Buffer Editor on iOS), and figuring I’d cat them together at some point. But I got to thinking about ways I can make my life easier (not having to manually insert entries at the right spot chronologically, etc.), and came to a few conclusions about ways to maintain a quick and dirty manual log file.

First thing was to standardize and always use a full date/timestamp. Originally I was doing something like:

2018-01-29:
    8.05a, sat on a chair.
    10.30p, ate a banana.

2018-01-30:
    [...]

…which is very hard to sort. So I decided to simply preface every single entry with an ISO-formatted stamp down to the minute, and then delimit the entry with a tab (2018-01-29T22.30 ate a banana.). As a matter of principal, I don’t like customizing my environment too much, or in ways that will lead to my forgetting how to do things without customization. I don’t, therefore, have many custom mappings in vim, but why not simplify adding the current date and/or time:

"insert time and date in insert mode
imap <Leader>d <C-R>=strftime('%F')<CR>
imap <Leader>t <C-R>=strftime('%R')<CR>
imap <Leader>dt <C-R>=strftime('%FT%R')<CR>

Leaderd for ISO-formatted date, Leadert for ISO-formatted time (down to minutes), Leaderdt for both, separated by a ’T’. If everything is formatted the same, with lines beginning in ISO time formats, then every entry can readily be sorted. Sorting is simple in vim, :sort or, to strip unique lines, :sort u. I think that it’s more likely that the merge operation would happen outside of vim, in which case we’d use the sort command in the same way: cat log1.tsv log2.tsv >> log.tsv && sort -u -o log.tsv log.tsv. sorting in place like this was a new discovery for me; I had always used temporary files before, but apparently if the output file to sort (specified by -o) is the same as the input file, it handles all the temporary file stuff on its own.

I think it’d be neat to establish a file format for this in vim. Sort upon opening (with optional uniqueness filtering). Automatically timestamp each newline. Perhaps have some settings to visually reformat the timestamp to something friendlier while retaining ISO in the background (using conceal?). The whole thing is admittedly very simple and straightforward, but it’s a process that seems worthwhile to think about and optimize. While most journaling solutions are much more complicated, I think there is a lot of value in a simple timestamped list of events for tracking certain behaviors, etc. I’m a bit surprised there isn’t more out there for it.


A few of my favorite: Pink pencils

I write a lot. I carry many bags. I’m untidy. I own and use many mechanical pencils. Some of them good, some of them bad, most of them pink. Here are my favorites.

Pentel Sharp Kerry:
The Kerry is hands-down the best pencil I own, in a very practical sense. It’s not beautiful; its oddly shiny-and-gridded midsection that looks grippy but is too high to function as such is just gaudy. The pencil was introduced at least 30 years ago, but I can’t imagine that ever looked good. But it’s such a well-engineered, functional pencil that it’s hard to rail on too much. It’s kind of the pencil version of 70s Japanese ‘pocket pens’ in that it has a cap, and it ‘grows’ to a usable size when said cap is posted. A pencil introduces its own challenges, of course, so the cap actually has its own lead advance button (which contains the eraser) that interfaces with the main advance. The cap obviates the need for a retraction method, so the Kerry lives comfortably in a pocket or a bag. I don’t have a bag without a Kerry in it.
Uni Kuru Toga High Grade:
Uni’s Kuru Toga is one of the most meaningful innovations in mechanical pencil mechanisms as far as I’m concerned. With a 2.0mm lead, or possibly even down to a 1.3mm, one might sharpen their lead with a purpose-built rasp or a lead pointer. Get much narrower, and your leads are all over the place. I use 4B whenever possible, and 2B otherwise, so this is less of a problem for me, but it’s still nice to find ways to mitigate problems. The Kuru Toga mechanism rotates the lead by a tiny amount every time you press it to paper. This mechanism is a bit ‘spongy’, perhaps, almost like a pencil with a suspension mechanism. I found it very easy to adjust to, but I’ve heard of others taking issue with it. The High Grade has an aluminum grip, which I like the weight and feel of, but others may prefer the rubber grip model.
Pilot Clutch Point:
This pencil is fairly maligned, and I understand why. The aforementioned pencils (and the following pencils) all use an internal clutch mechanism, and have a straight lead sleeve. Straight lead sleeves are great for draughting; they slide perfectly along a straightedge. I, personally, don’t like them all that much for writing, however. The internal mechanism brings with it other advantages. Keeping the mechanism protected, and having the lead held straight by the sleeve before the clutch means far less breakage. The Pilot Clutch Point exposes the clutch right at the front of the pencil, and if you don’t treat it with respect, it will jam. Badly. But when it works, it has a nice, pointy mechanism that will hold the shortest bits of lead known to humankind. It may very well be my favorite pencil for everyday writing.
Pentel Sharp Pocket:
The baby sister of the Kerry, I suppose? Much thinner, slightly shorter, and with a much more Biro-like cap that doesn’t really extend the pencil whatsoever. Great for attaching to a diary or the like. Works as well as any Pentel does. Very light.
Staedtler 775:
I guess the pink one is only available in Korea, but it does exist, and one can find it on eBay, so I say it counts. The 775 is a classic draughting Staedtler. It has a retracting point, but you have to ram it in to get it to do so. This has its ups and downs, being a simple retraction system makes it incredibly steady when engaged. But it’s also hard to disengage, and you risk breaking the lead or bending the sleeve.
Zebra Color Flight:
A really cheap pencil, but bonus points for coming in three shades of pink. It also has one other neat trick up its sleeve – much more eraser than the typical mechanical pencil, extended by rotating the advance. The plastic feels cheap, nothing to write home about. But considering how cheap they can be, the Zebra Color Flight pencils are actually pretty nice.

Alphasmart Neo2

I’m writing this from Tuckahoe State Park, the first leg of a multinight car camping trip which I (for practice, I suppose) opted to treat like a backpacking trip. My goal was to fit everything, aside from food (handled as a group), that I needed in or on a 30L pack for the one evening here followed by three in the sand at Assateague Island. Good way to try out a few things for when I ordinarily need to pack food but fewer clothes. So, why am I wasting precious pack space on a writing device?