freenode/#clim - IRC Chatlog
Search
5:50:09
loke
beach: Because creating millions of output record instances up-front when loading a document will take time. Also, when I add, say, a newline to the document, all those output records below needs to have their coordinates updated because they have moved.
5:50:40
loke
Finally, repaint will be slow as well unless one manually manages the output rcord history to quickly be able to find which ones are visible.
5:50:52
beach
loke: I agree with the first part, though I think it is only a matter of a short delay. I don't agree with the other part.
5:51:15
loke
How would you handle the case of adding a newline to a document at the beginning of a file?
5:53:06
loke
a DRAW-TEXT-OUTPUT-RECORD has absolute coordinates in it, doesn't it? It also has over 10 other slots, so it'll use a lot of memory too.
5:53:07
beach
You can even divide the output records into paragraphs if you really want repaint to be fast.
5:53:33
loke
Sure, but what are the benefits of having these output records created, rather than handlign repaint manually?
5:54:13
loke
I have always intended to support having presentations in the document. But these will be created ad-hoc when needed.
5:54:46
loke
Regular text isn't clickable though (a click moves the cursor, but that's not a presentation accaptor :-) )
5:55:32
loke
No no, you have spent much more time than me to think about this. It's obvious that your Climacs implementation works a hellofalot better than what I have muistered so far, so clearly you're doing something right :-)
5:58:40
loke
beach: I'm sorry if I'm coming across as unncessarily conforntational. I was just frutrated by my inability to coerce the output records to do my bidding last night.
5:59:53
beach
No need to apologize. I just think you need to discover the issues by trying out different options.
6:01:30
loke
beach: well, partly it's because it's becoming clear to me that the output records you were talking about are different from the ones I'm thinking. If one defines one's own output record stack, things become very different.
6:02:42
loke
Where were you storing your output recoirds? Did you have a parallel strocture that goes hand-in-hand with the buffer content?
6:03:42
beach
But I keep a copy of the buffer contents (which Cluffer basically requires), and the output records refer to that copy as I recall.
6:06:45
beach
I may have some custom methods on replay-output-record, but it is still the CLIM protocol.
6:07:38
beach
Like for a text editor, if you have ordinary lines that do not overlap and that are kept ordered, you can do a binary search to find which sub-records to replay.
6:09:17
beach
I am convinced that the CLIM protocols are sane and that they allow for this kind of customization.
6:13:00
loke
Oh they definitely are. I did stuff like that in Climaxima when I integrated an interactive graph as an output record ;_0
6:18:05
beach
I remember a bit more what I did now in Second Climacs. Since I concentrate on editing Common Lisp code, I parse the buffer into a hierarchy, using the incremental parsing technique of our ELS paper. Basically, each element of the hierarchy is a Common Lisp expression, so the top-level will be divided into top-level expressions. That hierarchy is then used as the output records.
6:26:00
beach
Also, I don't think I do a binary search, but I take advantage of the locality of most editing operations, so I divide the buffer contents into a prefix and a suffix. In almost all cases, the prefix and suffix stay the same and repaint can traverse only a few expressions at the end of the prefix and at the beginning of the suffix.
8:39:25
beach
Either way, I think the organization of the output records should depend on what in Common Lisp I call the "syntax", which is a generalization of the concept of a "major mode" as it is called in Emacs.
12:51:41
jackdaniel
you know what would be cool? to have a drones-based display and use angular measurement for mcclim units in it! https://twitter.com/MachinePix/status/1184830194323984389 ;-)