[MonoDevelop] Managed Line Editor

[Matej Urbas]

On Mon, 2006-10-30 at 02:35 +0100, Lluis Sanchez wrote:
> 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.

I doubt simple regex is a solution for such things. I think sometimes
you just need context aware algorithms. What about embedded SQL? Or code
documentation?

> 
> > 
> >   - 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.

Aye. So, no need to worry about that. Just make features easily usable.
I understand.

> 
> > 
> >   - 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.

Ok. I will first investigate a little on how other editors do things (to
avoid bad design decisions).

> 
> > 
> > > 
> > > 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
>