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.

A “display” is simply a rectangle that the user can see which can contain text and probably other things.  So a text window provided by the likes of “xterm”, a full graphic window in X11 or wayland, or maybe even a canvas in an HTML browser could server as a display.  A particular instance of an edlib editor can potentially have several displays of different sorts, each showing the same documents or different documents.

Each display provides a top-level “pane” which can have arbitrary children and more remote descendents.  Drawing performed in any pane is clipped to that pane and its ancestors.  Panes can be given a ‘z depth’ in which case they obscure any parts of other panes with a lower ‘z’ and which overlap in x,y space.  This allows for panes to provide pop-up dialog boxes, drop-down menus, or various other facilities.

A pane has no appearance by itself.  Something must render into it, whether that is to draw boarders, a background, or content. A typical arrangement might be that children of the root form tiles.  Each tile draws enough border to separate it from others (maybe just left-and-bottom) and then displays some document in the remainder of the pane.

A pane used to display a document might contain further child panes, maybe one per line of text, maybe two for parallel renderings of the same content in different styles.  The choice is up to the rendering code.

Each pane has a set of ‘damage’  flags which record if the pane might need to be redrawn at all.  It is expected that refresh will involve redrawing whole panes.  Which nesting level of pane needs to be redrawn will depend on the level of damage.  If just one pane is damaged and it can be redrawn without changing its size, then maybe only that pane needs to change.  Damage is normally detected when a document signals a viewer that the document has changed, and the viewer determines that this could affect some particular panes.

Implementation status

As yet the only display driver that I have implemented in an ncurses based driver to run in a terminal window. A tiling pane manager is available to divide a pane up horizontally or vertically, and a document can be viewed within any pane, complete with (very simple) scroll bar.

Working with a pixel display will clearly provide challenges that are not met when working on a simple character based display.  I suspect that I will make it possible to treat a pane in a pixel display just line a character based display, and will allow panes displaying different parts of a document to use different font sizes but still be simply character based.  This could make it fairly easy to use large fonts for headings in mark-down, or smaller fonts for text that is further away from the cursor and so probably less interesting. Lots of experimentation is needed. Support for images and general curves is important too.

I imagine that it will be useful to be able to display HTML and I don’t want to write an HTML renderer.  The idea of allowing webkit to display in one edlib pane is very appealing.  It probably wouldn’t be very useful for editing a document, but for simple display (an important role of an editor) it could provide just what is needed.

This entry was posted in edlib. Bookmark the permalink.

2 Responses to edlib – displays and panes

  1. Sankar says:

    I implemented an editor in college (about 15 years ago). Then a few years back, I wanted to implement another editor, no, not just another editor, but an auto-completing, self-learning, transliterator.

    To explain what it means, I wanted to develop an editor that will transliterate tamil words via english keys. Instead of merely transliterating, it should also auto-complete by first transliterating whatever keys pressed and convert them to a token and then do a token prefix matching in a dictionary of words. https://github.com/psankar/vaiyakani

    For this dictionary, I need a tokenizer and so I went and wrote a corpus builder which can read and tokenize Tamil words by reading Blogger, wikipedia and wordpress XML dumps. https://github.com/psankar/korkai I realized how amazingly fast CPUs are when my goroutines split, sorted and tokenized and ranked a million tamil words from a 600+MB xml file in about 7 seconds. Also realized how slow interpreters + single-threading is when the same process took about 5 hours for a python program made by a different author.

    Then I realized that I need the archive to be downloaded which may not be possible. So I tried finding out what is the way to get all the posts via RSS/Atom (so that I can extract words for any Tamil blog whose URL I know without asking its owner to send me the XML dumps) and realized that that is not possible.

    I learnt a great deal about Tries and other datastructures. My idea to combine the concepts of B-Trees and Tries to get an efficient datastructure for auto-completion was a good thing to have in my head for a while, until I went into a spiral of self-questioning negativity.

    I thought a bit about the architecture and I did not want the UI rendering to be done on a normal terminal. So I tinkered around finding clues to embed webkit in a terminal or a cross-platform widget. That lead to finding out how to write cross-platform desktop apps using nodejs. Then that lead to finding out how to do the same using Golang + webkit combo for a desktop app. Then I tried my hands on a while for the Chrome extension (bcos, what better way to distribute the product (even though it is not done yet)) and that lead to analyzing ace http://ace.c9.io/ etc.

    Did more investigations and found that GEdit supports a library to make it easy for writing editors. But why will I even think of writing an app with GTK anymore and pondered with that thought for a bit.

    Eventually, I realized that I have not done anything except waste about an year on analyzing the surrounding things. Now seeing your blog, too tempted to do to something useful again :)

    • neilbrown says:

      “until I went into a spiral of self-questioning negativity.”

      So I’m not the only one who does that? Cool!

      How does one enter Tamil without an auto-transliterator – there seem to be more characters (or is it “syllables”) than fit on a western keyboard? Do you need a special keyboard?

Leave a Reply

Your email address will not be published. Required fields are marked *

7 × four =


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>