[MonoDevelop] Impossible to see my cursor.

[Lluis Sanchez Gual]

A solution is to temporarily highlight the current line after a jump.
This used to work in the past.

El dc 14 de 10 de 2009 a les 00:33 -0400, en/na Michael Hutchinson va
escriure:
> On Tue, Oct 13, 2009 at 6:48 PM, Miguel de Icaza
> <miguel.de.icaza at gmail.com> wrote:
> >     When I press Go-to-next-error in MonoDevelop, I always have to move my
> > cursor left and right to see the cursor, otherwise I do not know where I am.
> >     We need to have a better mechanism to highlight the line we have
> > selected, there are a few options:
> > * Visual Studio selects the offending region using the selection mechanism
> > (so C-x cuts the text for example) and puts a squiggly underline
> > * XCode highlights the entire line, puts a error flag on the left column
> > (indicating the error or warning line) and puts the text in a small cute
> > font on the right
> 
> The specific problem here is that when using the errors list to jump
> to error locations, it's not immediately obvious where in the text
> editor the caret is. I don't have this problem myself, since I like to
> have the current line highlight enabled, but I can see how it could be
> a big issue for people who don't use that, especially with large
> monitors.
> 
> The inline highlighting/marking of the compiler errors and warnings
> would certainly help in this specific case, but the problem of finding
> the cursor after jumping is much more general. You can just as easily
> lose the cursor if you jump using the search pad, or symbol navigation
> commands like go-to-definition or go-to-base, or the navigate
> forward/back commands, or even if you just switch editor tabs. For
> this reason I would propose that we add a small animation to "pulse"
> the caret whenever the editor caret position "jumps" as the result of
> an IDE operation. This should be straightforward using Mike's new
> animation code. We could also trivially add a keybindable text editor
> command to pulse the caret, which I'm sure would be useful for some
> users.
> 
> To get an idea of how VS and Xcode handle these problems I've
> summarized what they do:
> 
> Visual Studio 2008
> * go-to-error with the error pad sometimes highlights the offending
> item, and sometimes just places the caret
> * go-to-definition just places the caret
> * on-the-fly errors are highlighted with red squiggle, compile errors
> are highlighted with a blue squiggle, compile warnings are highlighted
> with a green squiggle. All have tooltips with details.
> 
> Xcode:
> * go-to-definition selects the entire target line
> * compile errors have an icon in the gutter/margin, and paints the
> entire line with a highlight, with the details painted in an arrow on
> the far right.
> 
> I'm not a fan of the Xcode error markers - I think they're too
> intrusive, and painting the description inline wastes editor width. I
> also don't think it makes sense to select text at the jump target
> unless the user actually would want a selection. Fortunately it would
> be very straightforward to add different-coloured squiggles for
> different error/warning types - I did this for HTML/XML
> errors/warnings already.
> 
> For these reasons, I suggest we add the caret pulse on jump, caret
> pulse command, and blue/green error/warning underlines for compiler
> errors.
>