Skip to content
A scene from Ireland

Edlib

  • in Edlib
  • 6 min read

edlib - commands

It been over 3 months - maybe you thought I had given up - but no. I had some holidays and other distractions, but I'm back and will be working fairly consistently for a while.

The topic for today is "Commands". Commands are a standard interface for code in one module of the editor to call code in some other module. Various objects in the editor have commands attached to perform various tasks specific to that object. To some extent you can think of commands like object methods in an object-orient system, but that is only part of the story.

In many cases, commands are associated with names in a key-map. The key maps were hinted at in my previous note about managing input, but they are broader than that and details have changed since last I wrote. So maybe that is a good place to start.

  • in Edlib
  • 5 min read

edlib - managing input

Commands to an editor - at least the sort of editor that edlib is designed for - usually involve single keystrokes or key combinations. Translating those keystrokes, as well as mouse actions, into commands is the topic of this note. Many editors also support commands that are written out with words. Such commands are often introduced with Meta-X in emacs or "colon" in vi. For the purposes of edlib, such interactions can be managed by creating a simple document in a small window somewhere and accepting key-stroke commands to edit that document. Some keystrokes will "complete" the command which will make the window disappear and will perform the required action. So word-based commands are certainly possible, but they happen at a different level.

  • in Edlib
  • 3 min read

edlib - displays and panes

Displaying the document being edited is, of course, very important for any editor.

I have memories of the first editor I used on Unix which was em, rather than the well known "ed". It actually allowed a single line to be edited "directly" rather than by using pattern substitution (s/pattern/replace/) commands or rewriting whole lines. It also had a 'v' command to view lines of context around the current line. That ability to see what has happening helped a lot.

We've come a long way of course and today we expect to be able to easily see and move around the context of the place we are editing ... though that "context" is usually the very simple "nearby lines of text".

edlib needs to make it easy to provide a display of context, without mandating what that context might look like. To achieve this it provides "displays" and "panes". These are used for directing input from the user to the documents as well as for displaying content from the document to the user, but for now just the latter will be discussed.

  • in Edlib
  • 6 min read

edlib - because one more editor is never enough.

I've decided to write an editor. Silly idea I know - there are already two out there: both vim and emacs are quite good. I've heard rumors that there might be others, but investigation always shows they are just toys, not real editors. They don't support reading email, unless that is all that they do.

And I know that I'm supposed to be designing a new language: ocean. And I will... maybe. But how can one write code for a new language without a new editor (though one could equally wonder what language a new editor might be coded in if not a new language...). Ocean will have to wait.

So why a new editor? Well I really love emacs. Really. But I also hate it. I've tried programming in emacs and I just can't manage it. It isn't just the LISP (though that doesn't thrill me), it is the low-level hacking at the attributes in the buffer to create the image that I want to display. It feels like assembly programming. It is probably a personal weakness on my part - other people seem to manage. But isn't it always out of personal weakness that great genius emerges? I'm sure it is.

  • in Edlib
  • 6 min read

Document Storage

The next question to ask and answer is: how do we internal store a document.

The key issues are:

  • space-efficient storage of large texts
  • time-efficient small manipulation of text (add/delete in middle)
  • easy storage of stable pointers into the text
  • easy storage of assorted attributes with the text
  • easy undo-list maintenance
  • in Edlib
  • 2 min read

diff/patch editor

Another Use Case has occurred to me that I would really like this (hypothetical) editor to be able to support well. That is a diff/patch editor.

The basic idea is that when doing distributed software development, the items that are traded are patches. It is important to be able to work with these effecitively, both including them into ones own source tree, and generating a set of patches to distribute

  • in Edlib
  • 2 min read

Programming Approach

The point of this article is to try to describe the approach to developing an application within this editor.

A substantial motivation for this editor was the (apparent) difficulty in writing applications for EMACS. The difficulty lies in the need to worry about the wrong sort of detail. In EMACS that display is very tightly tied to the buffer contents. It is possible to hide parts of the buffer, and to display parts of the buffer differently, but the level of abstraction seems all wrong. There needs to be a clearer separation between the buffer and the display, with the option of arbitrary programatic conversion from buffer to display.

For this to be achievable without simply introducing a different sort of complexity there needs to be a clear model explaining how things should work.

  • in Edlib
  • 3 min read

More about documents

Many documents consist of just a single file, that can be read into a single document buffer. However this is not always the case.

A good example is a mailbox containing mail to be read. This can sometimes be a single file, but can also be a collection of files, either read from the filesystem or from a network connection such as with POP and IMAP. Another example is an HTML page that contains images. These images are stored in separate files.

  • in Edlib
  • 2 min read

Parsing Procedure

Parsing of documents needs to happen incrementally, both a high-level parse that just finds major sections, and low-level parses that only do a small local part of the document.

UNFINISHED

  • in Edlib
  • 1 min read

Dreaming dreams

I had a couple of weeks off recently (parent duty for the school holidays) and spent some of it playing with ideas for a document editor. You can find them under the Dreams link on the right.

I observed about myself a particular flaw in my approach to design. I tend to have grand ideas and try to develop them completely. I often run into difficulties in detail and tend to get bogged down in those details. Instead, I should solve a simple version of the problem and only come back to the more grand scheme once I have more experience with the whole system.

Maybe I will learn from this and not allow "Perfect" to be an enemy of "Good"...