Making Emacs Act More Like a Text Editor

Emacs used to be a great programmer's editor. It still is, but non-text features keep creeping in making it less usable for editing and viewing text. For example, doc-view mode makes emacs render a PDF, DVI, or PS file. But PDF and PS are text formats, so I can't imagine why I'd want emacs to render them--other tools do that well.
To make emacs better-behaved, it seems the following in one's .emacs file is sufficient:

(add-to-list 'auto-mode-alist '("\\.pdf\\'" . fundamental-mode))
(add-to-list 'auto-mode-alist '("\\.ps\\'" . fundamental-mode))

Thanks to Stefan Monnier at https://groups.google.com/forum/?fromgroups=#!topic/gnu.emacs.help/TGVh05FGzK8
My .emacs file (really, my emacs-custom.el which is loaded from my .emacs) has been growing since Fall 1988, and I don't see that changing, especially as new puppies start monkeying with emacs' behavior. Of course, I do trim detritus from time-to-time.
Actually there might be some stuff in there from my time at William and Mary, 1984-1986. Zippy says "yow."

Emacs Documentation Oddity: Basic Display

At http://www.gnu.org/software/emacs/manual/html_node/emacs/Misc-X.html, the description for command-line option --basic-display says:


‘--basic-display’
Disable the menu-bar, the tool-bar, the scroll-bars, and tool tips, and turn off the blinking cursor. This can be useful for making a test case that simplifies debugging of display problems.

That may all be true, but once one learns how to use emacs, the menu bar, the tool bar, the scroll bar, and tool tips only waste screen real estate and are completely, 100% superfluous.

Emacs 23: But Text is Text, Right?

I've lately been annoyed that emacs no longer seems to understand the structure of a text file. When editing a long line that wraps, the down arrow and ^n will often take one to a later portion on the same line rather than the current column in the next line. The idea is to consider lines as seen on the screen as more fundamental than lines in the file, even though in almost every application it's the file contents that matter.

It didn't take long to find the workaround--thanks to Nilesh Kapadia who commented at http://emacs-fu.blogspot.com/2009/07/emacs-23-is-very-near.html.

Insert the following into the .emacs startup file:


(setq line-move-visual nil)

<flame>
This seems to be yet another case of someone wanting emacs to act less like a text editor and more like a word processor. People that want emacs to act like a word processor should use a word processor, and not lobby to cripple emacs' ability to treat text like text.
<emalf>

Learned Something Tonight

I had just downloaded a statement from my bank, and it had the useless extension .asp on it, which I changed to .pdf since the bank said it was a PDF. Wanting a quicker way to verify that it was indeed a PDF than loading it into a document viewer, I pointed emacs at it. Instead of displaying a screen that starts with something like

%PDF-1,4

which is what the file indeed did start with, it complained that it couldn't render the file and asked if I wanted to view text extracted from it. The extracted text didn't include the first line, so I was at square zero. It only took a moment to get around this new emacs "feature," now a default in emacs23 which is the Mint 12/Ubuntu 11.10 default emacs version, but, in the interest of saving time in the future, I decided to disable the feature, docview-mode.

But that's not what this entry is about. While searching for a solution, Duck Duck Go led me to The Universe of Discourse, which is apparently not where I live, and the following description of my life:
Yesterday I upgraded Emacs, and since it was an upgrade, something that had been working for me for fifteen years stopped working, because that's what "upgrade" means.

I've been in this field for over 3 decades, and even though I am fully aware that backward compatibility is often not a consideration, I have not yet internalized the fact that upgrades necessarily lead to broken systems. However, this is consistent with my recent experiences, especially with Ubuntu and Gnome.

Useful "New" Firefox Feature

I am not a fan of GUI-based spellcheckers since it is so easy to miss a misspelling. I much prefer ispell within emacs. In particular, ispell does a great job (compared to any GUI I've seen) of suggesting alternatives, emacs and ispell together do a great job of accepting words for a session across multiple documents, and emacs understands various file formats and doesn't try to tell me that, for example, an HTML tag is not a valid English word. Well, it has long been a common opinion that GUIs are great for beginners but don't particularly reward more experienced users with better productivity. I particularly dislike spell checking within OpenOffice, since when adding to the dictionary one has to always specify which dictionary to save a word to, even if there is only one dictionary. Make the common case fast? I don't think that's a concept OpenOffice developers are familiar with.

So how can one make it less likely to miss misspellings before sending an e-mail, submitting a form, etc? Firefox 3.6 and newer has a nice feature that's a pain to enable, ui.SpellCheckerUnderlineStyle. See http://kb.mozillazine.org/Ui.SpellCheckerUnderlineStyle. I particularly like option 4, which places a double line under each misspelled word. But the article just cited does not give explicit instructions for enabling the feature.

1) Open about:config
2) Right click in the list of preferences and select new.
3) For the new preference name, use ui.SpellCheckerUnderlineStyle.
4) For the type, use integer.
5) For the value, use your preferred value from the MozillaZine article. 5 is the default, a wavy red line. My preference is 4, a double line.

