[MonoDevelop] Why MonoDevelop doesn't use GtkTextView/GtkSourceView?

[Mike Krüger]

Hi
> On Sat, Aug 23, 2014 at 03:41:45PM +0200, Mike Krüger wrote:
>> The search & replace idea was taken from us - therefore it's a bad example
>> :).
> Not the new search and replace API in GtkSourceView. Completely
> different UIs and behaviors are possible with the API.
Years to late for us.
>> Code folding is always possible to implement to a degree. But implementing
>> like we did would require to change text lay outing (we're drawing folding
>> markers as part of the layout) and background drawing - see the animations.
> Images or anchor widgets can be added to a GtkTextBuffer. Custom drawing
> is also possible below or above the text. Or it can be achieved simply
> with text tags.
The interesting case is to let the text flow around the fold marker.

line1[FOLDED]line10
>> GtkSourceView is nice - I do not have complains about that but it doesn't
>> solve our problem.
> Some features are common to each text editor or IDE: undo/redo, file
> loading and saving, margin/gutter (line numbers, marks, …), printing,
> search and replace, etc.
>
> GtkSourceView should be flexible enough for every text editor or IDE. If
> some features are not suitable for a certain application, then
> GtkSourceView should be improved (and bugs and feature requests should
> be filed on bugzilla).
undo/redo - depends on how it's implemented it's true - but we need to 
access the undo stack to draw the file changed state in the line number 
magin.
Some are not really easy - esp. loading - we've to use a custom encoding 
detector to be able to detect the most common VS.NET encodings. We used 
the gtk routine before but that didn't work for us.
Another common feature is cut & paste - but I need to go deeply into 
that mechanism - we're using a custom clipboard format that contains 
context where the code was copied from. That's useful for supporting 
automatic string conversions when pasting from/to strings.
It's very hard to bring all this kind of flexibility into a common API.

Recently I reworked our editor API - that's why I know that this is very 
hard to do.

>>> Is snapshotting different than a point in the undo/redo list? Or the
>>> text buffer saved to a temporary file?
>> Yes it is because it should be a O(1) operation that brings the whole text
>> representation in an immutable state so that it can be used by background
>> threads.
> Interesting. What is usually done in GtkSourceView is to execute the
> background work on small chunks of text in an idle. The remaining region
> of text to analyze is maintained in a data structure. When an insertion
> or deletion occurs in the text buffer, the region is updated
> accordingly.
>
> Do you have an example of a feature that uses a snapshot?
Background parsing for example does that. Auto save is another. 
Generally IDE's are doing heavy background analysis these days.
>> We've really many features that are hard to implement in a general purpose
>> editor  - if it's not supported like our virtual indentation spaces. And now
>> it's too late anyways - our text editor is now mature enough after 7 years
>> of development.
> Yes, it's too late for MonoDevelop. But it is maybe still the time for
> other IDEs. And I prefer if GtkTextView and GtkSourceView are improved
> instead of reinventing the wheel.
>
Editors got reinvented more than twice - btw. other IDEs may use 
Mono.TextEditor as well :).
btw. we may even choose to implement another front end for other UI 
libraries. I agree that reinventing the text editor isn't great - doing 
a text editor is a very huge task - but I do not see a real way around 
that because there are too many using scenarios.

- But - we can share data structure ideas / maybe even test suites and 
so on.
> What is the virtual indentation spaces?
That's like smart indenting unlike it doesn't add the indent to the text.
> In summary, if you still remember how GtkTextView works, what should be
> improved or changed in GtkTextView?
It has been ~7 years last time I looked at it. Everything I knew about 
it may not be true anymore.
But having a default folding implementation would be a good start for 
IDE use.
>> (And as said - we've been using GtkSourceView before that and felt it was
>> too limited for our use case at that time - 7 years ago - I think that the
>> GtkSourceView has evolved a lot since then. But atm I don't really see any
>> reason for switching back.
>>
>> Can you give one ? (The maintainance work isn't much right now - most of the
>> ongoing editor work is implementing new features or changing old ones)
> I think all the features of GtkSourceView are already implemented in
> MonoDevelop. Maybe the search and replace works better in GtkSourceView
> (including regex search), I don't know. Last time that I've used
> MonoDevelop to test the search and replace, I've found a few bugs. Maybe
> GtkSourceView has fewer bugs, since it is used by more applications and
> tested in more different use cases. The GtkSourceView API is also well
> documented.

The GtkSourceView search&replace was implemented with taking our 
implementation as example/concept.
I remember that I did something wrong in the implementation - but it 
works well for me.

Regards
Mike