This series is written by a representative of the latter group, which is comprised mostly of what might be called "productivity users" (perhaps "tinkerly productivity users?"). Though my lack of training precludes me from writing code or improving anyone else's, I can, nonetheless, try and figure out creative ways of utilizing open source programs. And again, because of my lack of expertise, though I may be capable of deploying open source programs in creative ways, my modest technical acumen hinders me from utilizing those programs in what may be the most optimal ways. The open-source character, then, of this series, consists in my presentation to the community of open source users and programmers of my own crude and halting attempts at accomplishing computing tasks, in the hope that those who are more knowledgeable than me can offer advice, alternatives, and corrections. The desired end result is the discovery, through a communal process, of optimal and/or alternate ways of accomplishing the sorts of tasks that I and other open source productivity users need to perform.

Wednesday, January 18, 2012

Second installment: Outlining with nano

nano, the old stand-by, low-resource console editor, is probably most often used for quickly editing computer configuration files. It seems also sometimes to be used by programmers for writing programs or editing code. Some of us non-programmers can think of other uses it might serve, such as writing documents or creating outlines. This article will discuss some of the uses I've tried to make of it and some ideas I have for further deploying it.

My history with nano


I'm a long-time user of the nano text editor, it having been from the beginning for me a far more approachable tool for editing configuration and other text files in GNU/Linux than the other popular option, vi. My experiences with nano began in the days when GNU/Linux operating system installations were command-line affairs, and when most initial configuration of the system was done from the terminal. But even after operating system installations developed into a thing of graphical wonder (Knoppix was sort of a trailblazer in this realm, as I recall), I continued to use nano for many tasks owing, not in small part, to the fact that I'm a trailing-edge technologist (read; I re-purpose cast-off or firesale equipment), and so gravitate toward low-resource computing applications.

When I needed to create a very long and complex document a few years ago, I was even hoping at that point that I could learn enough TeX mark-up in order to be able to write most of it using nano. In the end, however, I found myself too intimidated by the prospect of both learning TeX mark-up and planning and executing the complex document, to make the attempt. I chose instead to use a WYSIWYG word processor for the task--but that's another story.

I've since maintained my interest in TeX and LaTeX, and, in the last year or so, actually managed some modest successes with it. Needless to say, I've been using nano right along, and have combined the two in those successful tests. But what got me started thinking about a possible new way of using nano in combination with TeX/LaTeX was actually a tweaked version of vim--vimoutliner with which I was experimenting. And my initial experiments were not TeX/LaTeX related, but were actually focused on finding a text-mode outliner.

vimoutliner


Ok, I know that's a rather convoluted introduction to this story but, hey, life is like that. I all the time stumble onto new and unexpected variations, both in my technical endeavors as well as in other areas of life. So, please bear with me as I recount some of the convolutions, and be comforted by the fact that I'm not rehearsing them all. :)

Now, as a pre-emptive nod to all you emacs lovers out there who are just hopping at the prospect of putting in your pitch for emacs org-mode here, know that I'm aware of and interested in that project. In fact, I already attempted to install it. But once I saw the outrageous size of emacs and associated files, I got cold feet. vim was far smaller, and the vimoutliner package that causes vim to function as a nice outliner doesn't add much beyond that. So, off I went for some experimentation with vimoutliner.

One of the interesting things vimoultiner does is to cause varying outline levels to appear in different colors. For example, the leftmost level will, in a terminal with a dark background, appear in a white font, while the next level--one tab space from the left margin--will be in a red font. The next level--two tab spaces from the left margin--will appear in a green font. And so forth. So, vimoutliner enables vim to use both a particular type of formatting, where tabs at the left margin determine outline levels, as well as applying font coloring to go with those levels.

That's a nice little trick in that the colors allow the eye more readily to distinguish between outline levels--something that, in more ponderous applications such as Libre Office Writer (LOWriter hereafter) is accomplished by both indentation from the margin and the use of varying symbols or letter/number combinations for the differing levels.

