Persistent undo buffer for scripts and text files

Today I did what I was planning to do for some time. I added persistent undo buffer for my build scripts.

This is second side effect of naracea usage I didn’t expected when I started the development. When I moved my dev notes to naracea, I was kind of afraid of data loss. The file format was still not fixed and there were some bugs in file saving at that time. While I keep my documents in version control system (as everybody should), I was thinking I should have a backup plan for the case when something goes really wrong and document gets corrupted while being saved. So I added two phase save (first rename the existing document, then save the new version and only when the save is successful remove the previous file) and as a last resort I implemented automatic export of the document’s content to the text file.

I never needed the feature, since I never experienced the problem so bad that it would corrupt the document file, but it was there, and I was thinking how it can be useful. And then I realized that adding possibility to set the autoexport filename would allow me to use naracea as an undo buffer for normal text files.

Here is how it works: in my project folder I created subfolder named “_undo”. I created new naracea document called “scripts”. In the document I renamed the branch to “rakefile”, put content of my rake script into it and set its autoexport filename to “..\rakefile.rb”. Now, when I want to edit my rakefile, I open “scripts.ncd” naracea document and when it is saved, the rakefile branch is automatically exported to the actual “rakefile.rb” file in document’s parent folder.

Sounds complicated, but it really isn’t (see forum post which describes it in more detail).

So now, if I edit my rakefile in naracea, I have all changes made to the script persisted, and I can move back and forth in the script’s history without being scared that I won’t be able to undo changes after I close the text editor (which is exactly what happens when I use other text editors).

Sure, naracea is not programmer’s text editor, and it doesn’t support syntax highlighting etc., but still: the feature seems neat to me.

No settings

If you’ve tried naracea already, you probably noticed there is no settings dialog. This is intentional — since the very beginning I wanted naracea to be settings-dialog-free. Reason for this is the fact, that I thing that settings dialogs are evil.

Let’s say you install an application. What is the first thing you are going to do? If you are like me, you will find the settings dialog, and then waste some time by changing what is in there. Then you get used to your specific settings and when you need to move to other computer (let’s suppose the application is available there), you will feel awkward until you waste the change-stuff-in-settings-dialog time again.

And then there is the time you waste by looking into settings dialog to figure out whether there is better way to set up the application. And honestly, there is very little value in all that time invested in changing settings. You would be able to use the application pretty much the same way with reasonable default settings.

Don’t get me wrong: I’m not saying there should be no settings in application at all. There are some cases when allowing user to change things is pretty much inevitable. For text editor it would be crazy not allowing to set the font size. I’m not so sure about the font face, but that is still OK for me. But building extensive settings dialog, where you can change every little aspect of the application behavior seems, well, unreasonable to me.

In naracea, the closest I got to the usual settings dialog was autosave. When I started implementing it, I felt like I really need to create the settings dialog. But then I was thinking: when I want to enable autosave, what do I want to really achieve? The answer is: reduce the amount of wasted work when something wrong happens and application crashes, or power goes off. Do I really need to set the autosave period? I don’t think so. What I need is reasonable default autosave period, and ability to turn it off in some special cases. And what amount of work I’m willing to sacrifice? Right now I think it is 3 minutes. Therefore by default all new documents in naracea are created with autosave turned on, and the time interval between saves is 3 minutes. It is possible to turn the autosave off, but it is based on document, not application global settings, because I believe there are documents for which autosave is good and documents for which it is undesirable. Having global setting would break this, and it would enforce the autosave on documents for which I really don’t want it, or disable it for document for which I really want the feature.

So in naracea there is document properties dialog with single check box which allows turning autosave on or off.

And I took similar approach to all other things which are configurable in naracea: set reasonable default value, allow user to change some of the things, but remember, that while some settings are global, more of them is related to the document, or event branch. (In fact, there are only five global settings in naracea: font face, font size, background and text color and width of the editing area when application is maximized.) And most importantly: prevent settings dialog, which would take forever to go through.

Because at the end, naracea is text editor, and what people should be doing with it is editing text, not settings.

Keeping to-do list and notes as a text

Honestly, I’ve never believed in stories about somebody building A just to suddenly find he’s built B.

That would be like – I don’t know – me saying I’ve started building text editor fitting my writing habits so I can write that novel I have in my head, and in the middle of the process realizing that I’ve created nice tool for keeping to-do lists and notes.

Well.

You know.

That’s exactly what happened.

It all started when I moved my dev notes from OneNote to naracea. Once naracea started to be really usable, I felt strong obligation to use it on day-to-day basis. Because developing an application in my spare time, took all my spare time, I wasn’t (and I’m still not) able to do any serious writing. So I moved all the notes I kept in OneNote to naracea because it was obvious thing to do and in fact those dev notes are still one of the few documents I work with on almost every day.

Don’t get me wrong – OneNote is great application. I used it quite extensively, but there was one thing I really miss – history tracking. Keeping track of the history is crucial for me, because while I work on naracea regularly, I have only limited amount of time every week I’m able to dedicate to the development. Therefore I need to keep track of all decisions I’ve made, all bugs I resolved, and all features I want to implement, preferably in one application, in one document.

I’ve tried couple of to-do list applications, but the problem with all of them is, that either there is just too many things to change in the settings (which I always end up to do — turning things on and off, changing columns, rearranging tasks etc.), or their functions are not sufficient. And after some time every to-do list I’ve tried got noisy, and I needed to switch between different modes and views so I see what needs to be done and what is finished already.

After a short time, I ended up keeping my development to-do list as a bullet point list in OneNote, and once the task was done, I moved it to the bottom of the notepad and changed its formatting to stroke. This isn’t the nicest solution, but it seemed to work.

However, once I moved those notes to naracea, things get so much easier. I add everything to one long to-do list and I mark each task with simple marker (it is [bug] for bugs, [feature] for features). Once the task is finished, I write short note (with characters => in front of it) and then I just delete the whole task.

This keeps my to-do list as short as possible — there are only tasks I’m working on or those which are still in queue, but the information about finished tasks is not lost. I can just open the find dialog, search the history of the document for occurrences of either [bug] or [feature] to get the whole list almost instantly. Because the find dialog shows text around the matched string, I can navigate through find results quickly and find what I’m looking for.

When I need to check some facts or decisions I’ve made couple of weeks ago, I just search for keywords (let’s say when I see some chance to simplifying the code which is saving all files, I can search for “save all”), and I get the information why something is the way it is with very small effort.

Second thing which makes note taking in naracea extremely simple are branches. Originally, branches were meant to keep different versions of the document, allowing writing parallel versions or alternative endings or making reviews and editing easier. While branching can still be used for all of this, now I use then as a way to keep things related to one project in single file. Instead of using branches for real branching, I use it as a way to keep several notepads in single document.

In my dev notes I have three branches: one for general to-do and bugs, one for something I call “knowledge base” (I keep my design decisions there) and one for feature ideas. With these I have all things related to naracea development in one place, but somehow logically structured and with full history. Designing a feature is iterative process, so I first write everything down into couple of paragraphs, then I refine it and finally I clean up stuff which is not useful. But it is still there, so when I need to check why I rejected possible solution, I can get back and see why I rejected it.

I use this feature so much (for other things and projects I need to track), that I added button for creating new empty branch to the ribbon.

So while originally I started naracea as a text editor for writers, it seems that the set of features I decided to implement makes it really nice program for people outside of the community I originally meant it for.

Well, sometimes strange things happen.

(Suggestions for keeping textual to-do lists in naracea are also in this forum post.)