Re: [Help-zile] Next steps

[Gary V. Vaughan]

Hi Reuben,

On May 12, 2014, at 1:59 AM, Reuben Thomas <address@hidden> wrote:
> On 11 May 2014 18:57, Gary V. Vaughan <address@hidden> wrote:
> 
>> Of course, a parallel alien array of cell attributes will still be a good 
>> deal
>> faster than the slew of nested tables I'm currently slinging... Or maybe
>> I'm missing something more elegant by thinking along those lines?
>> 
> I would go with that.

Ack.  And it seems like the easiest way forward too. :)

> In general, the only better idea I've had (and once implemented in the C 
> version of Zee) is to use what I call "lazy ropes", i.e. ropes (as 
> implemented e.g. by the companion libraries to libgc) which are only split 
> when needed. A file can thus be read (or mapped) into a single string, but 
> when part of the file is edited, it's split into lengths of rope, and hence 
> doesn't have to be maintained in a contiguous lump of memory. This slows down 
> navigation but speeds up editing; I suppose that some sort of adaptive 
> remerging of sections that have not been edited for a while might also be 
> good. One might use the generational aspect of a garbage collector for that, 
> without, of course, the actual collection.

Interesting.  I guess this is another thing to work on when we start adding 
alternate buffer algorithms.

> Ropes also seem like a good way to split up a buffer to apply metadata, like 
> highlighting information, with various scopes.

I think I don't (yet) understand the ropes data structure well enough then, 
because I don't see how to store the metadata in the same structures without 
drastically impacting the process of extracting substrings from buffer regions. 
 I'll take a look at C Zee and bug you some more if my head starts to spin :)

> Lazy parsing could work with lazy ropes to keep things fast when you open a 
> big file.

That's definitely on the radar for syntax parsing, at least.

I have one remaining (slightly broken) patch to port forward from the 
topic/syntax-highlighter branch, which recalculates the color tables only while 
awaiting keystrokes (instead of on-demand while drawing buffers in windows).  
But it interferes too much with code shared between Zz and Zemacs (and I don't 
want to sprinkle unused code throughout Zemacs just to support Zz), so I'm 
belaying it until the key handling is properly abstracted.

Now that Zz is my favorite text editor again, it's quite possible that I'll 
feel compelled to do the syntax parser optimizations sooner rather than later 
-- but I'll try to stay focussed on the important supporting background tasks 
first: finish converting legacy Zlisp tests; adding unit tests for the Zile 
modules; defining the interfaces to Zile modules properly so that its possible 
to fiddle with Zz's input loop without impacting Zemacs' input loop etc.

Maybe I should roll up another release first, and announce it on lua-l to try 
and get some more contributors...

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)

signature.asc
Description: Message signed with OpenPGP using GPGMail