In a typical Windows program, some output text can be copied as text but some is only an image. For example, the text in the body of a document is text, but the words on the menus are not. The text in a dialog box may or may not be.
In Emacs, text is just text, no matter where you see it. This means that Emacs is less visually interesting because there is less variety. But this also has several advantages that may not be immediately obvious. I’ll give a couple examples.
The Emacs directory editor
dired lists files in a text buffer. The output is essentially the output of
ls. (On Windows, Emacs emulates
ls.) That means you can do anything to the output you could do to text: copy, paste, search, etc. No text is off-limits. And in editable mode, you can rename files just by editing their names. You could, for example, rename many files at once using regular expressions.
Dired also lets you navigate the file system with the same commands you use to edit files. In particular, you can keep your hands on the keyboard. (It’s possible to use the Windows file explorer without a mouse, but it’s limited and awkward.)
Another advantage of everything simply being text is that you can run a shell inside Emacs. Why not? A shell is just text output. In an ordinary shell, editing commands are mostly limited to the current line. Not all text is created equal. But when you’re running a shell inside an editor, all text is equal: current line, previous lines, and text on either side of the command prompt. And if you want a transcript of a shell session, just save the buffer displaying the session.
If you’re shopping for a text editor and spend an hour trying each one out, Emacs may not look very promising. It has odd terminology, weird key strokes, etc. But if you try Emacs long enough, and particularly if you have someone to help you get started, you start to appreciate the advantages of subtle features such as everything simply being a text buffer.
10 thoughts on “Advantages of everything-is-text”
Acme by R. Pike would be another text-based editor/window system worth looking at. (It runs on Windows, too.)
I’m trying to get the drift of your philosophy on this… in some previous post, you talk about the advantages of piping objects in PowerShell over piping text. I assume that the answer to which is better is `it depends’. Do you, or would you, elaborate more on this?
Matt: That is a very good question, and one I haven’t resolved to my satisfaction.
Piping text isn’t just piping text. It’s also parsing the text to pull out what you need. Sometimes this is trivial. It’s always trivial in books and blog posts. But sometimes it’s a lot of error-prone work, and that’s when the PowerShell approach is easier.
A limitation of piping objects is that you can only access the objects that the author thought to expose. Maybe that’s OK, but you can use text in ways the author didn’t imagine.
So I guess a preliminary answer would be that PowerShell, like all Microsoft tools, works well when you use it as intended. Microsoft serves the profitable middle of the market well. But text is more flexible when you want to do something the software wasn’t intended to support.
GUIs divide output into graphical and textual elements because the designers have decided “This is the part users want to copy” and “Nobody will want to copy this.” And if all goes well, they’re usually right, maybe always right for their target market. Textual output doesn’t make this kind of decision, for better — more information is accessible — and for worse — the user is given less guidance.
You can see the power of emacs and “everything-is-text” for example if you use extensions like WDired. Emacs is awesome, but the learning curve is kinda evil.
Unfortunately the idea behind powershell objects is that it depends on your intent. The power in storing all your data in .NET presentation is pretty awesome, and there are even methods to let you create your own objects and customise existing objects. Custom objects allow you to define interfaces, a positive in my book, which text does not readily allow. While hand made custom objects may give you space savings (RAM) on some occasions, but objects produce bloat in others (most actually). Objects are sweet in cases where you want some level of type checking or are in a heavily structured mood.
The downfall of Windows powershell objects is they can only be acessed in the scripting engine and become text the moment you display or send/pipe them to a win32 application. So coming back to the pipeline question, I only believe that text is better once you get the hang of regex. At the end of the day, parsing text skillfully is like a carpenter’s chisel – not the prettiest tool, but vital.
By the way, did you know that when you get a Windows dialog, you can usually copy its text just by pressing Ctrl-C without selecting anything? I learned this only recently.
Ram: Thanks. I did not know the shortcut you mentioned. Will have to try that out.
Great article, that way i love emacs,
but i still hoping, a great folding code in emacs..
I used to be a Emacs user long ago and thought I had become contemporary by using newer age editors and IDEs like Eclipse and Netbeans.. This post has convinced me to get back to Emacs! :)
for most of the task you mention, there is a free from the web program that does just that, eg puts the directory of files (with ot without the folder tree structure) into a text file….
PS: no VI flame ?