Vscode: Replicate code changes indicators from VS 2015

Created on 23 Apr 2016  路  11Comments  路  Source: microsoft/vscode

Please (partly) replicate VS 2015 code changes indicators. Those indicators are good way to track changes made by 'Replace All', helps to validate recent changes and locate to changes in the file.

change_indicators

In my opinion VS 2015 version is a little bit over engineered. Different colors add little value, difficult to decode and in some cases duplicates other indicators (changed file indicator next to file name)

VS Code might have single indicator, namely "line changed since file was opened".

*out-of-scope ux

Most helpful comment

@bgashler1 thanks for looking into this.

tl;dr: Change indicators are good for smaller changes then one normally includes into git commit.

Ok, will try to give an example. If I want to change the behavior of a class restyle an element in the certain way, I open the file and to achieve desired behavior I know that I need to do X steps; change that, remove this, add that. Before I will go and try to test it I do a little validation/review thing. I look at the lines I've touched and map those to my initial (or final) mental model of the changes required.

Change indicators (VS201X implementation) are good for a single to-do item, while git commit is good for an entire to-do list (bug/feature).

Frankly I didn鈥檛 know that there are those quick diff indicators in place. Since it's in place and people already using it, my suggestion does not have space for existence. Besides, since VS201X indicators implementation is bound to the moment when file was opened in the tab; it may not translate well to vscode; the way one opens a file in vscode is completely different with tabless UI model.

In my opinion current implementation was a couple of rough edges both from UX and ideological points of view.
Tying the indicators to git status creates modes, user have one experience with versioned files and completely another with unversioned. I guess people are having hard times figuring out why in some cases indicators are present and in some not.
Ideologically I'm not sure why editor should know about git at all. Besides, there is a good way to check changes since last commit. >Git: Open Change.

It feels like vscode is dictating how one should work (use git and commit often) and I think that it is not that good for vscode and users.

All 11 comments

Why not with a little diff popup when your mouse goes over?

@charlesmilette because it is good to keep feature requests small. I believe that my suggestion adds value on its own without popup. Sure it can be inflated to something bigger but why? And mouse over does not necessarily means user intent to view more information.

@joaomoreno starting with you. I know we have that for git. May be something the editor can provide out of the box.

Afaik this is not related to git at all.

No. Basically, it is just a little indicator that appears yellow when you change some code, and turns green when you save.

See here for full description.

Currently we show the git quick diff:

  • green for added lines
  • blue for modified lines
  • red triangle for deleted lines

@bgashler1 How could we provide both indicators visually without confusion?

image

Visual Studio line changes when the code is not git versionned, and git line changes when it is?

@quasilatent thanks for your suggestion.

I have some additional questions regarding this to help me understand where you're coming from.

  1. For projects using Git, the _quick diff_ in the editor already offers the ability of seeing what you've modified (blue and green). In what ways is this not meeting your needs?
  2. Are you using Git in the files you are working on where you need to see the modifications?

@bgashler1 thanks for looking into this.

tl;dr: Change indicators are good for smaller changes then one normally includes into git commit.

Ok, will try to give an example. If I want to change the behavior of a class restyle an element in the certain way, I open the file and to achieve desired behavior I know that I need to do X steps; change that, remove this, add that. Before I will go and try to test it I do a little validation/review thing. I look at the lines I've touched and map those to my initial (or final) mental model of the changes required.

Change indicators (VS201X implementation) are good for a single to-do item, while git commit is good for an entire to-do list (bug/feature).

Frankly I didn鈥檛 know that there are those quick diff indicators in place. Since it's in place and people already using it, my suggestion does not have space for existence. Besides, since VS201X indicators implementation is bound to the moment when file was opened in the tab; it may not translate well to vscode; the way one opens a file in vscode is completely different with tabless UI model.

In my opinion current implementation was a couple of rough edges both from UX and ideological points of view.
Tying the indicators to git status creates modes, user have one experience with versioned files and completely another with unversioned. I guess people are having hard times figuring out why in some cases indicators are present and in some not.
Ideologically I'm not sure why editor should know about git at all. Besides, there is a good way to check changes since last commit. >Git: Open Change.

It feels like vscode is dictating how one should work (use git and commit often) and I think that it is not that good for vscode and users.

This seems to be in VSCode now, how do you switch it off?

This feature request will not be considered in the next 6-12 months roadmap and has been closed to keep the number of issues we have to maintain manageable. See also our issue reporting guidelines.

Thanks for your understanding and happy coding!

Was this page helpful?
0 / 5 - 0 ratings