Re: griping about development

[Havoc Pennington <hp redhat com>]

Chris Phelps <chicane reninet com> writes:
> One of the biggest problems right now is the lack of a *really* good
> programming text widget. The new tktext port is certainly superior to
> the old GtkText, but it lacks many things that a good code editor
> needs.

Such as what? The only two I know of are tab support and custom-drawn
margins (breakpoints, line numbers) but these are both planned and can
each be implemented in about 1 day.
 
> Anyway, enough of that...
> 
> What I really mean to say is, Im going to write a new widget using the
> best features/code from tktext, GtkExText, Scintilla, the NEdit text
> widget, and others.

You are on crack. ;-) The new widget in GTK took 3-4 months of work,
split between me and Owen. And it started with the existing Tk
codebase and design. You don't want to go there. Do something useful
with your 3-4 months.

> It will have gutter pixmap support (for debugging purposes), line
> numbers, etc.

1 day task for the widget in GTK.

> It will use GtkBinding for key mapping.

Already done in GTK.

> It will have vertical selections.

1 or 2 day task for the widget in GTK, though I'm not currently
planning to do it myself.

> It will not be based on GtkEditable, so it will not have cut/paste
> problems.

Already done.

> It will be extremely fast.
> It will use much less cpu than any of the current widgets.
> 

The GtkTextView widget in CVS HEAD is fast enough. It also still has
some optimization room if you wanted to hack on it. Moreover the UI
never blocks for a user-perceptible time slice, which makes it appear
to be fast even when it isn't.

You are just going to end up with Yet Another Gapped Text Buffer
Widget, and there are dozens out there, several for GTK and many
others for Qt, etc. that you could port. Look at the one in KWrite for
example, or as you mention the one in NEdit. This is a problem that's
been solved 1000 times and solving it again is Useless (tm). If you
want a gapped text buffer, use one of the GTK widgets, or port NEdit
to GTK, but it's a pointless undertaking IMHO. I considered the
KWrite, NEdit, etc. code while writing GtkTextView.

There are some advantages of a simple gapped buffer widget vs. the
GtkTextView in GTK+ 2.0, yes, but they are not very compelling for
something like an IDE. The main advantage is "easy to implement" but
that isn't relevant since we already implemented things the hard way
for you. ;-) A gapped buffer also uses less memory and _some_
operations are faster, others are much slower. A gapped buffer
probably can't implement incremental reflow easily, without an
auxiliary data structure that wrecks its less-memory advantage, which
means you can't get proper Pango support either.

The only approach that hasn't been tried ad nauseam is a piece table,
as with the AbiWord buffer. I consider skip lists to have been tried,
because they would result in essentially the same widget as the btree
in GtkTextView. But I don't think a piece table would be especially
good for an IDE widget.

Havoc