[MonoDevelop] Fatwa: bring the XCode error/warning reporting to MonoDevelop.

[Michael Hutchinson]

On Thu, Oct 15, 2009 at 8:50 PM, Miguel de Icaza
<miguel.de.icaza at gmail.com> wrote:
>> * The wrap/ellipsise behaviour in Xcode is complex. Sometimes Xcode
>> wraps the message onto the *next* line (that still has text on it, and
>> Xcode has a rendering bug when you type on that line), sometimes it
>> wraps it onto a "new" line, sometimes it ellipsises, sometimes a
>> mixture. Tuning this behaviour could be difficult.
>
> This is merely an overlay computed at the time the bubble is created, or
> when the editor is resized.   It does not need to live or share the same
> text-o-space than the actual text is.   I believe this is the source of your
> concern.

In my experimentation it seemed that sometimes Xcode created a blank
line in the editor space for the bubble. Maybe I was wrong.

>> * There needs to be some kind of logic for deciding when to hide the
>> bubbles (maybe a short while after the line or an adjacent line has
>> been altered) or they will stick around and get in the way. Of course,
>> the aforementioned menu could be used to bring them back.
>
> Simple issue.

Finding/tuning a good behaviour is not necessarily "simple".

> I never get the error pad and think to myself "Let us look at all the
> possible errors and pick the one I want to fix first".   When you are
> developing, all you care about is hitting the next one.   We can keep it
> around for log or diagostic purposes, but with bubbles, it becomes
> effectively useless.   I have yet to use that in XCode, ever.

Well, *I* like to be able to skim the list of errors first to get an
idea of what was broken. Things can be more complicated, for example,
when autogenerated code is involved, and you sometimes need to get the
big picture to see what's happened.

Xcode does not keep the error list for "diagnostic purposes". It's
simply in a separate window, which is Xcode's closest equivalent to a
pad. Users may not choose to use it most of the time, and that's fine,
but there will always be circumstances when it's useful.

>> * How should bubble rendering interact with breakpoint markers or the
>> current line highlight marker?
>
> Side by side.

That doesn't work. Breakpoints are rendered across the full line, not
just in the margin.

>> * Does the purpose of bubbles conflict with the squiggly underlines
>> for on-the-fly syntax errors? Should we still use squiggly underlines
>> for all on-the-fly errors (e.g. spelling, syntax, etc) and save
>> bubbles for compile-time errors?
>
> Yes.

Yes to which question? The latter?

>> * We've discussed getting rid of the status bar, or making it more
>> subtle (like Google Chrome's popup status bar) since it's currently
>> mostly redundant and wastes space. Will adding more things
>> (warning/error counts) to the status bar make the problem worse by
>> making it harder to get rid of the status bar, or solve that problem
>> by making it less redundant?
>
> They can still be contextual.   They only show up after a build, and remain
> there until some other significant event.
>
>> * VS also doesn't pop up the build/error pads unless the build fails -
>> it simply shows the build progress in the status bar - and people have
>> been asking for MD to copy this for a while.
>
> That is a good idea while we kill it

You have yet to explain why we should "kill" it. Xcode still has one
for a reason.

If we get this right, we will make users happier. If we are too
disruptive without considering the consequences, we will lose users.
Don't forget that users come from different perspectives, and emacs
and Xcode users like yourself are a tiny minority compared to those
who are familiar with other IDEs, especially VS. Blithely dismissing
these other viewpoints is incredibly counterproductive. We should be
discussing how we can make it more usable for everyone.

-- 
Michael Hutchinson
http://mjhutchinson.com