side bar alignment/instance highlight/right click

The side bar that shows code errors warnings etc is very useful. But it
could be more so.

The warning locations do not seem to line up with the location of the scroll
bar. If I move the scroll bar to overlap a warning line, the code which
contains the warning does not alway appear in the code window. This is
frustrating.

If it was possible to right click on the warning line and have the alt-enter
window pop up so you could fix the issue from there this would be a good
time saving option, for make variable read only or implement members this
would be very useful, and would allow you fix issues without moving away
from where you currently are in the code.

It would also be nice if, as in eclipse, when you had a variable selected
the side bar showed where instances of this variable were in the file
(although this would only be useful if the first issue is fixed), and also
highlight other instances in the code window.

Thanks

Sam


18 comments
Comment actions Permalink

+1 on everything, but most especially the misalignment of the markers. I've bugged the JetBrains folks about this before, but perhaps we can refresh their memories and get them to actually do something about it instead of blaming the problem on the way MSFT implemented the editor window. Note to JetBrains folk who remember this being brought up before: yes, MSFT implemented the editor window behaviour a bit oddly, but it has always been that way and Visual Studio is what YOU are integrating YOUR product with. Make your markers align with the Visual Studio editor window and its scrollbar behaviour. End of story.

0
Comment actions Permalink

Back in the 1.0 days, there was a lot of dicussion about the markers. It
mostly dealt with dealing with folded code issues.

The eventual solution is what you see. The error-strip bar represents the
ENTIRE FILE, with no folded sections. This way you always see the error
stripes correctly (relative to their place in the file) even if the errors
are "hidden" in folded away code, and the stripes aren't constantly moving
all over the place.

The other issue that is confusing is that if you scroll the scroll bar down
to the bottom of the file, there's lots of "white space" there at the end...
the last line of source will be at the TOP of the screen, not at the bottom.
This adds to the perceived "misalignment" even when no code is folded. The
error stripe bar has the last line of stripe-area being associated with the
last line of the file. There isn't any "dead space" at the bottom of the
stripe bar.

Thus you should consider the scroll bar and the stripe bar as independent.
They simply represent different things, and it'd be very, very difficult to
somehow "syncrhonize" them. If you want to scroll to the location of an
error, just click the stripe. I understand the juxtaposition of the two
bars implies an alignment, but there really isn't meant to be one, and
trying to alter things so there is one is very, very difficult, to the
extent it would be possible at all (and trust me, if they did make the
effort, people would be complaining about the dead space at the bottom and
the stripes jumping around all over the place all the time). The alignment
isn't actually necessary for functionality either, so it would be a lot of
effort for very little gain.


"Jeremy Gray" <no_reply@jetbrains.com> wrote in message
news:10012559.26621207334036583.JavaMail.jive@app4.labs.intellij.net...

+1 on everything, but most especially the misalignment of the markers.
I've bugged the JetBrains folks about this before, but perhaps we can
refresh their memories and get them to actually do something about it
instead of blaming the problem on the way MSFT implemented the editor
window. Note to JetBrains folk who remember this being brought up before:
yes, MSFT implemented it that way, but it has always been that way and
Visual Studio is what YOU are integrating YOUR product with. Make your
markers align with the Visual Studio editor window and its scrollbar
behaviour. End of story.


0
Comment actions Permalink

It does take some time to get used to the different scales, but ALT-PgUp/Down makes navigation pretty simple once it is second nature.

The idea of a quick way to highlight usages of an item is good.

0
Comment actions Permalink

Hello,

The idea of a quick way to highlight usages of an item is good.


ReSharper -> Search -> Highlight Usages in File?


Serge Baltic
JetBrains, Inc — http://www.jetbrains.com
“Develop with pleasure!”


0
Comment actions Permalink

