This is Google


Okay, I’ll ask because apparently, I wasn’t using Inbox fully: huh?

Best as I can tell, they rolled in a few of the features in the latest update to Gmail, including the ability to snooze emails.


It’s not about the features, it’s about the UI. It’s really all about that big green check mark.


You’d be surprised. I mean…

Random Guy: “MINIX exists, so why should I write my own Unix-like OS for PCs. That’s crazy talk!”
Linus Torvalds: “Hey guys, I started working on this new Unix-like OS. Anyone want to help?”

If some programmer/group of programmers with the necessary skills are clamoring for it, it will get done. If course, if no one gives a rat’s ass, then it won’t get done. And maybe that’s why Inbox is going away? Not enough people gave a rat’s ass about it.

Eh, it’s not quite the same. I actually felt constricted by the Inbox UI and it didn’t work with my preferred work flow and it was taking me longer to do the kinds of things I do in Inbox vs. classic GMail.

Of course, you probably shouldn’t be talking about UIs given how you insist on using a basically Model T text editor (vim) instead of something more modern.

Okay, Vim is probably more like a Model T that someone bolted on a giant ass spoiler and coffee can-sized exhaust tip to than a classic Model T, but my point still stands.


You’re supposed to change yourself to match the software, not try to force the software to change to match the way you do things already.

Vim is not a Model T. In fact, it’s a lot like Inbox. Clean and not a cluttered mess. An empty box that you type text into. Nothing more, nothing less. A timeless design. GMail is a lot like those garbage IDEs everyone uses. A cluttered kitchen sink mess that went out of style last decade.


[quote=“Apreche, post:284, topic:511”]
You’re supposed to change yourself to match the software, not try to force the software to change to match the way you do things already.[/quote]
Feh, it depends if the software actually has comparable ways of doing what I want. I use an extensive bunch of filters, labels, and keyboard shortcuts to get around my GMail. Inbox’s UI, at least for the brief time I tried it (and I did try it) just did not scale for me.

Bah. Vim is a Model T. A Model T was a clean, uncluttered car too. However, it still was a Model T. Vim has an ancient, primitive UI designed for 300 bps dumb terminals in the 1970s.

If your beef about modern IDEs is about them being cluttered messes, fine, I won’t necessarily argue about that. I think they can be cluttered, though I put up with them because they do so much out of the box. But that doesn’t mean Vim isn’t an antiquated UI that should’ve went the way of the antiquated hardware it was designed for.

If you really want the ultimate example of a modern UI that is a clean and uncluttered, maybe you should look at something like Acme. It was Dennis Ritchie’s, and many other old-school Unix inventors’, text editor of choice once they had access to modern graphical workstations. If Acme is too much UI for you, then Sam, the predecessor to Acme which is also used by a lot of the original Unix guys, may be more your speed.

Heck, even editors like Visual Studio Code, Atom, and Sublime Text, offer very uncluttered UIs (unless you pile on a bunch of crap via add-ons) and modern user interfaces vastly superior to that of the 1970’s era Vim.


I’ve tried all three of those. They are all garbage.


Garbage in what way? In that they don’t offer a 1970’s era user interface?


The goal of every IDE is to make it so you can develop software using only one program. You never have to leave the IDE. The result is that they do everything, but they do everything worse than the individual tools.

I could go on and on about all the reasons I hate IDEs, but I’ll just stick to the number one reason.

I’ll never forget that time in Visual Studio I wrote a hello world and pressed the play button. I was met with a wall of errors. I copied and pasted that same code into a text file and ran gcc file.c and it obviously worked on the first try without error. The problem was some kind of crazy configuration settings in Visual Studio somewhere.

Using an IDE means you have to solve the problems of the IDE, and not just the problems of your code.

And it’s not just Visual Studio.

The same thing happened again when I tried to use Eclipse to write some Java.

And the same thing happened again when I tried PyCharm with some Django.

The same thing happened when I tried Android Studio (also Ecilpse-ish).

The same thing happened when I tried to use XCode on OSX.

Fuck all IDEs. Burn then with fire.

