Codecov Report

❗️ No coverage uploaded for pull request base (master@9b9a90a). Click here to learn what that means.
The diff coverage is 14.08%.

@@           Coverage Diff            @@
##             master   #2017   +/-   ##
========================================
  Coverage          ?   38.7%           
========================================
  Files             ?     423           
  Lines             ?   17940           
  Branches          ?    2451           
========================================
  Hits              ?    6944           
  Misses            ?   10444           
  Partials          ?     552

I'm excited so see this going in! 😃

Workflow wise, now I have the option to view using Open Conversation, the next most likely action I'll want to preform is Edit in Browser.

I'd almost be inclined to replace the Open in Browser option with an Edit in Browser option (that starts editing the MD - if such a thing is possible). Is there a URL for that?

For some reason I keep heading to the Open in Browser link at the bottom, rather than the Open Conversation link. @donokuda are users more likely to click the top/bottom commands on a menu? Or is it just me? 😉

Having links to individual commits is great! Could we make the text clickable as well, like on dotcom?

Once nice thing is, once you've drilled down to a file diff, you have to option to Open File in Solution and navigate to the change of interest (assuming it still exists).

I wonder how difficult would be to leverage a read-only Visual Studio editor component for syntax highlighting? Is markdig easily customization like this?

Maybe @jaredpar would give us a sanity check/tips on how to create a read-only editor component like this? 🙏

It would be nice if we could get links wired up to the Open from GitHub command, so the user can navigate to lines/ranges in the local solution!

I think this kind of integration is where we can add value when viewing PRs/issues inside Visual Studio.

Something I really miss is emoji support. Could we have a button or even just a reminder to click Windows Key + . to bring up the Windows 10 emoji picker? 😜

Maybe @jaredpar would give us a sanity check/tips on how to create a read-only editor component like this

Not quite sure what you were looking for advice on here. Could you elaborate?

@jaredpar,

Not quite sure what you were looking for advice on here. Could you elaborate?

I remembered you wrote the https://github.com/jaredpar/EditorUtils library for hosting the Visual Studio editor outside of VS. What I'm wondering about here is a potentially simpler scenario (hosting it inside VS).

At the moment we're using Markdig for rendering .md content inside Visual Studio. Unfortunately it doesn't have built in syntax highlighting.

I was wondering how feasible it would be to create a read-only WPF editor control with syntax highlighting, that corresponds to a markdown code block? We could then render any code blocks in pull request/issue in a similar way to Visual Studio. The highlighting and color themes would be the same as Visual Studio so it wouldn't look out of place.

Is this realistic or do you think there are performance/complexity issues that are likely to bite us?

What I'm wondering about here is a potentially simpler scenario (hosting it inside VS).

Yes that is feasible. Within VS the editor is just there. You can grab all of the factory interfaces from the MEF container and just create the IWpfTextView instances directly.

@meaghanlewis yes, this is definitely a feature we should have! I did look into implementing it a while ago, but never finished it. It would involve writing a markdig extension, which shouldn't be too difficult; would just require the time to be allocated to it.

One thing I noticed while testing. I'm not sure what the correct functionality should be here, Don says he expected to open the browser, I expected it to open the Detail page.

Floating this idea:

If I click on a link, I'd mostly expect the page that the action took place to update instead of something on the side. However, I probably expect that since the page itself looks and feels like closer to a webpage.

We could consider doing both: navigate the conversation view to the corresponding pull request and also navigate the GitHub panel to show the details view with relevant information to the PR.

There are a few risks that I anticipate (which we would want to consider validating with some folks): 😬

1. When I'm focusing on a specific pull request, it's confusing to have the panel navigate without me interacting with it. If I'm not aware that the panel has updated, I might be disoriented or accidentally read irrelevant information.
2. It's not clear how to get back to the previous screen in the pane. (The solution here would be to use the navigation bar above, so this would mostly be testing if that functionality is discoverable.)
3. People don't expect the conversation page to change. 👈I doubt this is a problem, but I also understand that my hunch could be wrong.

I am leaning towards navigating both the conversation page and the GitHub panel to the pull request, but I'm open to feedback in case I'm missing something. 😄

@donokuda I've been thinking about how I use the current View on GitHub link. I pretty much always use it after creating a PR to edit the markdown description and to add images. This is something the current conversation view doesn't allow and it would take a lot effort to get feature parity with dotcom. I think this is a pretty important use-case/workflow.

How about rather than replacing or combining the View on GitHub / View Conversation functionality, we keep the View on GitHub link and take inspiration from the comments icon on the dotcom PR list.

I link showing the number of comments gives people an incentive and invites them to click. It would also be clear that clicking on the comment link would show those comments.

I think we've always been pretty explicit about when a command will open an external browser (for both menus and links). I'd be hesitant to introduce a command that both opens an external browser and does an action inside Visual Studio.

In fact we should have a common command/keyboard shortcut to Open on GitHub no matter the context (if we don't already). 🤔

@jcansdale 👍 Sure, let's try that idea out! 😄

My only concern is if the text isn't blue (like the links around it), then folks might assume they cannot interact with it (and that it's only informational.)

Would you be open to making it a blue link?

@donokuda,

Would you be open to making it a blue link?

Absolutely! The main thing was the comment icon/number of comments. I copy/pasted from dotcom. 😉

@StanleyGoldman,

One thing I noticed while testing. I'm not sure what the correct functionality should be here, Don says he expected to open the browser, I expected it to open the Detail page.

Is this the link you're referring to above?

I'd expect the # link on the conversation view to open in a browser, just like the link in the the notification does on the left. In fact, could we include the owner/repo in the conversation view link as well to add a little more context?