Thanks Serge, that useful. An option to automatically do this when an
entire word is selected in the editor and then undo when it is unselected
would, in my opinion, be a useful addition.
"Serge Baltic" <baltic@intellij.net> wrote in message
news:dc0986bfc62b98ca666229d8f922@news.intellij.net...

Hello,

>
>> The idea of a quick way to highlight usages of an item is good.
>

ReSharper -> Search -> Highlight Usages in File?

>

-
Serge Baltic
JetBrains, Inc - http://www.jetbrains.com
"Develop with pleasure!"

>



0
Comment actions Permalink

Hello,

An option to automatically do this when an
entire word is selected in the editor and then undo when it is
unselected would, in my opinion, be a useful addition.


Possibly. But this will make it harder to navigate through the usages — as
you change the selection, the highlighting goes away.


Serge Baltic
JetBrains, Inc — http://www.jetbrains.com
“Develop with pleasure!”


0
Comment actions Permalink

I totally hear you on the behaviour as it pertains to regions, and quite appreciate that the bar shows the entire file as if all regions were expanded (which, as an aside, I always do. I use regions, but I can't stand them collapsed.) That said, the relation of the stripe to the scroll bars is still not consistent, for the precise reason I and others have mentioned repeatedly. You should be able to expand all regions and have everything line up as you scroll. You can't, because R#'s behaviour is in error. Were it not in error, this subject wouldn't keep coming up from time to time.

0
Comment actions Permalink

That has to do with the 'blank space' at the end of the file that Visual
Studio "creates", that is not part of the file, as I outlined in my previous
post.

It's not that Resharper is in error, its that the intuitive expectations
don't match the reality of the implementation. The implementation is fine,
and once you understand the difference, it doesn't bother you any more.
Also, the lack of alignment doesn't affect functionality in any way I'm
aware of either. Just click on the stripe and you're right where you need
to be.

"Jeremy Gray" <no_reply@jetbrains.com> wrote in message
news:29519276.34191207602832485.JavaMail.jive@app4.labs.intellij.net...
>I totally hear you on the behaviour as it pertains to regions, and quite
>appreciate that the bar shows the entire file as if all regions were
>expanded (which, as an aside, I always do. I use regions, but I can't stand
>them collapsed.) That said, the relation of the stripe to the scroll bars
>is still not consistent, for the precise reason I and others have mentioned
>repeatedly. You should be able to expand all regions and have everything
>line up as you scroll. You can't, because R#'s behaviour is in error. Were
>it not in error, this subject wouldn't keep coming up from time to time.

0
Comment actions Permalink

Paul, no offense, but if "the intuitive expectations don't match the reality of the implementation" then the implementation is wrong. When you deliver software to your clients and "the intuitive expectations don't match the reality of the implementation", I bet you sit down with them to improve the software, not argue against their intuitive expectations. The implementation may be fine for you but that doesn't stop it being problematic for a number of people, all of whom you are are quick to shout down simply because they have a higher expectation for the implementation to match the intuitive behaviour.

Why not direct your time and effort towards something more productive than attempting to deny the existence or value of our viewpoints, because the last time I checked we both paid the same amount for the product and deserve the same amount of attention from its vendor. Perhaps there is some other improvement you would like to see made to R#? Perhaps you can start up a thread encouraging JetBrains to make the change you want, and leave us to encourage JetBrains to make the change we want, which in this case is to have the intuitive expectations match the reality of the implementation.

0
Comment actions Permalink

No offense taken, and none meant when I say a LOT of software isn't
immediately intuitive... that's why there is documentation and training.

Once you're told how and why it works as it does, it's not an issue. There
is no missing functionality. Having the stripes aligned with the scrollbar
thumb position doesn't actually gain you much if anything. This is all I'm
saying.

If you can propose a solution that would actually work, go ahead. I know
the JetBrains people have tried different things, and the current solution
is the best one found so far. It USED to try and follow folded regions and
the scroll-bar thumb, and the result was even more confusing. At least now
it's consistent and predictable.

It takes a bit of getting used to, but it's fine once you do. LOTS of
things take "getting used to" in the world of software. I undestand your
view, I went through this same thing years ago, and I'm just trying to help
you get past it and move on in the way I did. Once again, the current
functionality isn't in any way blocking or problematic. It's just a matter
of getting used to the way it actually works rather than assuming it should
work a different way.

I'm just saying this is a battle that has already been fought many times,
and is unlikely to change any time soon, so it's easier to adjust
expectations at this point. I'm not saying you're wrong, I'm helping you
understand that this is something they're aware of, something that was
already heavily discussed years ago, and that the "obvious" solution has its
own challenges and "unintuitive" side-effects that may not be readily
apparant right now.

You're always free to submit a tracker issue on the topic (if there isn't
one already). And if the JetBrains guys come up with a great solution that
pleases everyone (even if it's yet another option that allows you to specify
absolute (current behavior) or relative (behavior you're suggesting) methods
of marking the stripes, so users can choose), nobody would be more happy
than me. I just hope they prioritize performance and other seriously
blocking issues and "real" bugs above it, is all :)


