Why not using GtkSourceView?

[Sébastien Wilmet]

Hello,

I'm interested to know why Bluefish doesn't use GtkSourceView. I've
written this wiki page:
https://wiki.gnome.org/Projects/GtkSourceView/PainPoints

So the reasons that I see:
- Bluefish has a different implementation for the syntax highlighting
engine (plus completion system), described here:
http://oli4444.wordpress.com/2010/08/14/bluefish-editor-widget-design/

- Bluefish predates GtkSourceView, so the features like undo/redo,
margins/gutters (line numbers, marks, …) were probably already
implemented in Bluefish.

By using GtkSourceView, you would have less code to maintain in
Bluefish. You would just not use the syntax highlighting provided by
GtkSourceView, but the other features can be used. So is it just because
of a lack of time to port Bluefish, or are there other reasons?

Btw, the syntax highlighting engine of Bluefish looks very interesting.
It could be merged to GtkSourceView (as another implementation of the
GtkSourceEngine interface). And some utility classes or a common
framework could be shared between the two implementations.
(Unfortunately the current implementation in GtkSourceView is one big
class. A branch exists to split the highlighter out of the engine, but
the work was not finished).

Regards,
Sébastien

[Olivier Sessink]

Post by Sébastien Wilmet
Hello,
I'm interested to know why Bluefish doesn't use GtkSourceView. I've
https://wiki.gnome.org/Projects/GtkSourceView/PainPoints
- Bluefish has a different implementation for the syntax highlighting
http://oli4444.wordpress.com/2010/08/14/bluefish-editor-widget-design/

part of you question is already answered in this post ;-)

Post by Sébastien Wilmet
- Bluefish predates GtkSourceView, so the features like undo/redo,
margins/gutters (line numbers, marks, …) were probably already
implemented in Bluefish.
By using GtkSourceView, you would have less code to maintain in
Bluefish. You would just not use the syntax highlighting provided by
GtkSourceView, but the other features can be used. So is it just because
of a lack of time to port Bluefish, or are there other reasons?

Indeed many of the features are already present in Bluefish for a long
time. Sometimes even a bit more advanced (Bluefish for example can undo
in multiple documents if you did a search+replace over multiple documents).

Another reason: the editor widget pretty much defines an editor. At
leats the last time I did a good comparison (that might be a year ago)
GtkSourceView did not have the completion features that Bluefish has,
and not the context-aware in-line spell checking. But perhaps times have
changed?

Post by Sébastien Wilmet
Btw, the syntax highlighting engine of Bluefish looks very interesting.
It could be merged to GtkSourceView (as another implementation of the
GtkSourceEngine interface). And some utility classes or a common
framework could be shared between the two implementations.
(Unfortunately the current implementation in GtkSourceView is one big
class. A branch exists to split the highlighter out of the engine, but
the work was not finished).

The engine in Bluefish also has one major drawback for object oriented
languages: it can never do something like this:

var = myclass();
var.now_complete_this_function_correctly(

because the DFA table is static, it does not know which type var has,
and thus it cannot present the correct methods...

Olivier

[Sébastien Wilmet]

Post by Olivier Sessink
Indeed many of the features are already present in Bluefish for a long
time. Sometimes even a bit more advanced (Bluefish for example can undo
in multiple documents if you did a search+replace over multiple documents).

Yes, GtkSourceView works on an individual file/buffer, it is not aware
of multiple documents. And the UndoManager doesn't know the underlying
action behind a text insertion/deletion (does it come from a search and
replace, or modifying directly the text in the buffer, etc).

Post by Olivier Sessink
Another reason: the editor widget pretty much defines an editor. At
leats the last time I did a good comparison (that might be a year ago)
GtkSourceView did not have the completion features that Bluefish has,
and not the context-aware in-line spell checking. But perhaps times have
changed?

GtkSourceView has a completion framework, completion providers can be
implemented externally. A provider exists in GtkSourceView to complete
simple words present in a GtkTextBuffer. But unlike Bluefish, the syntax
highlighting engine doesn't provide completion proposals depending on
the context.

For the spell checking, GtkSourceView know which regions should be spell
checked, and which regions should not. When describing the syntax of a
language, context classes can be attached to a context. There are
currently three context classes: comment, string, no-spell-check (and
custom classes can be created). With functions in GtkSourceBuffer, you
can thus know if a GtkTextIter is inside a comment, etc.

For the in-line spell checking itself, GtkSpell can be used, but
unfortunately it depends only on GtkTextView, not GtkSourceView, so the
no-spell-check context class is not used.

Post by Olivier Sessink
The engine in Bluefish also has one major drawback for object oriented
var = myclass();
var.now_complete_this_function_correctly(
because the DFA table is static, it does not know which type var has,
and thus it cannot present the correct methods...

The compiler can provide tools for a text editor. For example Clang
provides a tool for the completion of C/C++. Or tools for code
refactoring.

For the syntax highlighting a scanner should be sufficient (or a little
more powerful). For other features, a full parser is needed (that is, a
context-free grammar), and also a context-sensitive analysis (to know
the type of each variable).

--
Sébastien

[Olivier Sessink]

Post by Sébastien Wilmet

Post by Olivier Sessink
The engine in Bluefish also has one major drawback for object oriented
var = myclass();
var.now_complete_this_function_correctly(
because the DFA table is static, it does not know which type var has,
and thus it cannot present the correct methods...

The compiler can provide tools for a text editor. For example Clang
provides a tool for the completion of C/C++. Or tools for code
refactoring.
For the syntax highlighting a scanner should be sufficient (or a little
more powerful). For other features, a full parser is needed (that is, a
context-free grammar), and also a context-sensitive analysis (to know
the type of each variable).

I know this is possible with clang, but clang cannot do php or
javascript, or python... I've been thinkin how to create a generic (for
all languages) option for auto completion of OO-languages, but this will
require a complete rewrite of the syntax scanner. And at the moment I
don't think anybody in the Bluefish team has the time to work on that.

Olivier