Unwrapping Paragraphs in Emacs

After my last post detailing an unfill-region-or-buffer command for Emacs, a reader asked about creating an analogous unfill-paragraph command. The same tactic should work in this case that worked before: temporarily change fill-column to a large number and call fill-paragraph.

The fill-paragraph command takes two optional parameters, justify and region. In my first attempt at coding it I tried to pass them straight through in raw form. (The asterisk in the interactive string will cause Emacs to signal an error immediately if the file is read-only.)

(defun unfill-paragraph (&optional justify region)
  "Unfill paragraph at or after point."
  (interactive "*P")
  (let ((fill-column most-positive-fixnum))
    (fill-paragraph justify region)))

This worked when there was no active region, but when the region was active it unfilled the following paragraph instead of the selected one. I took another look at those two parameters. The first one, justify, is used to specify left, right, center, or full justification when filling a paragraph. I decided in the unfilling situation it made little sense, and so I could simply pass nil in its place. The second parameter is an indicator of whether or not there is an active region. I decided I didn’t need to receive that as a parameter, I could just pass the return value of the region-active-p function. Thus unfill-paragraph didn’t need to receive any parameters at all; I could just generate what was needed for fill-paragraph.

(defun unfill-paragraph ()
  "Unfill paragraph at or after point."
  (interactive "*")
  (let ((fill-column most-positive-fixnum))
    (fill-paragraph nil (region-active-p))))

This worked perfectly. With no active region it unfills the current paragraph. When the region is active it fills by paragraph within the region.

The biggest roadblock I ran into was when I first started to test my first version. It didn’t work at all, but threw no error. In due course I tried fill-paragraph, and it didn’t work either. In a few minutes I realized I was in my *scratch* buffer in lisp interaction mode and the text I was using was not commented. When I moved my testing to a temporary file in text mode, I got much better results.

Writing a Function to Unwrap Text in Emacs

Recently I had need of a way to unwrap hard-wrapped text in Emacs. This has actually happened several times so I decided I should find some easily repeatable solution. Two strategies came to mind. First, I could use find and replace to remove line breaks in a region. If I recorded a keyboard macro as I went along, it would be repeatable. For a small amount of text, it would be easy to eyeball it for any nuances I might have missed. For larger amounts of text from external sources that might be less than ideal. My alternative strategy was to use the fact that unwrapping text is the same thing as wrapping text to a very large line length. In order to facilitate possible maintenance, I chose to write it in a function.

In Emacs, wrapping is called filling, and the function to fill a region is called fill-region. Text is filled to a line length specified in variable fill-column. The other piece of information I needed was the largest number I could use to specify a line length. I had trouble finding this in the info documentation, but an internet search turned up the variable most-positive-fixnum as the store of this value. This was easily verified as being correct for my version of Emacs by looking at the help for most-positive-fixnum.

The idea for this function was to set the fill-column to a large number, fill the region, and then restore the old fill-column. I used a let to make the fill-column change temporary. The function should unfill the active region, but as a convenience, it should unfill the entire buffer when a region is not specified. In the past, I have tested for an active region using (and mark-active transient-mark-mode), but newer versions of Emacs provide a function use-region-p for this purpose. If an empty region should be treated as no region, the function region-active-p is a better choice because it doesn’t check the value of the variable use-empty-active-region, so I used region-active-p.

Here is the final function definition.

(defun unfill-region-or-buffer ()
  "Unwrap hard-wrapped text in buffer or region."
  (interactive)
  (let ((fill-column most-positive-fixnum))
    (if (region-active-p)
        (fill-region (region-beginning) (region-end))
      (fill-region (point-min) (point-max)))))

The code is not very long and is easily tested. Once it was working, I dropped it into an init file along with a key assignment.

