Re: tbuf and markers

[Greg Harvey <Greg.Harvey@thezone.net>]

Klaus Schilling <Klaus.Schilling@home.ivm.de> writes:

> G. Harvey-s text buffer module, which is announced in the preliminary project
> list, lacks stuff like markers, text properties, undo, ...
> Is it possible to add those on scheme levele.g. using some object system
> , taking a <tbuf> class, and deriving <tbuf-with-mark> etc. from it?

Actually, I'm mostly abandoning the code that's available now to wait
for goops and reimplement it generically. That being said, it should
be possible to add those bits (though not necessarily with the best
performance) from scheme... regexp matching is probably the best
example of something that should go through scheme to get a consistant
interface with the rest of guile. The only use of the code there now
is for programming text mungers, where text buffers can make life
easier with multiline things (though nothing to really help with
common patterns, like sexps, is in there yet, either). It really
doesn't have editing buffers (or, in fact, buffers consisting of
anything but char's) in mind.

Essentially, what should be provided is a <buffer> class, which does
nothing but handle all the movement functions, insertion and deletion;
from there, you could derive <text-buffer>, <text-display-buffer>, <smob-buffer>
etc... Then you could have something like (pseudo closish code)

(define-method buffer-insert ((<text-undo-buffer> buf))
	(save-undo-state buf)
	(call-next-method buf))

> Or would that annihilate on site all the performance advantage that tbuffers
> give over large strings when it comes to frequent
> insertion/deletion?

It depends on how you do it. There isn't currently a way to get at the
guts of things from scheme; gap positions being the main thing you'd
really need to put something more complex together, though it wouldn't
be hard to make that available with the code that's there. The
essential problem to making the current code more flexible (at least
from c) is that it would require hobbling together a makeshift object
system, which is grossness incarnate.

>  Also, what are the main objections to implementing buffers as port objects? 

They probably could be done that way, though I haven't given it much
thought. 

-- 
Greg