-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Allow user to toggle inline comment margin #1568
Conversation
This toggles the GlyphMargin on and off. It will be changed to toggle the comments margin.
08ca4e2 to
acb8a94
Compare
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
Compare
We don't want live taggers running and monitoring live files when margin isn't visible.
Only monitor live file when InlineCommentMarginEnabled.
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, |
grokys
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought this hack was no longer necessary with DifferenceViewerOptions.ScrollToFirstDiffId?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So did I! 😢 It seems there's another issue where the 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> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
| VerticalAlignment="Center" | ||
| GotFocus="ReplyPlaceholder_GotFocus"> | ||
| GotFocus="ReplyPlaceholder_GotFocus" | ||
| SpellCheck.IsEnabled="True"> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wasn't there another PR with this feature?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done. I hope it make sense. Let me know if it isn't clear.
By using Key we can take advantage of the option's type information.
No need to go through IGitHubServiceProvider.
Use InlineCommentTextViewOptions for typed editor option keys.
Thanks for the heads up! I don't understand why this is happening. 😕 I'll investigate more tomorrow. |
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. |





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 Find best way to open diff view without scrolling to first diff #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 comments 😕)View Changes in SolutionFixes #1565