"Jeremy Gray" <no_reply@jetbrains.com> wrote in message
news:31069679.37201207668553817.JavaMail.jive@app4.labs.intellij.net...

Paul, no offense, but if "the intuitive expectations don't match the
reality of the implementation" then the implementation is wrong. When you
deliver software to your clients and "the intuitive expectations don't
match the reality of the implementation", I bet you sit down with them to
improve the software, not argue against their intuitive expectations. The
implementation may be fine for you but that doesn't stop it being
problematic for a number of people, all of whom you are are quick to shout
down simply because they have a higher expectation for the implementation
to match the intuitive behaviour.

>

Why not direct your time and effort towards something more productive than
attempting to deny the existence or value of our viewpoints, because the
last time I checked we both paid the same amount for the product and
deserve the same amount of attention from its vendor. Perhaps there is
some other improvement you would like to see made to R#? Perhaps you can
start up a thread encouraging JetBrains to make the change you want, and
leave us to encourage JetBrains to make the change we want, which in this
case is to have the intuitive expectations match the reality of the
implementation.


0
Comment actions Permalink

Hello Paul and Jeremy,

I think the problem is in the fact that Error Stripe and Scroll Bar are next
to each other :) For example, if Error Stripe always were on the left side
of editor, far from scroll bar, the false impression of their synchronized
state would be eliminated and Error Stripe would always be preceived as "document
map", which is not affected by "view state" like folded regions and extra
scrolling space.


Sincerely,
Ilya Ryzhenkov

JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"


0
Comment actions Permalink

Paul, allow me to be clear: I do know how and why it works as it does, and can certainly function just fine. That said, this feature is obviously still a problem for people, as it keeps getting brought up release after release.

There is room for improvement here, and there is no benefit for the people interested in raising it as an ongoing issue and discussing it to have you come in here and tell them how they should feel about how the software works for them. That it works fine for you doesn't negate the fact that it does not work well enough for others.

Perhaps some day you will feel as we do now, when someone drops by to troll a thread about something you want to see improved about R#. That person won't be me, however, and here's why: I understand that I have different requirements and desires for R# than other people, and am open to seeing it enhanced to fulfill the needs of more than just myself. You might, however, want to step back and think about why that person keeps being you, on threads like this.

This is my last post on this thread, for the simple reason that you are now firmly trolling the thread so there is no point of further discourse with you.

0
Comment actions Permalink

I'm sorry you feel I'm trolling... I assure you I am not. I am simply
trying to help.

See Ilya's post above.

"Jeremy Gray" <no_reply@jetbrains.com> wrote in message
news:17873191.38131207675939996.JavaMail.jive@app4.labs.intellij.net...

Paul, allow me to be clear: I do know how and why it works as it does, and
can certainly function just fine. That said, this feature is obviously
still a problem for people, as it keeps getting brought up release after
release.

