What will be new in 1.5

My original plan to release some minor update to 1.4 didn’t pan out very well, to be honest. Once again I couldn’t resist the call of new features, and I did significantly more than I wanted to do. Which means that I’m just testing version 1.5 which doesn’t contain many new visible changes, however it provides a way to author plug-ins. As a proof of concept (and a guide for anyone who would like to write one) I extracted file exporters to separate plug-ins (so now there is separate plug-in for each export format Naracea supports, and it should be trivial to write more, if there is demand for that) and I prepared one sample plug-in which generates couple of paragraphs of lorem ipsum, just to show how to extend UI (this plug-in is not part of .exe installation, because it is… well, quite dumb, however you will be able to get your hands on it if you download .zip installer).

Plug-ins do not require any special installation, just copy them to application installation folder and restart the app. To get rid of plug-in, just delete the .dll. Sure, things can get little bit more tricky when plug-in depends on some 3rd party assemblies, so perhaps I’ll introduce a way to manage this kind of conflicts, but right now things can be kept simple.

So, if you want to take a look on plug-in interfaces, visit Naracea.Plugins repository.

Now, all this is pretty boring, and I probably wouldn’t go from 1.4 to 1.5, if there wasn’t something more. And the one more thing thing is one new plug-in which I’ve written. And that plug-in is Python scripting engine.

Sure, I understand this is not something revolutionary, because there are plenty of editors which can be scripted in various programming languages (and also writing Python scripts to do things with text editor has appeal for limited audience), but well, it is still really exciting to write a script and… well, see it running.

For me scripting is a natural way to extend Naracea’s functionality, mainly because I don’t need to compile and build and package whole application for one little missing piece of functionality. I just write a script, test it, and here we go, I’ve got a new function.

Anyway. There is a bit of UI related to Python scripting, which is quite obvious. Scripts need to be stored in Naracea’s application data folder, and you can open that folder from UI. Plug-in creates Naracea document configured to have Pyhon syntax highlighting and exporting everything to the right place with .py extension, but you don’t need to use it — just copy your scripts into folder and click refresh.

Currently I’m testing the whole thing, and tuning couple of other minor features I implemented, so I expect 1.5 release to be available in couple of weeks. Stay tuned!

Find and replace

Designing find and replace for naracea was so much fun for me.

You know, I’ve always felt somehow dissatisfied with how searching works in most text editors. There are usually two things: a) find next/find previous and b) find all. And once you edit something in front of the text you have searched for, you must search again, because search results are not being updated. Let’s face it: every search engine struggling with limited browser abilities have better UI for search results than most of desktop text editors backed with all those fine tuned UI frameworks.

So after a short period when I was considering going the usual way, I decided to try to do something little more user friendly with search:

What we have here is seemingly the usual set of next/prev/all buttons, including some replace buttons (because I believe finding and replacing are related so much in text editing, that they should never be split in two windows).

As you can see, results contain a lot of additional information. There is text surrounding matched term, so it is easier to see which result is the right one and there is information about position in the text. Also document and branch where the match was found are there. And as the finishing touch, there is replace button on each result item, so you can replace the matched text right there, without moving the mouse pointer to the top of the window.

Also: searching for something else (or in some other document or document’s branch) doesn’t necessarily clear the results. It is possible to have listing of several searches in the results list. Clicking on the result will take you to document, branch and text position of the match.

But what happens if we insert or delete some characters in the text? Right, the search results get updated as the text changes, so even after you edited the document, the results are still pointing to that one occurrence of the text we have searched for.

This seems more like what I would like to have in all text editors with find and replace.

When this was finished, I’ve started thinking how timeline, while useful, is just not enough to make all those stored changes really useful. To be really able to find something in history of the document there needs to be a way to search it.

And here it is: by selecting “Search the text and its history” in combobox above the replace all and find all buttons, you can search the whole history of the document. Of course, it is not possible to replace anything, because as we know history cannot be changed, but using this feature you can easily find whatever text you’ve written though the whole existence of the document:

