[MonoDevelop] Managed Line Editor

[Lluis Sanchez]

El dg 29 de 10 del 2006 a les 21:51 +0100, en/na Matej Urbas va
escriure:
> On Sun, 2006-10-29 at 20:16 +0000, Michael Hutchinson wrote:
> > On 10/29/06, Matej Urbas <matej.urbas at gmail.com> wrote:
> > > Create a source editor with GTK# and Pango? Take a look at how
> > > SharpDevelop's, NetBeans' or Eclipse's (my favourite) editors manage
> > > things? Better integrate parsers with editors?
> > 
> > The only major issue you *might* have with a managed editor is
> > performance -- I think the #D guys had some trouble there IIRC -- but
> > there are plenty of advantages. You could even port #D's editor
> > directly from its current SWF to GTK#/Cairo/Pango, though I think that
> > MD's architecture has diverged quite a bit in that area. If you
> > implement the interfaces in MonoDevelop.Ide.Gui.Content, then most of
> > the existing text editing features should work fine. The #D book
> > (which is now free) might have some stuff about how they wrote the
> > editor. I remember seeing an interesting document a couple of years
> > back about how they'd designed it.
> 
> Yes, performance should not be a stopping factor (well, it isn't for NB
> or Eclipse - both of which have their editors written in Java).
> 
> Porting SD's editor or maybe producing a feature compatible one is what
> I'm after.
> 
> > 
> > I don't know how useful integrating the editor with the parser would
> > be -- what ideas do you have in that area? I would more be thinking
> > about ease of adding code folding, error underlining, line
> > modification indication, complicated syntax highlighting schemes...
> 
> When talking about a tighter integration with a parser,  I was thinking
> more about the editor to be more aware of the language it is displaying.

It doesn't sound like a good approach to me. A text editor should focus
on text editing, and provide enough formatting features so that an upper
layer of functionality can implement custom behavior for specific
languages.

> for example:
> 
>   - on the fly syntax checking (printing out syntax problems - like
> eclipse does - or VS 2005)

Regarding this feature, the editor should only provide a way of
highlighting incorrect source code. VS does it by underlining that code
as spelling errors (GtkSourceView also support this kind of
underlining). The decision about what to underline does not belong to
the editor.

> 
>   - more dynamic and context aware syntax highlighting (the 'value'
> keyword in Setters - C#)

I wonder if the regex used to highlighting C# could be improved to
support this.

> 
>   - context aware indentation engines (empty lines with indentation -
> VS.NET behaviour, code auto-styling engines - VS.NET 2005)

We already support smart indentation. Adding more complex modes should
be possible.

> 
>   - context aware code completion engines (expected types - useful in
> 'new' expressions)

Well, we already support code completion of types and members. Adding
support for code completion in other contexts is just a matter of using
the parser information we already have.

> 
>   - auto-refactoring (the same as VS.NET 2005 - when changing names of
> variables, types or methods...)

Again, this doesn't need to be supported by the editor. The language
add-in can get information about the position of each member, track
changes in the text editor, and start a refactoring operation when it
detects that a member name has changed.

> 
>   - you name it :-)

Things we cannot do with the current editor that would be possible to
implement with a managed editor:
* Code folding (although I think it could be implement with the latest
version of GtkSourceView.
* Code underlining with different colors.
* Correct detection of words boundaries (navigation with control+cursor
and selection with double-click doesn't always work as you would expect
for a source code editor).
* Selection and manipulation of text boxes, so we can for example copy
or delete columns of text.

> 
> I've got the impression that all of these features need some kind of
> very tightly integrated (and smart) engine - an engine that knows the
> language very well and also knows how to work with the editor...

Not really. What we need is a an editor with good formatting features,
and a language engine able to take advantage of it.

> 
> > 
> > Fully managed text buffers would alse be useful for having more than
> > one active view of a buffer, for split panes or different editor
> > interfaces.
> > 
> 
> I was planning to look into SD, Eclipse and NetBeans (their code
> actually) and only take the best design ideas from them.
> 
> I have a very vague idea on how source editors work... And already see,
> that I will progress only slowly on this front...
> 
> Any help is very very much appreciated.
> 
> Enjoy
> ---
> Matej
> 
> _______________________________________________
> Monodevelop-list mailing list
> Monodevelop-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/monodevelop-list