Re: GSoC

[Tom Tromey <tom@tromey.com>]

>>>>> "Simon" == Simon Marchi <simon.marchi@polymtl.ca> writes:

Simon> It would be interesting to gather some feedback from those who lead
Simon> this initiative in the past.  Would you suggest trying to go for it
Simon> again?  Why, why not?

I did it in the past but stopped because I wasn't spending enough time
mentoring.  I think it is worth doing but you have to be more organized
and committed than I was.

Simon> On my side, there's the output colouring support which I'd like
Simon> to see become a reality some day :).

I actually did this, but I didn't submit it.  I got sort of mired in
design choices.

The first approach I took was to just hack some color stuff directly the
CLI ui-out, and add a way to "set color <mumble>" (I don't actually
remember exactly how I spelled this, and the branch is long gone).  This
required some hacks to get the column computation to be correct so that
wrapping wouldn't suffer.  I think I just made it so the color string,
whatever it was, was assumed not to take any space -- a hack since this
wasn't actually enforced.

This was a bit too inflexible for me so I abandoned it.


The second approach I took (I still have this branch) was to let the
Python layer insert an object that would replace the CLI ui-out object.
Then colorizing and other reformatting -- the Python ui-out object is
"MI-like" and so had access to more data -- could be done by writing
some Python code.

I liked this approach ok but it needed some hacks (maybe since obsoleted
due to Pedro's recent work, not sure).  Also I think it suffered because
there was no way to get the wrap hints into the Python layer.

And, finally, for something like "set color", there's no good way to
implement completion because there isn't a list of the table- and
column-names.  This could be done by introducing enums or something like
that, but at that point the patch is going to be beyond what I would
want to commit to.

Tom