Of course, for long documents, it takes some time to go through all the changes and find all occurrences of the word or sentence, so the searching of the history runs asynchronously, and it is possible to write more text while the search is ongoing. The search always starts at the current change and the changes are rewound one by one and the rewound document is then searched for the search term.

So this is how search and replace works in naracea. There are couple of interesting scenarios which are enabled by the history searches, but I’ll keep these for future posts.

When undo is not enough

Writing, at least for me, is iterative process. I tend to write something, then delete it only to find that I actually need deleted part of the text in other place. Eventually I realize, that what I’ve written first time was better than the version I use instead of it.

For short blog posts it is not that annoying, but when writing longer essays or fiction, I feel quite miserable from time to time, because I need to re-write something. To correct this, I decided, that if I was going to write text editor, it would have infinite undo, and that the undo buffer would be saved along with the text.

When I started prototyping what eventually become naracea, I realized two things. First of all, when you store all typing and deleting you have done, there is no need to store the actual text. You can reconstruct it from recorded changes, and with a bit of optimization on the UI side, very good performance can be achieved. Second thing is, that to manage infinite undo buffer old undo and redo operations are not enough.

Let’s take a look on how the undo usually works: we start typing some text:

Lorem ipsum dolor sit amet

Now assume we undo last three words:

Lorem ipsum

But what happens when we hit period? We get the text

Lorem ipsum.

and empty undo buffer. So now the text “dolor sit amet“ is lost, and there is no way getting it back. It is indeed logical behavior, because with just two commands for managing undo and redo, there is no way to get any better. And that’s the reason why naracea uses along with undo and redo (which work the very same way they do in all other text editors) also rewinding and replaying.

If you think about that, undo and redo are editing commands like typing or deleting. It actually alternates the text. But to be able to keep infinite history of the text, we need operations, which are not changing the text it self. We just need to move though the recorded changes and revoke the effect they have on the text.

So in naracea, using undo or redo will store the “change”, which points to changes which are being undone or redone. On the other hand using rewind and replay will just move though the stored changes and present the text in the form it was before each particular change was made.

So using our previous example, rewinding from

Lorem ipsum dolor sit amet

to

Lorem ipsum

will not store any change, or issue and editing command. By clicking on replay button we can get the original text back very easily.

What happens when we rewind the undo? Well, all undone changes will be restored, and the text will look like no undo was done at all.

So taking the final state of the undone document

Lorem ipsum.

and hitting the rewind button will change the text to

Lorem ipsum

Hitting replay again and again will change the text to

Lorem ipsum d

then to

Lorem ipsum do

and if we keep hitting the button long enough, we will end up with the text we had before pressing the first undo:

Lorem ipsum dolor sit amet

Now, what happens if we continue using rewind? The characters will start to disappear again, but now we are not undoing them. We just rewind all the changes until we end up with empty screen. But remember, all changes are stored in the application, so one easy hit on “replay all” button will bring the text back to the last change we have done:

Lorem ipsum.

(Of course, rewinding and replaying text by single change would be tedious, so there are convenience commands to rewind/replay by words, sentences and paragraphs, and similar convenience functions for undo, so you can undo the whole sentence at once.)

You might be thinking: what happens when I have rewound document and I press some key to insert a character in to the editor? Well, there are several options what to do (e.g. preventing editing on rewound text, or replaying it back to the end), but it seems most reasonable to just silently generate undo command, which will turn rewinding in to actual change and allow you to continue as if you undone all the text manually.

But there is more: if we have all these changes stored somewhere, what else can we do with them? You are right. We can try to generate some statistics out of them! While certainly it would be most interesting to build lots of charts and tables from the changes, for version 1.0 there is only one basic “statistic” available. Under the editing area, you can see the timeline. Timeline is graphical representation of how many changes you’ve done to the text in chosen time span.

It is possible to set the span from 1 minute to the 1 year, so you can analyze your writing habits and performance. By default application doesn’t show empty bars, which correspond to the time intervals you have written nothing, because it can turn really annoying really quickly, but for sure you can turn the empty bars on, and then you see your writing performance in one bar graph with resolution you like.

There are more distinctive features in naracea. I will shed some light on them in future posts.