My ideal editor

Notepad Art
Photo credit: Stephen Dann

Some of you probably read me ranting on G+ and Twitter about blog post editors. I have been complaining about that since at least last year when Typo decided to start eating my drafts. After that almost meltdown I decided to look for alternatives on writing blog posts, first with Evernote – until they decided to reset everybody’s password and required you to type some content from one of your notes to be able to get the new one – and then with Google Docs.

I have indeed kept using Google Docs until recently, when it started having some issues with dead keys. Because I have been using US International layout for years, and I’m too used to it when I write English too. If I am to use a non-deadkeys keyboard, I end up adding spaces where they shouldn’t be. So even if it solves it by just switching the layout, I wouldn’t want to write a long text with it that way.

Then I decided to give another try to Evernote, especially as the Samsung Galaxy Note 10.1 I bought last year came with a yet-to-activate 12 months subscription to the Pro version. Not that I find anything extremely useful in it, but…

It all worked well for a while until they decided to throw me into the new Beta editor, which follows all the newest trends in blog editors. Yes because there are trends in editors now! Away goes the full-width editing, instead you have a limited-width editing space in a mostly-white canvas with disappearing interface, like node.js’s Ghost and Medium and now Publify (the new name of what used to be Typo).

And here’s my problem: while I understand that they try to make things that look neat and that supposedly are there to help you “focus on writing” they miss the point quite a bit with me. Indeed, rather than having a fancy editor, I think Typo needs a better drafting mechanism that does not puke on itself when you start playing with dates and other similar details.

And Evernote’s new editor is not much better; indeed last week, while I was in Paris, I decided to take half an afternoon to write about libtool – mostly because J-B has been facing some issues and I wanted to document the root causes I encountered – and after two hours of heavy writing, I got to Evernote, and the note is gone. Indeed it asked me to log back in. And I logged in that same morning.

When I complained about that on Twitter, the amount of snark and backward thinking I got surprised me. I was expecting some trolling, but I had people seriously suggesting me that you should not edit things online. What? In 2014? You’ve got to be kidding me.

But just to make that clear, yes I have used offline editing for a while back, as Typo’s editor has been overly sensible to changes too many times. But it does not scale. I’m not always on the same device, not only I have three computers in my own apartment, but I have two more at work, and then I have tablets. It is not uncommon for me to start writing on a post on one laptop, then switch to the other – for instance because I need access to the smartcard reader to read some data – or to start writing a blog post while at a conference with my work laptop, and then finish it in my room on the personal one, and so on so forth.

Yes I could use Dropbox for out-of-band synchronization, but its handling of conflicts is not great, if you end up having one of the devices offline by mistake — better than the effets of it on password syncs but not so much better. Indeed I have bad experiences with that, because it makes it too easy to start working on something completely offline, and then forget to resync it before editing it from a different service.

Other suggestions included (again) the use of statically generated blogs. I have said before that I don’t care for them and I don’t want to hear them as suggestions. First they suffer from the same problems stated above with working offline, and secondly they don’t really support comments as first class citizens: they require services such as Disqus, Google+ or Facebook to store the comments, including it in the page as an external iframe. I not only don’t like the idea of farming out the comments to a different service in general, but I would be losing too many features: search within the blog, fine-grained control over commenting (all my blog posts are open to comment, but it’s filtered down with my ModSecurity rules), and I’m not even sure they would allow me to import the current set of comments.

I wonder why, instead of playing with all the CSS and JavaScript to make the interface disappear, the editors’ developers don’t invest time to make the drafts bulletproof. Client-side offline storage should allow for preserving data even in case of being logged out or losing network connection. I know it’s not easy (or I would be writing it myself) but it shouldn’t be impossible, either. Right now it seems the bling is what everybody wants to work on, rather than functionality — it probably is easier to put in your portfolio, and that could be a good explanation as any.

More explanations: why nano is Gentoo’s “default editor”

I say “default editor” in quotes because Gentoo really does not have a default editor, but rather a fallback-editor for whenever the users hadn’t chosen one themselves. And this is why stuff like the stage3, sudo, openrc and so on default to that when $EDITOR is unreliable (that is, until we can move to a full-fledged wrapper script).

Paul, in the previous post explained it quite well, albeit briefly, but since some other people asked me about that again, I’ll quote him and then go in a bit more of details:

… Third nano was kept as the default because it is small, straightforward, and easy to get out of when you don’t know it (let’s face it neither vi(m) nor (x)emacs is that easy to get out of). Fourth, by having the EDITOR/VISUAL variables point to nano (which is installed by stage2 as well as stage3) things would be working (although probably not optimal) out of the box. …

Indeed Paul speaks well: neither vi (or vim) nor emacs (or xemacs) is going to work. Why is that? Some people even goes as far to say that “it’s called *vi*sudo“ and “vi is the default Unix editor”. At the same time, I wouldn’t be surprised to hear “Emacs is the default GNU editor”. Well, let’s decompose it in two different problems.

Technical problem: the system set is messy already (and this is also “thanks” to my own pambase creation — which is, though, a solution to a previous problem). The packages that do enter the system set should be, whenever possible, small and with little dependencies. This includes, obviously, USE-optional dependencies, since when they are enabled, the dependencies also become part of the system set (like it happens with gnome and pambase). The dependency tree of nano is near invisible, while those of both vim and emacs are quite long (sure there are things like elvis, nvi, zile and jove, but this will bring us to the next point…).

Reality problem (or flame-retardant method): there is no way on Earth that any average number of people will be accepting to use the same editor as default, when taken from the list of “most popular” editors. Hey we cannot even find consensus among the three developers of lscube (I’m using Emacs – yeah I’m an Emacs user, burn me – and my colleagues using VIM and Eclipse). If we were to choose vim, all Emacsen users will complain, if we were to use GNU Emacs, both vim and XEmacs users will complain, and so on so forth. So we use nano, which is likely to make unhappy the most people, but all in the equal amount.

There’s a corollary to the reality problem above: if we were to choose any of the lightweight variants that I named above, or more of them, most likely the problem would be more or less the same, since almost all people would be pretty unhappy with the choice and would then unmerge that and install their editor of choice. But it would most likely upset the two “main factions” unequally, which would make one feel discriminated against.

Newbie problem: finally, there is another note: both Emacs and VI (and respective clones) aren’t exactly the most user-friendly editors. A newbie user who has no clue how to work in Gentoo is unlikely to guess at first sight how to use either of them, while nano is pretty much the easiest thing you might find around. You can fight as much as you want about powerfulness (Emacs and VI are obviously much more powerful than nano) and you can fight about relative easiness of use (:w versus C-x C-w) but nano is going to win over both of them in that regard.

So no, we’re not going to change the default anytime soon.