GtkSourceView pain points

Or why some applications don't use GtkSourceView. Of course the goal is to address those pain points in the long term, or at least be aware of the issues.

Anjuta

Anjuta already uses GtkSourceView, but Scintilla can be used too.

The main reasons that Anjuta still keep Scintilla support:

• With the code architecture of Anjuta, having both GtkSourceView and Scintilla makes sure that Anjuta stays independent of the editor implementation.

• code folding: but it is not critically needed for the Anjuta developers.

• rectangular selection: would be really useful. The multi-line edit plugin for gedit can already do rectangular selections.

• multi-line edit: a gedit plugin exists.

• less important, Scintilla highlights project symbols (e.g. already defined functions). It would be nice if GtkSourceView could highlight a custom list of words.

For more info, read this discussion on the anjuta-devel-list.

Bluefish

Bluefish uses GtkTextView, but not GtkSourceView.

• Bluefish has a different syntax highlighting engine (including an integration of completion results depending on the context). Read this blog post. The editor widget pretty much defines an editor.

• Many of the features are already present in Bluefish for a long time. Bluefish predates GtkSourceView.

• Some of the features in Bluefish are more advanced, for example undo in multiple documents if you did a search+replace over multiple documents.

For more info, read this discussion on the bluefish-dev mailing list.

MonoDevelop

MonoDevelop/Xamarin Studio used at some point GtkSourceView but they have written a new text editor framework in C#/.NET (so even GtkTextView was not suitable for them). The main reasons:

• They don't like the C language Using a C-based API in C# is not convenient.

• They have a multi-threaded architecture. The GtkTextView API can be accessed only by the main thread.

• text buffer snapshot: O(1) operation, so that the snapshot can be used by background threads, e.g. for auto-save, retrieve completion proposals, doing other parsing required for other IDE features.

• virtual indentation spaces: like smart indenting unlike it doesn't add the indentation to the text. Can maybe be implemented with GtkTextView by adding the indentation to the text, but with a tag. The text editor should then behave as if the virtual spaces didn't exist. For the file saving for example, the indentation contained in the tag can be removed. Related: elastic tabstops for gedit. Virtual spaces can be used also for alignment, e.g. to align columns in a CSV file.

For more info, read this discussion on the monodevelop-list.