Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Pull Request conversation view #2017
Work in progress for attn of @donokuda.
Progress so far
I'm excited so see this going in!
Workflow wise, now I have the option to view using
I'd almost be inclined to replace the
For some reason I keep heading to the
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
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
I think this kind of integration is where we can add value when viewing PRs/issues inside Visual Studio.
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?
@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.
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):
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
How about rather than replacing or combining the
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
Is this the link you're referring to above?
I'd expect the