OpenOffice Inserting Page Breaks

I've been using OpenOffice more than usual lately (and still greatly prefer emacs/LaTeX for speed and accuracy). One annoyance has been inserting page breaks: Insert|Manual Break|Page Break. Very clumsy and slow. There's no hint regarding an equivalent shortcut adjacent to the menu item, so I tried ^L--it is the standard ASCII page break character--but no joy. Googling led to http://www.oooforum.org/forum/viewtopic.phtml?t=35045, where Bhikkhu Pesala suggests ^enter (or control enter for newbs). Thanks Bhikku.

Human-Readable Dired in Emacs

In emacs, dired defaults to

ls -al

format, but I would prefer

ls -alh

For example, I'd rather see this:

total 200M
drwx------ 2 jdm jdm 20K Mar 24 22:00 .
drwxr-xr-x 9 jdm jdm 52K Mar 21 03:04 ..
-rw------- 1 jdm jdm 520K Mar 24 21:03 252.jpg
-rw------- 1 jdm jdm 1.4M Mar 24 21:04 253.jpg
-rw------- 1 jdm jdm 1.3M Mar 24 21:04 254.jpg
-rw------- 1 jdm jdm 1.3M Mar 24 21:05 255.jpg
-rw------- 1 jdm jdm 1.3M Mar 24 21:05 256.jpg
-rw------- 1 jdm jdm 1.1M Mar 24 21:05 257.jpg
-rw------- 1 jdm jdm 1.1M Mar 24 21:06 258.jpg

as opposed to this:

total 204060
drwx------ 2 jdm jdm 20480 Mar 24 22:00 .
drwxr-xr-x 9 jdm jdm 53248 Mar 21 03:04 ..
-rw------- 1 jdm jdm 532078 Mar 24 21:03 252.jpg
-rw------- 1 jdm jdm 1369711 Mar 24 21:04 253.jpg
-rw------- 1 jdm jdm 1285739 Mar 24 21:04 254.jpg
-rw------- 1 jdm jdm 1320355 Mar 24 21:05 255.jpg
-rw------- 1 jdm jdm 1328517 Mar 24 21:05 256.jpg
-rw------- 1 jdm jdm 1101028 Mar 24 21:05 257.jpg
-rw------- 1 jdm jdm 1077152 Mar 24 21:06 258.jpg

The fix was this line of Lisp added to the end of my .emacs file:

(setq dired-listing-switches "-alh")

Emacs Spontaneously Shifting to DOS Mode. Yuck.

For some reason emacs (GNU Emacs 22.2.1 (i486-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of 2010-03-26 on rothera, modified by Ubuntu) on Ubuntu 9.10 has been spontaneously deciding to use MS-DOS/Windows line endings rather than Unix. This is rather wasteful of space, and sometimes causes issues with other tools. It's also inconvenient, since I was killing the emacs buffer, running dos2unix on the file, and then loading the fixed file back into emacs. Looking for a fix, I stumbled across three blog entries of note:

1) http://www.debianadmin.com/flip-convert-text-file-line-endings-between-unix-and-dos-formats.html recommends a tool called flip. This makes no sense to me whatsoever since it does exactly what dos2unix and unix2dos do. It looks to me like someone's CS1 assignment that somehow got added to the Debian repositories.

2) http://www.sowbug.org/mt/2004/07/emacs-dos-line-endings.html has a good short-term fix, a bit more convenient than what I was doing. Within emacs, type the following key sequence: C-x [ENTER] f unix [ENTER]. This sets the "Coding system for saving file." Good enough.
Also, Sowbug.org has a great tagline: "If all you have is a Bloom filter, everything looks like a set whose membership you wish to test with a possibility of false positives."

3) Barriehie at http://ubuntuforums.org/showthread.php?t=1375454 has the winner, a good, permanent, catch-all type solution. Essentially, modify .emacs to include:

