[MonoDevelop] Scintilla over GtkSourceView

Ben Maurer 05mauben@hawken.edu
Thu, 29 Jan 2004 12:13:26 -0500

(Todd, please approve this to the list...)

Yes, I realize that we will have to abstract many things. Basically, there =
are two paths we take for different issues:

1) Push it back to gtksourceview
I want to do this for features that you would see in any editor. Like =
smart indenting, Folding strategies, highlighters, markers, etc. GtkSourceV=
Iew can allow us to provide the data we need. For items like folding, this =
gives you guys 100% freedom in the editor -- we wont have to backport to =
MD. For items like extra markers, we have to be careful to provide a =
platform neutral binding.

2) Keep it in MD
A great example here is code templates. Also, code generation goes here =
too. We have to implement these inside c# because they cannot be generalize=
d to the C widget. To maintain portability, it is critical that we use =
implementation neutral code. That means no references to IDocument, for =
example; because our binding will not have that. I would be happy to work =
with you guys to make an API that allows us to easily swap in either impl.

On linux, we are clearly going with sourceview. From the beta version, it =
feels much more natural than the custom buffer. I cannot begin to list the =
ways in which this is true. Lets take the small things -- the syntax =
highlighting in gedit and MD is the same. This is great, because i love =
gedit, and it helps me as a user to not have a weird switch between the =
two impls. Secondly, I am able to use the middle mouse button to copy and =
paste text via the X server. This is important to many old-school =

For this reason, it is pretty critical that we allow the editor to be =
pluggable. Not so much so that a person can switch in VIM at will, but so =
that we can share code MD <-> SD.

I would note that the code is actually getting smaller by making the =
editor wrapper.

-- Ben

>>> Mike Krueger <mike@icsharpcode.net> 01/28/04 14:18 PM >>>

Don't make it TOO easy ... if you want to make an abstract editor=20
wrapper you'll need to wrap >many<
#Develop was desinged not just beeing a C# IDE (which was the top=20
priority however) but instead it should be a platform
for 'any' language and people should be able to easily integrate their=20
own languages ... MonoDevelop will go down the same
road right ?
In this case keep in mind that MD will be >extensible< at many >points<.=20=

Language bindings should contain their own
editor stuff like:
+ Smart Indenting
+ Folding strategies
+ Custom highlighters and markers (IDEA does do this quite good ... for=20
C# a better highlighting would be good)

Therefore it is better to support just ONE editor ... this simplifies=20
much and there is NO point to write a 'wrapper'
which is as big as a editor on it's own :) and the editor should be=20
configurable through the 'options' therefore each
editor needs the same set of options (that is almost never the case) or=20
bring it's own options pane... which may
be rather annoying for the user. And one philosophy of the add-in tree=20
based approach is :


Switching the editor might be fun for some people (there are some =
out there which requested the vim editor for #D)
but for the most programmers this feature is not useful and it adds too=20
much uneccessary problems to the code ... try to
make clean, small code and think as a 'user' of the tool when adding=20
functionality and try to think a bit in the future.


>Ben is working as part of this new editor, a common binding assembly
>that implements all the menu items/dialogs that you expect from a source
>buffer. This will mean that if someone decides to write a new editor
>(mmmmm, vim binding anyone?) you will have a common set of Interfaces to
>inherit and handle to get it embedded into MD, and your find will look
>like the find people expect irrespective of your source buffer of
>On Wed, 2004-01-28 at 11:07, Marco Canini wrote:
> =20
>>Here's my suggestion:
>>don't preclude any way!
>>In eclipse the editor is not one, there's a collection of editors and
>>they implement a common interface.
>>I don't think there would be too much penalty in doing it so also in MD.
>>So you can use sourceview, scintilla, maybe a vim binding, etc...
>>What do you think?
>>On Wed, 2004-01-28 at 16:01, Ben Maurer wrote:
>>   =20
>>>I actually use SciTE for my editor right now :-).
>>>Folding is in the plans for SourceView, so I would rather push this =
>>>rely on Scintilla.
>>>The problem with Scintilla is that it is not very well integrated with
>>>GNOME. The idea here is to make an editor that, as I stated on my blog,
>>>feels as native to Linux as VS.net does on Windows.
>>>If I wanted 5000 editor features, we would be binding vim or emacs,
>>>anyways :-).
>>>If someone *really* wants folding, I am sure the gtksourceview team
>>>would love and be happy to check in any patch. Ditto for any other
>>>-- Ben
>>>On Wed, 2004-01-28 at 09:47, Mike Krueger wrote:
>>>     =20
>>>>One advantage of Scintilla is that it HAS folding and many other=20
>>>>features and it could be used inside #Develop too (GtkSourceView would
>>>>be a step backward for the windows version) this will enhance the =
>>>>compatibility of #Develop and MonoDevelop if we choose to do
>>>>it this way. I don't know if you have seen this:=20
>>>>http://sourceforge.net/projects/scide/ this is the beginning of a=20
>>>>wrapper for scintilla ... I don't know
>>>>if there are more out there.
>>>>       =20
>>>>>I read the text buffer is going to be migrated to GtkSourceView =
>>>>>scalability and usability. I have been using Anjuta(based on=20
>>>>>scintilla) for a few months, it supports code folding and auto=20
>>>>>complete features. I would like to suggest using Scintilla over=20
>>>>>GtkSourceView, so we can gain the new functionality without writing =
>>>>>much code.
>>>>>         =20
>>>>Monodevelop-list mailing list
>>>>       =20
>>>Monodevelop-list mailing list
>>>     =20
> =20