-
Notifications
You must be signed in to change notification settings - Fork 190
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add compare view #431
Add compare view #431
Conversation
To compare text files, you right click on one, select “Select for Compare”, then right click on another and select “Compare with Selected”. We should probably use the same approach to invoke our diffs. |
fcdbaa6
to
0531e4d
Compare
@dbartol I never even knew that feature existed until you mentioned it here. I could try to do something similar. I'd like to first get the basic feature in and then work on ways to improve and fill it out completely. The way I generally do compare is to select two files, right-click -> compare. |
Hah, I didn't realize that multiselect worked for compare. Apparently, VSCode allows all three ways of doing compare: Related: Apparently multiselect in a TreeView is supported now, so we could do any or all of the three above. I agree that multiselect is the most natural. |
I've been having a hell of a time getting the second style to work. It's making me think that there may be a problem with vscode (or at the very least my understanding of vscode). I raised this issue: microsoft/vscode#99767 |
e976db6
to
ee8663b
Compare
The reason why there are so many commits right now is that I rebased on top of #437. When that change gets merged, this one should shrink. |
@@ -277,10 +301,10 @@ export class QueryHistoryManager { | |||
constructor( | |||
ctx: ExtensionContext, | |||
private queryHistoryConfigListener: QueryHistoryConfig, | |||
selectedCallback?: (item: CompletedQuery) => Promise<void> | |||
private selectedCallback: (item: CompletedQuery) => Promise<void>, | |||
private doCompareCallback: (from: CompletedQuery, to: CompletedQuery) => Promise<void>, | |||
) { | |||
this.ctx = ctx; |
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.
any reason not to replace this.ctx = ctx
with an argument list field declaration also?
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.
Makes sense. Must have missed that one.
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.
Actually...don't need it to be a class property at all. removed the field.
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.
Mostly looks good, I especially like the refactoring-out of result-related components, which would have been a fine idea even apart from needing to reuse them as you do here.
beforeText: /^(\t|[ ])*[ ]\*[^/]*\*\/\s*$/, | ||
action: { indentAction: IndentAction.None, removeText: 1 } | ||
} | ||
const onEnterRules: string[] = [ |
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.
Why are these commented out?
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.
That's a mistake.
@@ -274,6 +286,14 @@ class ResultTable extends React.Component<ResultTableProps, {}> { | |||
{...this.props} resultSet={resultSet} />; | |||
case 'SarifResultSet': return <PathTable | |||
{...this.props} resultSet={resultSet} />; | |||
default: |
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.
This default
shouldn't be necessary; the type ResultSet
constraints resultSet.t
to be either RawResultSet
or SarifResultSet
, and the lack of default
makes typescript's exhaustivity checking a useful signal. Unless perhaps you see some way that we're likely to break type safety and want an informative error message here?
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.
In which case I'd prefer something slightly more verbose like Invalid result set type
, but not knowing anything else, I still think the default
doesn't belong here at all.
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.
Will remove.
t: 'setComparisons', | ||
stats: { | ||
fromQuery: { | ||
// since we split the description into several rows |
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.
It's not clear to me that the user-defined label case works well here. When I set the label of the query-being-compared to to [%t] custom
, what I see is just the query file name and not the string 'custom' appear anywhere in the view.
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.
Hmmm...let me see.
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.
Ugh...silly mistake. Fixed now.
* @throws Error when: | ||
* 1. number of columns do not match | ||
* 2. If either query is empty | ||
* 3. If the queries are 100% disjoint |
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.
When I do a comparison of disjoint queries, the comparison view is forced visible, and I do get an error message saying the results are disjoint, but the comparison view still contains whichever comparison it did before, which I think is slightly misleading. I think I'd prefer --- but would be happy deferring to a follow-up PR if this is at all complicated --- having one of the possible states of the comparison view actually being "results disjoint" as opposed to window.showErrorMessage
.
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.
Hmm...right. I should fix that.
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.
There are a few other error states. What I will do is ensure that the compare view will hide the columns and display the error message in this case.
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.
Yeah, that sounds great.
Adds the tsx file and updates the webpack config so that this new tsx file is properly compiled.
This is in preparation for creating a new webview, extract shared functionality to the webview-utils file
This module will behave like the interface.ts module and handle interactions between the compare webview and the extension.
Also, some moving around of functions and whitespace changes.
ee8663b
to
735226c
Compare
@dbartol about different ways to invoke comparison, I tend to agree with you that the most natural to me is select the two things and then invoke comparison --- but I think it's fine to get this PR in and then add that functionality afterwards, since multiselect brings a couple other complications with it. Showing an appropriate error message when any commands (including those other than comparison) are invoked with an inappropriate number of items selected is the main one that comes to mind. |
* The error message will be displayed instead of the empty results tables. * Also, uncomment onEnterRules. That should never have been committed. * Also, extract CompareTable to its own component.
Looking good --- just one more suggestion, in |
Avoids an issue when one table has many more rows than the other and the tables are off-centered.
Ping @github/product-docs-dsp! This is a fairly large change. I can describe here how it will work, or we can sync up over zoom. Up to you. Edit: I see you're already tracking this at: https://github.com/github/semmle-docs/issues/160 |
Thanks @aeisenberg, exciting update! Feel free to drop any information into the docs issue if you want, though we'll also let you know if we need more help when we get round to documentation 😃 |
This PR adds the compare view. See #394.
To compare 2 queries:
Fixes #394
Checklist
@github/product-docs-dsp
has been cc'd in all issues for UI or other user-facing changes made by this pull request.