;; Set ALL files to UNIX line endings
(add-hook 'find-file-hook 'find-file-check-line-endings)
(defun dos-file-endings-p ()
(string-match "dos" (symbol-name buffer-file-coding-system)))
(defun find-file-check-line-endings ()
(when (dos-file-endings-p)
(set-buffer-file-coding-system 'iso-latin-1-unix t)
(set-buffer-modified-p nil)))

I've tested it just a bit, and it works beautifully.

Also, my .emacs is all in one file, and I prefer the way he splits it across multiple files. I'm using the .emacs that grad students were given at Ohio State ca. 1992 with many, many modifications. Following Barriehie's lead, I've split my .emacs it into multiple files, thus allowing me to keep my modifications separate from the stuff passed down from Brutus Buckeye.

Thew and Fro

Spell checkers allow users to add words to their dictionaries. It would be nice if they would also allow users to subtract words. Two frequent typos of mine are 'thew' for 'the' and 'fro' for 'for'. Unfortunately, both typos are English words, though neither is a word I use at all often. Almost always when either occurs in my writing it's a typo. So why can't I tell ispell or Open Office or Firefox or Thunderbird that these are words that should be flagged as misspellings? Actually, I could write a postprocessor for LaTeX documents that flags likely typos, but it would be harder to do this for a clumsier tool, like the WYSIWYG tools. Also this points out a problem with non-text-based tools for text-based applications. A postprocessor would work fine for text files, which means it would be more widely applicable than to just LaTeX, but every GUI has its own spell checker, with its own dictionary, and so they don't integrate well with each other, with simple tools, etc. Going back to elm or mutt for e-mail would solve part of this problem, by raising my productivity for basic e-mail by allowing the editing of e-mail in emacs, but they make multimedia e-mail a bit more of a challenge. OTOH, perhaps they've improved attachment handling in the past few years--worth a look.

GNU Emacs: making the obvious difficult

Off and on it's really irritated me that someone on the GNU team decided to change the default behavior of tab in fundamental mode from insert ^i to indent-relative. I hate indent-relative. It makes lining things up in columns in text files difficult. So every few months I do a Google search, find other people making the same complaint, and see less than helpful suggestions. Tonight I got more frustrated than usual, and so spent more time than usual. It appears that the following shuts off indent-relative for the most part without messing up filename completion or indentation in various modes, e.g., java or html.

(setq default-major-mode 'text-mode)
(define-key text-mode-map "\t" "\C-q\C-i")

The above is pretty much alpha code at the moment. There's detritus in my .emacs that suggests that years ago I didn't like text mode for pnews or mail modes, but those are no longer issues. indent-relative is, IMHO, evidence of word processor-oriented thought processes, not text editor-oriented processes. As Linux grows to be more Windows like (e.g., bloated and buggy), there seems to be an undercurrent of making basic tools, e.g., emacs and wc, less Unix-like.

Renaming a Pack-o-Files

A friend asked me a question that got me thinking that emacs must provide an easy way to rename a bunch of files in a directory from one thing to another. E.g., suppose I want to rename every file ending in .doc to a .tex extension. Point emacs at the directory, and type %m This fires off dired-mark-files-regexp, which selects files matching a regular expression. For the regular expression, try .doc$ Hit enter after each command. The '$' indicates that the pattern must occur at the end of a line. Now you can rename the marked files: %r This invokes dired-do-rename-regexp, which, for every marked file, asks what pattern to replace: doc$ It then asks what to change matching substrings to: tex ¡Voila! Much of the above is condensed from http://xahlee.org/emacs/find_replace_inter.html

Emacs Incremental Search Highlighting

Sometime in the fairly recent past default emacs incremental search behavior was modified to underline every occurrence of the search string in the current view. This makes searching very difficult to use if one wants to just skip ahead, e.g., a few 'o' characters, because every 'o' is highlighted, with no way to know which one is at the cursor. To return to the original, more usable behavior add this to your .emacs file: (setq isearch-lazy-highlight nil) ⟨editorial⟩ Emacs more and more is acting less and less like a text editor, and trying to get cute about things. Default behavior keeps changing, and often for the worse. This incremental search highlighting is a good example. Another is that in text mode it's now hard to line things up consistently because tab is no longer tab. Instead tab inserts enough spaces or tabs to line the cursor up with the beginning of the previous line, or with the beginning of a word in the previous line. I'd rather tab be tab. ⟨lairotide⟩