Re: GSoC
Tom Tromey <[email protected]>
| Newsgroups | gmane.comp.gdb.devel |
|---|---|
| Message-ID | <[email protected]> |
>>>>> "Simon" == Simon Marchi <[email protected]> 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