2004-07-11T08:29:36Z 2004-07-11T08:29:36Z 2004-07-11T08:29:36Z http://neil.brown.name/blog/20040711082936 <p>The next question to ask and answer is: how do we internal store a document. <p>The key issues are: <ul><li>space-efficient storage of large texts</li></ul> <ul><li>time-efficient small manipulation of text (add/delete in middle) </li></ul> <ul><li>easy storage of stable pointers into the text</li></ul> <ul><li>easy storage of assorted attributes with the text</li></ul> <ul><li>easy undo-list maintenance</li></ul> <p><a href=http://neil.brown.name/blog/20040711082936>read more...(No comments)</a> 2004-05-08T21:08:40Z 2004-05-08T21:08:40Z http://neil.brown.name/blog/20040508210840 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. <p>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 <p><a href=http://neil.brown.name/blog/20040508210840>read more...(No comments)</a> 2004-05-06T08:24:42Z 2004-05-06T08:24:42Z http://neil.brown.name/blog/20040506082442 <p>The point of this article is to try to describe the approach to developing an application within this editor. <p>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. <p>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. <p><p><a href=http://neil.brown.name/blog/20040506082442>read more...(No comments)</a> 2004-05-06T08:02:30Z 2004-05-06T08:02:30Z http://neil.brown.name/blog/20040506080230 <p><br>Many documents consist of just a single file, that can be read into a single document buffer. However this is not always the case. <p>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. <p><p><a href=http://neil.brown.name/blog/20040506080230>read more...(No comments)</a> 2004-05-03T20:24:54Z 2004-05-03T20:24:54Z http://neil.brown.name/blog/20040503202454 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. <p>UNFINISHED <p><a href=http://neil.brown.name/blog/20040503202454>read more...(No comments)</a> 2004-04-30T14:14:07Z 2004-04-30T14:14:07Z http://neil.brown.name/blog/20040430141407 <p>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 <a href="http://neil.brown.name/blog/Dreams">Dreams</a> link on the right. <p>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. <p>Maybe I will learn from this and not allow &quot;Perfect&quot; to be an enemy of &quot;Good&quot;... <p><p><a href=http://neil.brown.name/blog/20040430141407>(No comments)</a> 2004-04-25T16:35:09Z 2004-04-25T16:35:09Z http://neil.brown.name/blog/20040425163509 <p>In the &quot;what to display - Summary&quot; page I introduced &quot;Display Windows&quot; seemingly out of the blue. I should now develop the idea to make sure that it makes sense. <p><p><a href=http://neil.brown.name/blog/20040425163509>read more...(No comments)</a> 2004-04-25T16:02:07Z 2004-04-25T16:02:07Z http://neil.brown.name/blog/20040425160207 <p>The way my thoughts seem to be going at the moment, where are three general styles of windows which I shall call Navigation windows, Content windows, and Display windows. Their contents are displayed quite differently. <p><p><a href=http://neil.brown.name/blog/20040425160207>read more...(No comments)</a> 2004-04-24T21:24:12Z 2004-04-24T21:24:12Z http://neil.brown.name/blog/20040424212412 <p>When deciding what parts of the document to display, and how, a worthy goal is to endeavor to display as much information as possible. (I actually did my undergrad thesis on this question. I never got working code. Maybe now...). <p>The information content of different parts of the document need to be measuring the context of what the user is currently interested in. i.e. it must be a function of not just the document, but also the cursor. <p>The common approximation is that content near the cursor contains more information than content distant from the cursor, so content near the cursor is display as much as possible (with allowances for stability). <p>For plain text, it is hard to do better than this. However for a more structured document, it is tempting to do a lot more. <p><p><a href=http://neil.brown.name/blog/20040424212412>read more...(No comments)</a> 2004-04-22T11:27:54Z 2004-04-22T11:27:54Z http://neil.brown.name/blog/20040422112754 <p>The question for this article is: What should be included in the displayed window for a particular document? <p>We have a document. We have a current point (cursor) in the document. And we have a display area (window) with certain space characteristics (width, height, DPI) and we want to display part of the document, presumably including the part around the point, making best use of the available space. <p>There are two issues that can guide us. The first is the need for stability in the display : a small change in the document or point should cause a small change in the display. The other is information content : the display should be as informative as possible. <p>These two issues can conflict, so they need to be assessed together. However both a quite substantial issues and so developing them in parallel is not practical. <p>In this article we explore the stability issue assuming a very simple information model. In a later article we might explore information content and then blend the two together. <p><p><a href=http://neil.brown.name/blog/20040422112754>read more...(No comments)</a> 2004-04-15T10:55:08Z 2004-04-15T10:55:08Z http://neil.brown.name/blog/20040415105508 I'm still thinking about document formatting, which is a bit of a diversion from the ultimate editor. But I'll get back there. <p>The language needs to be able to describe what a page looks like, what parts it has, and how content is placed in those parts. It also needs to indicate how overflow content spills onto subsequent pages. <p>Some of the ideas here are inspired by the <a href="http://lout.sourceforge.net">Lout</a> typesetting system - a system that I thought held a lot of promise that for some reason it never quite realised (maybe this system will follow in it's footsteps :-( ) <p><p><a href=http://neil.brown.name/blog/20040415105508>read more...(No comments)</a>