Which brings up another factor in my quest for a lightweight outliner: LOWriter's outlining mode is absolutely horrendous. It keeps popping up some tool bar as you move through outline levels, which steals focus from the cursor, forcing you to do a mouse click at the point where you desire to enter text. Not to mention the fact that it's severe overkill to use such a gigantic application for creating an outline.

As I found out from my experimentation with vimoutliner however, both the lightweight and heavyweight applications have their advantages and drawbacks, depending on what is the final goal. And speaking of final goals, this provides occasion for highlighting a wonderful discovery I made with respect to TeX/LaTeX: the author of vimoutliner (Steve Litt) has created a conversion program that turns his outline files into the chapter, section, and sub-section headings of a book to which can then be added all the remaining text. Incidentally, he uses LyX for entering in the additional text.

I created a few outlines using vimoutliner--not for any book publishing projects, my more immediate need being the creation of notes to be used during lecture delivery. Though it did work well for me for the most part, things were still wanting in certain respects when it came to lecture note creation. For example in a text editor like vim (nano has the same shortcoming, you'll doubtless understand) there is no simple way to render something that will render well in printed form, such as WYSIWYG word processors allow and such as is needed for something like lecture notes, that need to be as legible as possible and to contain various visual cues.

vimoutliner
For example, for use in the lecture hall, a larger font might be wanted--perhaps 14-point--and wider line-spacing. The varying symbols WYSIWYG editors can insert at differing outline levels also provide extra visual cues. Certainly page numbering, and perhaps even a header, would be desirable in the final, printed product as well. So, while the coloring vimoutliner provides on-screen for various levels is an aid to creating the outline, when it comes time to print the outline for use from the podium, it falls seriously short.

As a stop-gap measure, I imported the outline files I had made into LOWriter and performed some of the needed manipulations there. Not a very satisfactory solution but one that got me by at the beginning. The real solution to this issue, i.e., to creating from a file that works well on the computer to one that prints well onto a page, is to come up with some sort of conversion program, as Steve Litt did for his book outlines. That task--despite Steve's short-lived but well-intentioned efforts to teach me a little python (I got as far as creating hello.py)--remains at the moment beyond my capabilities.

Can I do something like this with nano?


But I've not given up altogether. One avenue I've begun exploring as a possible resolution to the issues--owing to being once again faced with the prospect of learning simultaneously two new systems (vimoutliner and whatever programming technique I'd need to use in order to convert my outlines)--is whether I might be able to employ my old friend nano in place of the less familiar vim in this scheme somehow. Oh yeah, this article is supposed to be about nano, isn't it?

My initial question was, then, whether I could get nano to function as well on-screen as vimoultiner. Could I make it do the same sort of indentation of levels, and possibly even cause it to assign differing colors to the varying outline levels? Well, that part of the equation turns out to have been quite trivial: with just a couple of simple tweaks to the configuration file .nanorc, nano can be made to do those same outlining features.

Here's how it's done. First, we'll need to locate nano's configuration file, .nanorc, or else create one. To do the latter, you would simply issue from the command line touch ~/.nanorc. That, of course, creates an empty .nanorc file in your home directory.

To invoke the outlining magic, two entries need to be made in that file. The first entry, which causes tabs made at the left margin to create persistent outline levels, is set autoindent. With just this entry in your .nanorc, nano will begin to treat all tabs that start at the left margin as level indentations--meaning that after each wrapped line or each hard return, the cursor returns to that same level on subsequent lines. To get the cursor back to the left margin, it's necessary to use the backspace key or the left arrow key.

The other way to get a .nanorc file in your home directory, or to perhaps create a nano configuration file that obtains system-wide, is to use the sample file found--on my Ubuntu computer--in /usr/share/doc/nano/examples, a file which, with proper editing, can implement nearly any tweak you might want to make to nano. For that file to be valid system-wide, it should, I believe, be renamed to nanorc (no leading period) and copied to the /etc directory.

In that sample file, for example, the line set autoindent is already included and you need only to uncomment it to activate that feature in nano. Likewise, you'll see toward the end of that file that a number of alternate nanorc files can be invoked as well. What are these?

If you inspect those alternate files--on my system located in the /usr/share/nano directory--you may note that they are pre-configured to apply color highlighting to certain types of files. For example, the html.nanorc configuration file stipulates that all files ending in .html, when opened with nano, are to have angle-brackets highlighted in blue, while other elements are to appear in red. This is all accomplished through the agency of regular expressions, which nano identifies as you type and so highlights with the defined colors in real-time.

I've worked a little in the past with regular expressions--mainly when I need to do "power searches" within LOWriter documents. I'm quite far from being conversant with the system, though, and need to consult some sort of documentation each time I want to do something involving regular expressions. Nonetheless, once I had read about these color-highlighting capabilities and understood that they relied on regular expressions, I suspected I might be able to get nano to do something very like the color highlighting vimoutliner does.

I had to experiment for a few hours, all the while trying to find any relevant snippets of information I might dig up on the internet, but I did finally find a way of causing nano to apply color highlighting to the differing levels that can be achieved by placing set autoindent into .nanorc.

That's done by, first of all, defining the extension of files to which the color highlighting should be applied. I decided to define my own extension: all files with the extension .outl should have the color highlighting applied to them. Then, I defined a set of regular expressions which cause color highlighting to apply to varying levels, as follows: white is applied to the first, left-most level; red is applied to the second level; green is applied to the third level; magenta is applied to the fourth level; blue is applied to the fifth level; yellow as applied to the sixth level; cyan is applied to the seventh level; and then the color scheme starts over again with red. I doubt I would ever create and outline that would go beyond seven levels, but it was trivial to add the capability to continue the coloration, so I did it.

Below is the entry I placed in .nanorc that causes the coloration to be applied:

syntax "outl" "\.outl$"
color brightwhite "(^).*$"
color brightred "(^[[:blank:]]).*$"
color brightgreen "(^[[:blank:]]{2}).*$"
color magenta "(^[[:blank:]]{3}).*$"
color brightblue "(^[[:blank:]]{4}).*$"
color brightyellow "(^[[:blank:]]{5}).*$"
color cyan "(^[[:blank:]]{6}).*$"
color brightred "(^[[:blank:]]{7}).*$"
color brightgreen "(^[[:blank:]]{8}).*$"
color magenta "(^[[:blank:]]{9}).*$"
color brightblue "(^[[:blank:]]{10}).*$"
color brightyellow "(^[[:blank:]]{11}).*$"
color cyan "(^[[:blank:]]{12}).*$"

The regular expressions stipulate that, in every file with the extension .outl, each new line that begins with a blank or series of blanks is to have all characters tinted with the appropriate shade to the end of the line. In this form, an outline can have a color-highlighting scheme that goes to thirteen levels. With those fairly simple modifications I was able to cause nano to mimic some of the chief characteristics of vimoutliner.

nano with my highlighting tweak
The difference, at least on the technical level, in how vimoutliner and nano handle the differing levels is not very clear to me. On the surface they differ in that my nano solution seems to treat all white space at the left margin as indicative of an outline level. So, either a space or a tab at the left margin indicates the second outline level, while either two tabs or two spaces indicate the third outline level. I believe there is no regular expression that differentiates a tab from a single space so, at my current level of understanding, it seems what I've come up with is the best possible solution for making nano do outline levels. In vimoutliner, on the other hand, only tabs at the left margin indicate outline levels.

What remains to be done: export outlines as can be done with vimoutliner


As I hinted earlier, however, my ultimate aims have not yet been accomplished. What I've managed to do thus far is to enable a console editor with which I am familiar to apply color highlighting to my outline files. This answers to two important considerations for me: it allows me to 1) utilize an easy-to-use and low-resource application to create outlines that 2) look good on the screen. But it does leave one very important consideration unanswered, namely how to get the created outline into a form that looks good on paper?

That's an issue on which I continue to work and I'm not really even sure where to begin. It seems that converting these outlines into a form that can be handled by LyX or even straight TeX/LaTeX, and from there into a nice printed form, should be possible--as certain vimoutliner add-ons that apparently utilize python for this, indicate. Since my capability with python has not progressed beyond creating hello.py, I'm certainly in no position to attempt to create that sort of converter.

A more congenial place for me to start, since I have slightly more experience with it, would be to use bash somehow. The little I know about it leads me to wonder whether, by bringing to bear something like awk or sed, a sort of search-and-replace could be done on the .outl files in order to add the relevant mark-up to them. But to be honest, I lack even the rudimentary knowledge to know whether bash might even be a viable option for this task.

Another alternative might be to create some macro in LOWriter that could import and apply formatting to these files. I don't have much more experience with macros than I do with bash scripting, though I have become quite familiar over the years with the LOWriter interface and the program's capabilities. Of course TeX/LaTeX printed output looks superior by far to what any office suite can produce. But I would be satisfied with a somewhat aesthetically inferior product for these lecture outlines if I could more readily accomplish the task with LOWriter.

If you have suggestions for any of the issues raised above, please offer them. Specifically, if you know of a way to distinguish, using regular expressions, tabs from spaces, please offer your input. Also, if you know whether the conversion of which I speak might be accomplished using bash and related utilities, please let me know: that would involve essentially searching for end of lines together with tabs/spaces and followed by any character, then replacing those instances with the same end of line, number of tabs/spaces, a TeX/LaTeX mark-up string, then the same character with which the line initially began (incidentally, the mark-up can be found at this site). Likewise, if you have any Libre/Open Office solution for importing these files into a list or outline, please say your piece.

6 comments:

  1. nice idea, more into markdown type languages for this kind of thing though.

    anyway:
    color brightred "(^[]).*$"
    replace with a literal tab

    not sure why \t wouldn't work but im no regex guru so i could have been missing something obvious

    ReplyDelete
  2. sorry make that

    color brightred "(^[TAB]).*$"

    replacing TAB with a literal tab.

    ReplyDelete
  3. This is interesting. Nano is definitely easier to use than vi. Vi is so cryptic that its functionality fades from the mind unless used frequently. I used to use vi a lot but haven't for years. Nano is the way to go.

    Consider learning a little HTML. You might be able to get Nano to output HTML that you can then display with a web-browser for viewing and printing that you can control with CSS. HTML is much easier to understand than Python.

    Another useful text editor is jEdit, but jEdit is more resource intensive and you must have a java run-time environment installed; however, written in java means that jEdit is cross-platform compatible. I use both jEdit and Nano. jEdit for casting HTML files among other things, and Nano for editing files on another machine via a wireless MODEM or when I need to do something from the command line and don't have a GUI running.

    Python would be my programming language of choice. I've looked into it and think it is very powerful and easier to use than a lot of others, but haven't had the time to devote to learning it to any extent. You should be able to pick up HTML fairly quickly.

    ReplyDelete
    Replies
    1. VIM is OK! I’ve tried it, but prefer FreeMind which is written in Java. FreeMind can export your mind-map direct to an outline that can be opened by Libre (Open) Office. I use FreeMind extensively.

      Delete
  4. Outstanding, markdown type languages are very useful these days.Sample Documents

    ReplyDelete
  5. You're right, html is definitely worth looking into. I do know some, though the little knowledge I have of it is pretty dated. I've looked into jedit in the past but have not yet tried it. I'm kind of attached to nano or some command-line editor because, when I'm away, I ssh in to my machine at home and connect to a screen session I leave running there. But I'm definitely up for exploring various alternatives.

    ReplyDelete