Back to the text file?

< Next Topic | Back to topic list | Previous Topic >

Posted by Derek Cornish
Dec 8, 2006 at 07:58 PM

I came across one of Chris Murtland’s blog items of last year [ http://www.murtworld.com/2005/09/life-in-files.php ] today, where he discusses the value of using plain text files as one’s basic information-container (but maybe extending this to cover pdf files, and other widely-used standard types: html? xml?). As he mentions, this is a more modest - and perhaps more practical version of more radical solutions, e.g. http://www.43folders.com/2005/08/17/life-inside-one-big-text-file/

In fact, there is a lot of interest in text-files - e.g., http://gtdwannabe.blogspot.com/2006/08/ive-got-text-fetish.html and http://todotxt.com/whytxt.php where the rationale is pithily explained: “Plain text is software and operating system agnostic. It’s searchable, portable, lightweight and easily manipulated. It’s unstructured. It works when someone else’s web server is down or your Outlook .PST file is corrupt. Since it’s been around since the dawn of computing, it’s safe to say it’s completely future-proof. There’s no exporting and importing, no databases or tags or flags or stars or prioritizing or [Insert company name here]-induced rules on what you can and can’t do with it.”

It also forces some difficult choices - for example, maybe abandoning software that uses proprietary file formats that make it difficult to search them from outside, unless the data itself remains as ASCII (e.g. Lotus Agenda; Zoot).

Given my predilection for Zoot (no rich-text editor) and continuing love of the old plain DOS programs and interfaces, I’m a natural pushover for people who suggest getting back to ASCII basics.

A lot of the web material I now mindlessly download and store, images and all, in bloated directories could as easily be d/l as simple text. Maybe that would be a good discipline, and maybe others stronger-willed than I do so already.

So is there still mileage in the idea of going back to basics in this way? What do others think?

Derek

Posted by Stephen Zeoli
Dec 8, 2006 at 09:29 PM

Derek,

There are a great many advantages to plain text, many of which you’ve mentioned in your commentary. Here’s another advantage:

I sometimes have to pretend to be a graphic designer. When I do, I always convert any Word documents or RTF documents to plain text before importing into my desktop publishing program—this way you don’t get any annoying formatting code gumming up the works. I do the same when importing text into Front Page when creating a web site.

When composing my own text, I often work in a plain text editor—Note Tab. It’s nimble, quick and clean, and that makes it easy to redraft sentences on the fly—something I find myself doing, even in so-called “first drafts.”

I’d guess that 90 percent of the information I collect and manage is perfectly fine in plain text. I’m one of those eagerly awaiting the version of Zoot which will handle formatted text, but I hope Tom Davis also provides the option to capture and store information as plain text.

Steve Z.

Posted by Derek Cornish
Dec 9, 2006 at 01:22 AM

Steve -

> but I hope Tom Davis also provides the option to capture and store information as plain text.

Me, too. On an aside, unlike many people I find the Zoot interface positively elegant with its lack of huge, clumsy, unhelpful icons, and clear simple three-pane text-based display. I have it tricked out in a fetching combination of autumnal colours (suitable to my time of life) that are always a pleasure to encounter.

I wouldn’t want to go cold turkey in respect of graphical data, of course, but I often feel that I waste a lot of time either d/l data in graphics-enhanced forms that I don’t really need, or in using graphics-oriented programs that store data in unhelpful ways - proprietary, encrypted, etc. (I exclude non-graphics ones like Brainstorm that store data in text format, or those like PocketThinker that use opml.)

What I am thinking about in no very coherent way - it’s the end of the week, after all - are the relative benefits of keeping in closer contact with basic text. Among other things it might involve working in plain text via wikitext, LaTeX, and other text+markup approaches as opposed to WYSIWYG. It might also involve routinely converting any essential file formats that aren’t plain text into plain text - like the way html tags are stripped out of files, or pdf files into ordinary text files - so that could be handled by programs like Zoot. After all, most of the time I just want the “text”.

I’m not sure how much mileage - if any - there is in this notion, but for those working mainly with unvarnished text - i.e. writing as opposed to anything involving presentational considerations - it might reduce the need for so many programs, and the ensuing CRIMP that often spirals out of control as a consequence.

Of course, OTOH, this may just be an invitation to CRIMPING pastures new - see, for example, the mouth-watering http://www.latexeditor.org/screenshots.htm

Derek

Posted by Chris Murtland
Dec 10, 2006 at 05:24 PM

I’ve gotten to where I don’t consider a backup of a program’s data files to be a real backup, if those backups aren’t plain text, HTML, or PDF. The lifespan of file formats is a real problem. PDF is kind of a borderline case; I’m not sure it’s as good as plain text or HTML as far as longevity, but I’m assuming it’s well entrenched enough that there will be conversion tools for a long time.

I have tons of backups of files from Zoot, Ecco, Info Select, and many other programs. It’s a long term CRIMP side effect - you end up having your various attempts at being organized strewn all over in general chaos (I have the related problem of “starting from scratch” numerous times, so each application also has many different sets of data files that represent different attempts). I’m systematically converting all of these to plain text where possible, and frequently converting from whatever apps I’m currently using that have proprietary formats. It’s a huge task to work through old backups, but it’s a nice feeling to “liberate” the data so that I don’t have to have a specific program to access my information.

Chris

Posted by Derek Cornish
Dec 12, 2006 at 07:42 PM

Chris -

I’m still not quite sure where I am going with this, or what triggered it.

1. One aspect was your concern about future-proofing data when archiving it, and thinking - like you - that plain text seemed the best way.

2. Another consideration was making all my data as available as possible to the other programs I use - in particular, to Zoot (see 3.) and to indexed search programs. I was tired of finding that, although the best of these programs will find and index text in ANY file, the display of “hits” is often poor.

3. I wanted to standardize on Zoot “as is” - i.e. not wait for the new 32-bit version, or rich-text editor, etc - and just accept it for the very fine plain-text program it is. Since Zoot works so well with Outlook - which is itself all about “text” - and has its incredible Zooter for receiving and sending textual data to/from other programs, these were added reasons for standardizing on it.

4. I wanted to explore various ideas about splitting up the roles of writing, styling and formatting when drafting articles and books, and not trying to do everything at one and the same time (and in one program, MS-Word, which I admire, but don’t feel comfortable working in). One reason was to reduce distractions when writing; another was to be able easily to produce plain text (see 2.) - preferably as a default output.

5. When downloading information from the web, I wanted to try to discipline my temptation to download entire web-pages. Instead, l need to move towards extracting the information and linking it either to the original URL or - if I really need one - to a local copy of the web-page. The same goes for pdf files - extract the text (using OCR where the pdf is an image file), and link to the URL or a local pdf copy.

6. As far as outlining is concerned I don’t anticipate problems; most modern programs can export to plain text as well as to MS-Word. Older applications like Grandview can export to text and to structured text for export to a more modern outliners, and then on to Word.

A lot of these things I do already (sporadically…), or have done in the past. Obviously there are some hurdles to his approach. Zoot needs a better editor, whether rtf or not. It also needs to be able to handle longer notes, and more folders. But the move to 32-bit alone will solve many of these problems. Meanwhile one can usually work productively within these constraints. Zoot databases can be exported easily to text (e.g., csv), and making more use of delimited fields within Zoot enables more metadata to be exported, too.

With regard to point 4, I’m still thinking about the LaTeX route, maybe with Lyx, but this still distracts from writing IMHO. So I will probably settle for using a plain-text editor for all my drafting - maybe with a few ad hoc markups for headings and emphasis - and leave everything else (styling, formatting - including integration of charts, tables, footnotes or endnotes, references, etc) until later. In this scenario, working in MS-Word (or even Lyx) would be postponed until the final stages.

One drastic simplification would be to use Darkroom - http://they.misled.us/dark-room . Another might be to go back to a DOS program like PC-Write that uses dot commands and a limited number of non-ASCII codes to mark up for emphasis (italics, underline, bold), but whose files are simply structured and eminently readable quasi-ASCII ones.

This way of working is probably most useful for longer articles, reports and books. But trying to get as much of one’s information into plain text has the wider benefits I mentioned above.

Derek

Back to topic list