(global-set-key [(control c)(f)] 'fill-region)
(global-set-key [(control c)(F)] 'unfill-region-or-buffer)

One of the things I love about Emacs is the documentation that comes with it. The Emacs manual, Emacs Lisp Reference, and Introduction to Emacs Lisp (which now all come with Emacs) were all I needed to learn the skills to solve my own text editing problems. This particular function may be of little use to many people, but it is a nice short example of how I go about writing functions to solve these little niggly issues. I recommend it as both fun and satisfying.

Self-help Books and Howtos

Behold the curious creature that is the self-help book. Someone has a problem, figures out how to solve it, and then writes down what they did. But instead of recounting the method that led to their own success, they write about the final conclusion as if it had just come to them. Then they couch it as a set of instructions for someone else. This they market.

The self-help aisle in the bookstore teems with those who hunger for a magic bullet. Whatever their perceived problem is, they pore through the offerings, select the closest fit that they can afford, and stroll to the checkout area. confident that the methods prescribed within the pages of their choice will solve their problem for good. ‘Tis a fools errand.

The efficacy of the self-help book depends upon an unlikely sequence of facts and events.

• The author understood his problem perfectly.
• The author is certain that his problem is solved.
• The author knows that the steps he took effected the solution.
• The author knows which of the steps he took effected the solution.
• The author did not omit any pertinent steps in his recounting.
• The author did not add anything counterproductive while fleshing it out to make it book length and please the editor.
• The editor did not remove anything essential.
• The reader has the exact same problem as the author.

That last one bears repeating: the reader has the exact same problem as the author. As unlikely as it is that all of the others are true, this is the most unlikely of all. Since the author has left the analysis out and included only the configuration, the reader will have to do that part for himself. Once he has done so, he is unlikely to need the book at all. For those who cannot or will not, the author has helpfully gone into the workshop business, and for a fee, will provide the analysis he left out of the book. Then, if he knows how to solve the reader’s problem, he will do so in the workshop. He may even write a sequel recounting what he learned from his workshop customers.

Though related, the howto is not the same beast. Howtos are often filled with analysis. Things like “if this is your situation, do foo; if not, do bar instead,” and “I tried blee, but it didn’t work because I hadn’t considered blah.” This is a useful document because the reader can tell right away whether the problem matches his own. Furthermore, if his situation is different, he is still guided in the analysis. The howto is the beautiful thing the self-help book should have been.* Aptly named, it really does explain how to do something. Because the self-help book only really helps its author, it too is aptly named.

The howto author often has a distinct advantage in producing a useful work. The howto mostly addresses technical topics (e.g. configuring a network) or physical processes (e.g. repairing a bicycle or baking a cake) that have defined and discrete steps. It is often clear which steps led to a solution and whether that solution was truly obtained. The howto author likely understands both the problem and its solution. Those who don’t, often know that they don’t and say specifically where their knowledge fails them as an aid to the reader.

Self-help books generally cover more amorphous topics. Therein lies the problem. It simply is not possible to give step by step instructions that lead from some unknown state to some poorly defined goal. Almost anything can be claimed as at least partial success, but true success is likely elusive.

In the coming weeks, I shall begin recounting some problems I have solved and how I did so. But these were my problems, not yours. You may freely adapt my solutions to address your own issues, but I offer no guarantees, and I won’t be doing a workshop.

*Yes I have over-generalized to make a point. Some howtos are not useful. Some self-help books can be (although I’m still wary of anything with a follow-on workshop). And it should go without saying that I only know what goes on in the self-help aisle of the bookshop because I’ve been there.

Changing Environs: Graphical Desktop Environments & Home Decor

I am baffled by the popularity of coffee tables. They don’t work well. People bump into them, sometimes painfully, spilling any drinks thereon. When sitting, side tables are much more convenient. Coffee tables require leaning to use, and people eschew that. The person who sits in the center of the couch is trapped by and dependent on the coffee table. As people fill a living room, that position stays unused the longest. Coffee tables take up space that could be put to better use. If the coffee table is close enough to reach, it prevents the person seated in front of it from stretching out his legs. Except for catching clutter, coffee tables serve no purpose that is not better served by smaller easily moved tables.

I don’t always use rooms as intended by the builder, and I don’t always arrange the furniture in traditional ways. Letting someone else decide (or some formula dictate) my room arrangement does not work for me because it isn’t optimized for my comfort and use. Ever since I was a kid I have preferred to do my own space plan for rooms I use. If I don’t want a coffee table, I don’t have to use one. I can choose better forms to provide that function.

Using a desktop environment is a lot like letting someone else design your room. Pick your poison: be it Gnome, KDE, Mac OS X, MS Windows, or whatever du jour. They all make some assumptions about how your space should look and how it should work. To some extent they all make it difficult to change it to work in unintended ways.

Recently I read about Linus Torvalds switching from Gnome3 to Xfce, due to functional differences from Gnome2 that caused him issues. To wit:

Why can’t I have shortcuts on my desktop? Why can’t I have the expose functionality? Wobbly windows? Why does anybody sane think that it’s a good idea to have that “go to the crazy ‘activities’” menu mode?

Here’s an example of “the crazy”: you want a new terminal window. So you go to “activities” and press the “terminal” thing that you’ve made part of your normal desktop thing (but why can’t I just have it on the desktop, instead of in that insane “activities” mode?). What happens? Nothing. It brings your existing terminal to the forefront.

That’s just crazy crap. Now I need to use Shift-Control-N in an old terminal to bring up a new one. Yeah, that’s a real user experience improvement. Sure.

You can’t blame him. His desktop environment is his personal space, and someone rearranged all the furniture. Worse, they replaced his stack of small easily-moved tables with a single coffee table. He found that suboptimal and moved on.

I have done it myself. I used Macs from their beginning. When Apple switched to Mac OS X, I discovered my muscle memory, troubleshooting strategies, workarounds, and collection of add-ons were of little use. I would eventually be forced to learn a new paradigm. Rather than restrict myself to Mac OS X, I took the opportunity to consider others and settled on Linux as the best compromise between a bright future and a hedge against having my paradigms changed again.

Using Mac OS 9 and its predecessors had been like living in a furnished apartment. Since I liked the furniture, it was fine. I acquired accessories that worked with it, and I was happy. The move to Mac OS X meant that the landlord had decided to remodel. The new design looked nice, but I found it less functional. All my accessories had been resting on surfaces that were now removed. I found them piled in a box out back to be discarded. I decided to move into my own place. I have had to decorate it from scratch, but it’s just how I like it.

Linus,* similarly, was living with a furniture package he liked. The landlord remodeled and changed the package. The neighbors say that there is way to rearrange the furniture so that it is just like the old package, but this wasn’t his experience. He decided he preferred a different package and switched.

Choosing a different package is one way to configure a look and feel for your desktop. Packages allow varying levels of configuration within that choice. If the configuration options are insufficient you could write your own. We each decide how much we are willing to bother to get it right. Some people build their own furniture; some hit the flea market. Some people modify their furniture to fit their needs; some use everything as is. Some people just buy a set and have it delivered. As for me, I’ll skip the set; it has a coffee table.

*I do not know Linus Torvalds personally. I’m just being presumptuous.

The Journey Begins

“Analyze and configure” is as close as I get to having a mantra. Examine life; figure out what makes it worth living; make it so. Iterate as needed. This is my simplified description of problem solving technique: down to two steps. There can be no step skipping. Configuration without analysis is fraught with error, and analysis without configuration leads to no result at all. Results may vary, of course, depending on the care taken in both steps: both good and bad decisions can be made this way.

The process is familiar. This is what the Buddha did, setting down his results in the Four Noble Truths. The prodigal son did it twice, both when he left and when he returned. RMS did it when he needed to fix a printer, and as a result the GNU project was formed. We all do it all the time. If you notice that you have a hangnail and decide to trim it, you have used this approach.

I may use it more consciously than most people because I am fascinated by the process itself. This simple formula applies across many domains. Whether I am decorating my home, planning meals, dealing with heartbreak, or trying to customize my computing experience, I find myself breaking it down to these two steps: determine what needs to be done and do it.

In these virtual pages, I intend to discuss how I use this approach in a variety of situations. Much of this will be about configuring software (particularly emacs) because I do a lot of that. But no life is centered entirely around software. We have living spaces, workflows, relationships, and always new interests. I’ll cover those too because the approach is the same, and this is really about the approach.

This blog is an experiment for me. It is my first. I am testing a theory that my analysis will gel better and my motivation will be increased thereby. We shall see.