>

There is room for improvement here, and there is no benefit for the people
interested in raising it as an ongoing issue and discussing it to have you
come in here and tell them how they should feel about how the software
works for them. That it works fine for you doesn't negate the fact that
it does not work well enough for others.

>

Perhaps some day you will feel as we do now, when someone drops by to
troll a thread about something you want to see improved about R#. That
person won't be me, however, and here's why: I understand that I have
different requirements and desires for R# than other people, and am open
to seeing it enhanced to fulfill the needs of more than just myself. You
might, however, want to step back and think about why that person keeps
being you, on threads like this.

>

This is my last post on this thread, for the simple reason that you are
now firmly trolling the thread so there is no point of further discourse
with you.


0
Comment actions Permalink

Having had the functionality explained and doing some playing with folded
regions I can see why what I wanted is not possible. Folding extends the
size of the scroll bar, but this is not relative to the part of the file
that is folded.

I am now inclined to agree with Paul that the expected functionality is not
possible due to the way the things work, and inclined to agree with Ilya
that it is the proximity of these things that causes the expectation that
they should be syncronised. I assume the reason that this keeps coming up
is that it is not immediately obvious what the reasons that this can't be
done are, and so new people (like I did) keep revisiting this as something
that should be fixed.

Having said all that I still think that with no folding and no blank lines
at the end of a file they should line up, and although it is close they
don't quite. however, knowing that it can never work, this doesn't bother
me any more :)

I don't think that Paul was trolling, simply trying to make it clear why
this can not work. As he said, I'm sure any epiphinies (sp?) on the subject
might change things but, unfortunately, I doubt this will happen.

Lets not let this issue detract from the other 2 suggestions, especially the
'fix from the side bar' one, as I belive this has some mileage.

And lets try not to fall out. Its only work :)

"Paul Bradshaw" <pbradshaw@advsol.com> wrote in message
news:ftgaii$33n$1@is.intellij.net...

I'm sorry you feel I'm trolling... I assure you I am not. I am simply
trying to help.

>

See Ilya's post above.

>

"Jeremy Gray" <no_reply@jetbrains.com> wrote in message
news:17873191.38131207675939996.JavaMail.jive@app4.labs.intellij.net...

>> Paul, allow me to be clear: I do know how and why it works as it does,
>> and can certainly function just fine. That said, this feature is
>> obviously still a problem for people, as it keeps getting brought up
>> release after release.
>>
>> There is room for improvement here, and there is no benefit for the
>> people interested in raising it as an ongoing issue and discussing it to
>> have you come in here and tell them how they should feel about how
>> the software works for them. That it works fine for you doesn't negate
>> the fact that it does not work well enough for others.
>>
>> Perhaps some day you will feel as we do now, when someone drops by to
>> troll a thread about something you want to see improved about R#. That
>> person won't be me, however, and here's why: I understand that I have
>> different requirements and desires for R# than other people, and am open
>> to seeing it enhanced to fulfill the needs of more than just myself. You
>> might, however, want to step back and think about why that person keeps
>> being you, on threads like this.
>>
>> This is my last post on this thread, for the simple reason that you are
>> now firmly trolling the thread so there is no point of further discourse
>> with you.



0
Comment actions Permalink

if you change selection to another instance of the same variable the
highlighting would stay.

I usually use this to check where else I am using a variable visually and so
a simple scroll through is all I would do, thus changing nothing. And this
way the functionality can be accessed from the mouse, without having to
resort to a 2 hands ctrl-shift-f7.

"Serge Baltic" <baltic@intellij.net> wrote in message
news:dc0986bfc64a38ca66f32173bced@news.intellij.net...

Hello,

>
>> An option to automatically do this when an
>> entire word is selected in the editor and then undo when it is
>> unselected would, in my opinion, be a useful addition.
>

