This is the mail archive of the guile@cygnus.com mailing list for the guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: text buffers


Greg Harvey <Greg.Harvey@thezone.net>  writes...
>
>"Marisha Ray & Neil Jerram" <mpriz@dircon.co.uk> writes:
>
>> Greg Harvey <Greg.Harvey@thezone.net> writes...
>>
>> >"Marisha Ray & Neil Jerram" <mpriz@dircon.co.uk> writes:
>> >
>> >> I've also been wondering about implementing buffers, and have a few
more
>> >> questions that I'd like to throw into the stream.
>> >> 1. What is wrong with simply porting the existing buffer code in Emacs
>> and
>> >> giving it a SCM interface?
>> >
>> >Quite a bit ;) A lot of the code in emacs is mostly unnecesssary for
>> >buffers that are, essentially, just places to put big chunks of data,
>> >where you can move around easily and munge at will. Plus, there's that
>> >whole mule/multibyte thing (bleah!).
>>
>> Aha!  (I'm writing this email backwards, if that helps make sense of my
>> comments.)  Do you mean that you are thinking of a buffer as a typeless
>> byte-stream sort of thing, that is mostly written at its end and read
>> starting from the beginning?
>
>Not quite: basically, I'm thinking of it as a very convenient way to
>munge a chunk of text (or bytes), which is usually much easier to do
>using a buffer, rather than the typical line by line method of things
>like perl or awk. To use an example, I wrote a little elisp program to
>extract function&macro definitions from the qdocs I'd written. All it
>had to do was find a line that contained the right tag (like
>Function:), then do a forward-foo (where foo was a movement function
>that would go to the end of the definition)... it didn't have to worry
>about keeping track of newlines or any of that crud; it just moved
>forward over what I wanted it to. Compared to using a typical text
>groking language, this is a big win (the extraction function is only
>10 lines long, and it's easy to insert new actions for different types;
>I plan on rewritting it to use the guile buffers as soon as I have a
>scheme interface written, and adding the ability to translate the
>simple format of the qdocs into texinfo).

OK, I see.


>> >> 2. Should Guile's buffers be designed to be more general than text
>> buffers,
>> >> i.e. to be buffers (ordered sequences) of arbitrary SCM objects?
(Think
>> >> music, rich text, whatever... )
>> >
>> >It may be useful. Essentially, a buffer doesn't have a clue what's in
>> >it, and it's up to the programmer to decide how to treat it, so having
>> >buffers that can hold any arbitrary thing might be a bit of overkill.
>>
>> I suppose I'm begging the question "when is a buffer not a buffer?"  How
>> does a buffer differ from a list of objects?  Both have fast insert and
>> delete operations - what else characterises a buffer?  This is probably
>> obvious to you, but not yet clear to me.
>
>Well, we don't have to mark a buffer of bytes. This is mostly a
>question of how to represent the buffer (and whether to allow
>non-uniform buffers, which sort of makes my brain hurt after the
>adventure I had writing the logic for simple buffers ;). I can see
>some ways to make it possible (at least for uniform objects), though
>I'd like to have actual working text buffers before breaking them :)


Fair enough.  As far as the implementation of non-uniform buffers is
concerned, though, I'm not sure that it's only a problem of representation.
When I was thinking about this, I couldn't work out how to move from Emacs'
hole-based text buffers to non-uniform buffers without losing performance.

>> >> 3. I assume that we want to also support overlays / intervals / "text"
>> >> properties.  Correct?
>> >
>> >I don't think there's any real purpose. As far as I can see, those are
>> >strictly for the display of the text, and since we aren't going to be
>> >actually displaying the text, we don't care what it looks like.
>>
>> Why do you say that we aren't going to be displaying the buffer?  It
seems
>> like this is something that someone will want to do very soon after a
>> non-displaying buffer implementation becomes available.
>
>Well, partly because I'm implementing buffers for my own selfish
>reasons (and, I want to have a library usable from c, as well as
>guile), and partly because I want the basic text/byte type buffers
>finished yesterday ;). Some redesign will likely be necessary, but for
>now, I really want something that can be used. Any lowlevel changes
>shouldn't affect the scheme view of things, so I don't think it's too
>limiting to concentrate on on a strictly text buffer, for now.
>
>However, when using buffers for simple (or even complex) text munging
>from scheme, it's wasteful to have all the trimmings, which would
>never be used; a better approach is to write a display (or editor)
>buffer, which uses a text buffer (or scm buffer, or note
>buffer... btw, I'd really love a mod tracker in guile, so I could
>finally get around to writing the garbage collector segfault song ;)
>object for the contents, and implements all the display and editing
>logic. It might require a little synchronization between the two (for
>markers and such, you'll have to figure out how far text actually
>moved at any given time), but has the benefit of leaving all the
>display stuff up to someone who actually has a clue how to do it ;).


(Garbage collector segfault song???  I don't understand!)  I'm not sure that
would be a good approach to implementing a display buffer - think, assuming
that the text buffer is not an object that can be extended by inheritance,
of all the buffer-manipulation wrapper functions you'd need to copy basic
text buffer functionality to the display buffer.  I think a better idea is
to add hooks to the text buffer that are meaningful (and defined) in the
text buffer's own terms but also happen to be what is needed to implement
display.

>> I should explain a bit more where I'm coming from, which mainly concerns
>> Emacs.  Two Emacs-related observations are that (i) Emacs includes a lot
of
>> functionality that is generally useful to other applications, e.g.
buffers,
>> input management, keymaps, window management; (ii) people are starting to
>> write free software applications, such as gIDE, that include their own
>> homegrown internal editors.  At the same time, two actual happenings: (i)
>> the slow push to replace the Emacs Lisp engine with guile, and (ii) we
are
>> discussing the implementation of text buffers for guile.
>>
>> So, maybe this is a bit too cathedral-ish, but it seems to me that the
>> obviously desirable endpoint is an unbundled Emacs, where (i) different
>> parts of Emacs' functionality, e.g. buffers, are implemented as guile
>> modules, such that they are available both to Emacs and other
applications;
>> (ii) "Emacs" is actually guile + guile modules + small amount of
application
>> code needed to connect everything together; (iii) Emacs as a whole can be
>> embedded within another application, and provides much more support for
>> communication with controlling/peer external processes, perhaps through a
>> generic guile IPC feature (so that the gIDE authors wouldn't need to
write
>> their own internal editor, they could use Emacs).
>>
>> OK, reading this back it sounds laughably futuristic, but I hope that my
>> point is clear.  That in an ideal GNU world, there would only be one
>> implementation of text buffers.  It would be written in C/Guile, and both
>> Emacs and other applications would use its services.
>
>A lot of this is probably better achieved through corba or somesuch
>(though I guess that's a little bit of heresy, given that guile is
>supposed to natively translate all languages under the sun), but the
>general idea is a very good one (though you could really get a lot of
>people screaming bloat by imbedding emacs ;). However, I do think that
>a text buffer has one job to do, and it should do it well. That it
>could also be used by an editor object is just a big plus :)

Sure, but CORBA is just a way of advertising your interface for someone
else's use; the functionality still has to be implemented somehow, such as
in guile.

Thanks for considering my ideas.  A non-display text buffer implementation
is a lot better than nothing, and a good place from which to start exploring
what could then be built on top of it - best wishes!

    Neil