Writing tools on Linux tend to suck, unless you start looking into the older and more established software.
Part of what annoyed me about KDE and GNOME was that the primary text editor for each has never been much good. Not that they lack useful features, but if you write anything more than a few paragraphs, the software starts bogging down. On a book-length text document, the text tends to display some three or four words behind your typing. Meanwhile, the CPU is being hammered hard by the software. Sure, turn off spell checking and it won’t be so bad, right? Look, you dumbass developer, spell checking was invented for a reason. If you can’t make it run without dragging down my system, then you aren’t much of a coder, are you?
Granted, the legacy tools are clunky in terms of things like keystrokes. Ever try Gvim? Emacs? They were around before DOS and Windows became the near-monopoly OS and everyone learned their standard keystrokes. In my mind, the developers of those two older tools don’t want mass adoption or they would at least make it an option to switch to Windows-like keystrokes. You’d have to learn the obscure scripting built into Gvim to change every stinking keystroke, and there are hundreds. Instead, they are catering to the current user base or purists who can’t imagine changing something for which they honestly have silly romantic feelings.
But in order to have something with both spell checking and a host of sensible formatting options, yet doesn’t choke the system with senseless CPU thrashing, I have to use the older stuff. Yeah, you can get a tame version of Gvim with the package called Cream, but it then takes away some of the advantages. Gvim allows you to have soft-wrapping, even on the console. Cream won’t do it by default; you have to set the mandatory margin way out to some crazy high number like 100,000. It works, but the underlying assumption that you simply must have hard carriage returns ignores a very real need for authors. Now, if your document is intended for plain text only, it really should have hard wrapping at around 72 characters; that’s about maximum length for how the average brain reads characters without losing place. I actually like plain text publication, but most readers aren’t interested in that format, and not a single publisher of any note will accept it.
At any rate, I sigh and take the time to learn the small handful of incomprehensible keystrokes I use in Gvim so I can write my book-length documents when they require soft-wrapping. I also struggle to keep track of the mode-shifting. As is obligatory in the world of Gvim users, you’ll find my .vimrc and .gvimrc below. I stole many ideas from others, and it includes the assumption I’ll switch between hard- and soft-wrapping modes for different kinds of documents.
There are some cryptic indented lines that allow me to use CTRL+J for reformatting paragraphs when I use hard-wrapping (provided you can make it work as you really like):
.vimrc set spell spelllang=en set spellfile=~/vimfiles/spellfile.add set nocompatible behave xterm set nojoinspaces set shiftwidth=3 set tabstop=3 set backspace=indent,eol,start set incsearch syntax on set showcmd set wrap linebreak textwidth=0 set whichwrap=<,>,h,l,[,] colorscheme koehler nmap <C-J> gqap vmap <C-J> gq imap <C-J> <C-O>gqap
If you run Gvim, it pulls in the .vimrc but I’ve had trouble in the past with Gvim ignoring the instructions to enable spellcheck by default, so I had to explicitly repeat them for my .gvimrc, along with the remapping of the keys:
.gvimrc set spell spelllang=en set autoindent set ruler nmap <C-J> gqap vmap <C-J> gq imap <C-J> <C-O>gqap set wrap linebreak textwidth=0 set lines=55 set columns=80 set guifont=Terminus\ 12
(On WordPress, using the <pre> tags allows for keeping indentations in plain text and puts it all into a quote box. But then you have to replace your left and right angle-brackets with HTML entities.)