Possibly. But this will make it harder to navigate through the usages - as
you change the selection, the highlighting goes away.

>

-
Serge Baltic
JetBrains, Inc - http://www.jetbrains.com
"Develop with pleasure!"

>



0
Comment actions Permalink

I'm really struggling to understand how people can accept that this can't or shouldn't be done.  Eclipse has folding, and a similar side bar.  Folded regions cause markers to disappear; this is an entirely consistent and intuitive behaviour that I imagine most users don't particularly notice.  VS has the stupid feature that it lets you scroll down to see lots of whitespace at the end of a file; that should simply mean that there will always be a blank section at the bottom of the error stripe until such a time as VS is fixed.

Were there any other issues that I've missed?  Those two don't seem enough to prevent fixing the problem.

I don't know who invented this idea originally, but I can't believe anyone who used both would think the R# implementation is more usable than that of Eclipse; especially if, like me, they came from Eclipse originally.  I would imagine that a significant number of R# customers are Eclipse users who are looking to get similar features for C# in VS.  The problem is not "that the Error Stripe and the Scroll Bar are next to each other"; moving them apart may reduce the tendency to think that they should be linked, but that would be a regression in the design.  Their proximity is a clear expression of the design metaphor behind this feature and that is why people expect it to behave in a certain way; it augments an existing very familiar concept of representation of space in the document rather than forcing a new one to be introduced.  As mentioned previously, the solution to usability issues is certainly not to force the user to read more documentation, even if the user is a programmer.

Regards,
Peter

0
Comment actions Permalink

Like Sam, Jeremy, and Peter, I have long been surprised/irritated at the apparent mis-alignment of the markers.  I think this is not merely aesthetic, but affects the function of the product.  Perhaps moving the error stripe somewhere else would reduce complaints about the problem, but it would also be a lost opportunity for better function.

I agree that it must be reasonably easy to account for the weird virtual whitespace at the end of the file using blank space in the error stripe.

The code folding issue is more complicated but not unmanageable.  Because I use Highlight Usages in File to find ALL usages, I would NOT want markers in folded regions to disappear.  Nor would I want compile errors to be folded away.  There is already functionality to collapse multiple markers down to one marker line, sometimes by segmenting the marker, sometimes by just overlapping them. (I don't understand when one approach vs. the other is used and would love an explanation!)  Using this feature, all markers in the folded region should be shown next to the single line of text representing the folded region, with the following precedence for showing overlapping markers:

Highlight Usage "Declaration"
Highlight Usage "Assignment"
Highlight Usage "Usage"

Compile error

Inspection "Show as error"
To-do Item "Bug"
To-do Item "Not Implemented"

Inspection "Show as warning"
To-do Item "To-do"

Inspection "Show as suggestion"
To-do Item "Note"


For Highlight Usages in File I would like it if declaration could have a different color from assignment.  In the case where both are on one line, use a segmented indicator, or give declaration precedence over assignment.

Also the colors used for notes/todos/etc are applied only in the To-do Explorer, and should be used consistently in the text editor as well, both in the error stripe and in the text itself.

I love this product, and cannot live without it!

0
Comment actions Permalink

It's occured to me that another favourite utility, BeyondCompare, does actually have a somewhat similar 'document map' type thing, which is displayed separately from the scroll bar(s) and which I have found to be imminently usable.

See the white rectangle to the left of the two panes in this screenshot:
http://www.scootersoftware.com/images/TextCompare1.jpg
In that case, their case seems a little more complex, but the solution they came up with is still usable.  This is because they have clear visual feedback about what the current viewable portion of the document is, along with reasonably intuitive interaction.

Simple visual feedback about how the current view related to the error stripe would make all the difference to the usability of the R# control, in my view.  The misalignment would probably hardly even matter with this feedback, regardless of wether it was in close proximity to the scroll bar or not.

0

Please sign in to leave a comment.