Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upAllow user to toggle inline comment margin #1568
Conversation
08ca4e2
to
acb8a94
This option controls InlineCommentMargin visibility.
Move implementation out of GlyphMargin.
No need to pass IWpfTextViewHost. Renamed marginVisual to marginGrid.
We're only really interested in the TextView.
Moved async initialization out of CommentsMarginViewModel.
Show the PR file name on margin.
They are now part of the checkbox lable.
113f67a
to
37963f6
We only need live updates is the margin is actually visible, not simply if it is enabled.
Increment NumberOfPullRequestFileMarginToggleInlineCommentMargin when checkbox is toggled. Increment NumberOfPullRequestFileMarginViewChanges when view changes/comments is clicked.
This allows navigation from View Changes in Solution to Code View. It also allows navigation from the default Team Explorer changes diff view (Compare with Unmodified...) to code view.
Add metric for navigating from editable diff (e.g. `View Changes in Solution`) to code view.
Add metric for number of times ExecuteGoToSolutionOrPullRequestFileCommand is executed.
Move NumberOfPRDetailsNavigateToEditor next to related metrics and comment that it should be renamed to NumberOfNavigateToEditor.
|
Hey @jcansdale here are a few things I noticed today:
This is a bit more vague, but I've noticed that some metrics aren't incrementing regularly for: |
Good point. It doesn't locate you on the comment, it simply navigates to show changes in the PR (that happens to have x number of comments). The use can then view an already open comment or navigate to the next/previous comment. Maybe, |
|
A few comments on the code, but this looks good for a beta feature. I find the toggle control slightly confusing at the moment, but I understand that this feature needs iterating on, so lets discuss that elsewhere. |
| // HACK: We need to wait here for the inline comment tags to initialize so we can find the next inline comment. | ||
| // There must be a better way of doing this. | ||
| await Task.Delay(1500); | ||
| RaiseWhenAvailable(Guids.CommandSetString, PkgCmdIDList.NextInlineCommentId, param); |
This comment has been minimized.
This comment has been minimized.
grokys
May 15, 2018
Contributor
I thought this hack was no longer necessary with DifferenceViewerOptions.ScrollToFirstDiffId?
This comment has been minimized.
This comment has been minimized.
jcansdale
May 15, 2018
Author
Collaborator
So did I! NextInlineCommentId depends on the comment margin tags having been updated in order to navigate to the next comment. Before the tags have been refreshed, this command is unavailable and it would crash when attempting to execute the command.
We should attempt to fix this in another PR.
| { | ||
| [Export(typeof(EditorOptionDefinition))] | ||
| [Name(OptionName)] | ||
| public class InlineCommentMarginEnabled : ViewOptionDefinition<bool> |
This comment has been minimized.
This comment has been minimized.
grokys
May 15, 2018
Contributor
I've never used this API, so I'm missing something here, but the only thing that seems to be used from this class is OptionName. Do we need to create a subclass of ViewOptionDefinition if we only use the name? Why not use an instance of this class as they key when getting options?
This comment has been minimized.
This comment has been minimized.
jcansdale
May 15, 2018
•
Author
Collaborator
By exporting ViewOptionDefinition we declare than a new options exists on the text views (and give it a default value). I probably shouldn't be using OptionName directly and should be importing the option and using the Key property. This gives us type information for the property.
I've changed OptionName to private and am using Key in the latest commit.
| @@ -118,7 +118,8 @@ | |||
| Text="{Binding Body, UpdateSourceTrigger=PropertyChanged}" | |||
| TextWrapping="Wrap" | |||
| VerticalAlignment="Center" | |||
| GotFocus="ReplyPlaceholder_GotFocus"> | |||
| GotFocus="ReplyPlaceholder_GotFocus" | |||
| SpellCheck.IsEnabled="True"> | |||
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
jcansdale
May 15, 2018
Author
Collaborator
Well, there will be. I didn't try to sneak this one in, seriusly! ;-)
| namespace GitHub.Commands | ||
| { | ||
| [Export(typeof(IGoToSolutionOrPullRequestFileCommand))] | ||
| public class GoToSolutionOrPullRequestFileCommand : VsCommand, IGoToSolutionOrPullRequestFileCommand |
This comment has been minimized.
This comment has been minimized.
grokys
May 15, 2018
Contributor
Could we have a comment here (and on the interface) as it's not totally clear from the class name what this command will do.
This comment has been minimized.
This comment has been minimized.
jcansdale
May 15, 2018
Author
Collaborator
Done. I hope it make sense. Let me know if it isn't clear.
Thanks for the heads up! I don't understand why this is happening. |
The When you execute |
|
@jcansdale it's still hard for me to understand what |
|
Also, @sguthals and I were noticing that when enabling or disabling the feature flag, that a file (or files) need to be closed and reopened to actually see the options to toggle the inline comment margin. This is probably to be expected, and I'm sure users won't just be toggling the flag often, but just wanted to bring it up. |
I think the confusion might be that it's a per-editor view setting, not a global show comments in the margin for all file setting. It is triggered when you click on the check box (when the horizontal margin is visible). I made it that way because the horizontal margin is constructed per-editor view. It might make more sense for it to be a global show the editor margin setting. The checkbox would remain set when moving between PR files and executing
Yes, that is by design. To make it dynamic, the margin would need to be loaded but hidden. I've made it so the switch completely disables this functionality. I got bitten by this once before when hidden functionality was causing issues. |





jcansdale commentedMar 28, 2018
•
edited
What this PR does
New horizontal editor margin is hidden behind feature flag
Adds a margin to the editor window
Clicking on checkbox (or filename/comment bubble) toggles the comment margin
Clicking on
view x commentsnavigates to PR file changesIf there are no PR file comments it will show
view changesIf there are no PR file changes the margin won't appear
Right clicking on solution file with active PR branch shows
View Changes in # PRbuttonRight clicking a diff view opened using

View Changes in Solutionslows the optionOpen File in Code View. This will open the diff pane in a new code view.Team Explorer - ChangesactionCompare with Unmodified...Clicking
View Changes in # PRnavigates to equivalent line on PR diff viewClicking
View Changes in # PRon file without changes in PR shows warning on status barMetrics
NumberOfPullRequestFileMarginToggleInlineCommentMargin- When the user toggles the checkbox to show/hide comment marginNumberOfPullRequestFileMarginViewChanges- When user clicks on view changes/view comments linkNumberOfNavigateToPullRequestFileDiff- When user navigates from editor to PR file diff via theGitHub.GoToSolutionOrPRFilecommandNumberOfPRDetailsNavigateToEditor- When user navigates from PR file diff to editor via theGitHub.GoToSolutionOrPRFilecommand (NOTE: this counter existed before)ExecuteToggleInlineCommentMarginCommand- When theGitHub.ToggleInlineCommentMargincommand is executed (via the checkbox or executing command directly)Technical notes
DifferenceViewerOptions.ScrollToFirstDiffIdglobal option will be temporarily set tofalse(see #1631). This lets me immediately set the equivalent caret position when navigating to the the diff view.Todo
Open File in Code ViewactionsGoToSolutionOrPullRequestFileCommandView Fileshow the comment marginIssues
Initial thoughts
My initial impression is that this UI element would be a great opportunity to surface other important information about the current PR. For example:
Lots of opportunities to show things there would be useful to the user and make this UI element more discoverable (e.g. showing the PR number would be handy for navigation and give context to the comment bubble).
Related UI
People will rarely see the following UI. They need to be using an Enterprise/Professional version of VS and be editing a non-source file. This is when editing our
GitHub.VisualStudio.vsctfile:When the user clicks on one of the sections, a bubble pops up with a scrollable list of sub-items with an automatic preview of each.
We could do a similar thing, except with a list of inline comments in the file and a preview of each comment. When the user clicks on the comment they're interested it, it would navigate to the inline comment in the source.
Similarly we could have a list of PR review comments, with a preview and navigation to the
GitHubPR review UI.Lastly when the user clicks on the PR number, there could be a list of changed files in the PR and the number of inline comments they have displayed. Clicking in the file would navigate to the PR file diff or editor.
This would give context for the comment margin toggle switch (which I think is too minimal/subtle at the moment).
Tackle in another PR (#1671)
View File(margin appears but no commentsView Changes in SolutionFixes #1565