PS: They all make me touch the mouse, which is high treason for any text editor.


Atom, Visual Studio Code, and Sublime Text are not IDEs though. They are just text editors, just like Vim, only without the archaic UI. Granted, they have rich plugin ecosystems that can theoretically give them IDE-like functionality, but if you don’t install/use those plugins, they are just plain text editors. For that matter, if you really wanted to, you could also load up Vim with a ton of plugins to make it IDE-like as well.

For example, how do I write a simple, single-file C program in Visual Studio Code (this applies to any of the editors I mentioned too, just with different command lines)? Like this:

  1. In a terminal, “code foo.c”
  2. In the editor, type my program.
  3. In the terminal “gcc foo.c”
  4. In the terminal, “./a.out”

Just like in Vim.

As far as touching the mouse, do you play FPSes without touching the mouse?

Touching the mouse can often be more efficient than dealing with an arcane string of keyboard commands, especially if used smartly. When I use the mouse in any of my editors, I use it kind of like how I’d use it in an FPS – mouse in one hand, keyboard on the other, and boom, I go about my business.

Example: I’m on a line near the top of the screen in my editor, and need to make a change to something in the center of the line in the center of the screen. For the sake of illustration, let’s say the cursor is currently on line 23 and the change is in the middle of line 70 and I want to insert the letter “s” after the second instance of the letter “d” on the line.

Vim Newbie: [Esc]jjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjlllllllllllllllllllllllllllllllllllllllllllllllllllllis[Esc]

Experienced Vim (assuming you have line numbers turned on): [Esc]70gfdfdas[Esc]

Mouse: Right-hand: move, click, Left hand: s

It only took me a single keystroke to do the mouse-based edit and I didn’t need to spend any time figuring out just what arcane key combination I’d need to do in order to do things the “experienced” way, which would’ve been made more difficult if I didn’t have line numbers turned on (and yes, I know you can do searches and whatnot – there are a bunch of different ways to do things in Vim and any other advanced editor, but I deliberately chose leaving out search/replace commands as I was limiting this to just navigation commands. Ctrl-F isn’t any harder to type than Esc / ).

Whatever time I may save by not grabbing the mouse in Vim (which, admittedly, Gvim allows you to use the mouse) may be lost by the additional cognitive load of figuring the the correct command sequence to just do things via keyboard.

Plus, the vast majority of the time I spend in a “mousey” text editor, I don’t even need to use the mouse anyway, especially once I learn the keyboard shortcuts for the functions I use most frequently. The mouse comes in handy for doing lots of scattered edits across a screen or when I need to use a rare function (though again, Gvim mitigates this by letting you use the mouse too). For the rare function case, using the mouse to hit a menu is quicker than trying to dig through help or Google or whatnot to look up just what the arcane command is that I need.


I don’t know about anyone else, but I can’t type with one hand. What if you were inputting the letter k instead of s? Your right hand is busy with that mouse over there it seems. The time spent moving hand from keyboard to mouse, all typing ceases. I type REALLY fast, so that’s a lot of typing that doesn’t happen. One mouse click could cost up to 20 keystrokes.

Also, here is how I would do your vim example Scott-style. Search and replace! Already in command mode I press / and type something that gets me onto that d you want to change. Perhaps it’s in the word “delete”. I type /del and that probably gets me there. Worst case there are some other instances of del hanging around and I press n or N a few times to get to the one I want. Once I’m in the right spot, I just type a then s then of course esc again. In my case I actually have ctrl+[ in muscle memory instead of esc. That way my pinky doesn’t have to reach, and it’s compatible with weird keyboard layouts that have done bad things to the Esc key…

That’s real world vim usage, not clever vim golf usage. No cognitive load of trying to figure out something weird. No mouse. No line numbers or other weird shit. I’m sure someone out there uses vim like that, but I don’t. I should really use some sort of keylogger of some kind to analyze my vim usage patterns.


Well, sure, if I had to do a lot of typing other than a single character or two, I’d go two-handed with the typing. For typing ‘k’ instead of ‘s’, I can easily just move my left hand over and type ‘k’ (and often do). And I’m speaking as someone who types well over 100 WPM myself (I haven’t timed myself in a while, so I don’t know what the exact number is).

One mouse click costing 20 keystrokes? Let’s assume that it takes one second to move your hand to the mouse, move the pointer to where you want, click, and return your hand to the keyboard. Also, the average length of an English word is 5.1 letters. So that means that you can type about 4 words per second or 240 WPM The world record for typing in English is 212 WPM. You may be a pretty fast typist, but you’re not a world-record typist.

If I was a bit more generous and gave 2 seconds for the mouse action, okay, you’re down to about 120 WPM, which is probably in the ballpark of what a regular “fast” typist does.

And again, it comes down to using the mouse “smartly.” I don’t use the mouse for short, local “jumps.” I use it for when I need to do a lot of scattershot jumping around the code on the current screen. I also will use Ctrl-C/Ctrl-V like crazy to copy and paste multi-character changes if I’m doing multiple identical scattershot edits with the mouse.

Finally, yes, even if using the mouse can eat up 20 keystrokes of time, would you actually be typing all those 20 keystrokes during that time? Would part of that time be spent thinking about the change you’d be making? And how many of those keystrokes are actually useful content (prose or code) as opposed to cursor navigation or equivalent (e.g. search-and-replace) keystrokes?

If we’re going to play it that way using the editor I currently have open at the moment, I can just do Ctrl-F, del, Return (as many times as necessary to get to that point), Esc (to close the search tool), s. Your way took a minimum of 7 keystrokes. Mine also took 7, so it’s a tie there.

I’ll give you credit that you aren’t using any sort of Vim golf reasons to claim why you are more productive with purely Vim keystrokes than using a mouse. Most of the claims I’ve seen about Vim’s productivity has been from Vim golf examples, which you agree are often very contrived.

It would be interesting to see how the search-and-replace vs navigate-and-edit techniques of making scattershot changes scales to when you have a bunch of random, unrelated, quick scattershot changes to make. I think the mouse would win if you have to make a ton of those small changes to make, but I don’t have the appropriate statistics to back me up.

For a real test on what a powerful, truly mouse-centric UI can be like, give Acme a whirl, or at least read up on it (link to a page/video demoing its capabilities). Almost everything is done with the mouse (sometimes to a fault, even in my opinion), but it uses it in such a powerful and elegant way, thanks to some help by chording the mouse buttons, that it’s actually quite fascinating. Want to execute arbitrary text in your buffer? Select it with the middle button and release it (or, alternately, select it with the left button, the middle click). Cut/Copy/Paste? Select and then use chords of left and right or left and middle to copy, then left and right chord to paste. Search? Select the text you want to search for with the right button. It all sounds weird, but check out the video to see some of the crazy stuff you can do with it.

Of course, they did include a few keyboard shortcuts for the most common local editing/navigation operations. I do wish they had one for moving the cursor up and down a single line, though.

It certainly was powerful and efficient enough for Dennis Ritchie and a bunch of other old school true Unix Santas (as in the guys who actually invented Unix) and their apprentices/associates to choose it as their preferred editor once they had the proper hardware for it. I tried it for kicks once and it wasn’t quite for me (had some quirks, including the lack of keyboard shortcuts for moving up and down, that I couldn’t get around), but I can see why people love it once they learn it.

Edit: fixed typos


Don’t use a browser made by an advertising company: forcing users to log in to the browser.

Come on over to Firefox! The water’s fine!


I was on the verge of switching over to Chrome just for funsies but yeah, nah.


Sure jan


Eh, this is a nearly year old article and it’s been corrected.

I guess there’s always getting a Chromium build:


Another bad decision.

AMP, auto-sign-in, undeleting cookies. Is the big G not exploiting its position in a monopolistic fashion?




So in other words, Google found a (admittedly pretty bad) security hole that wasn’t being exploited in the wild, patched it, and then decided to shut down the product that was affected by it since it had a minuscule user base to begin with and wasn’t worth continuing to support.


The only people who seem to still use it are the indie RPG community and a few enterprises that have made terrible, terrible decisions.

The latter will continue to be supported.