feat: Include query text in history hover

[aeisenberg]

Include the text of the query file when hovering. For quick eval, only
show the selected text.

Long files are truncated in the hover. It looks like vscode limits tooltips to only a few hundred chars.

Not sure if showing the text for all queries makes sense. The other option is to only show expanded tooltips for quick eval.

[aeisenberg]

Closes #264

[adityasharad]

Thought: instead of showing it in the tooltip, could we have a right-click menu command for 'Show original query text', that displays the query text (at the time the query was run) in a temporary editor window? I imagine most query text is going to be too large to usefully view in tooltips (and they are not the most accessible part of the UI).
We would need to take some care to distinguish in the UI (and docs) between 'this is the query exactly at the time you ran it' vs 'this is the same query file you ran, but you may have changed it since it was run'.

[aeisenberg]

Certainly something I can try, though it would be hard to visually distinguish the historical query text from a regular file.

I have another idea. We could show the query text in the results view itself. It could be placed in a text area that is hidden by default and there is a button somewhere that shows and hide it.

[aeisenberg]

And perhaps, for quick eval (which tend to be shorter queries) we can still keep the text in the tooltip. And we can also show query text in the results view.

(we can include a disclaimer that this was the text when the query ran, but it may not coincide with the current text of the query file)

[jcreedcmu]

In the current version, I'm not getting any hovertext for quick eval; I think showing the token being eval'ed would be useful to store, or having some mechanism to jump back to it.

[aeisenberg]

I think showing the token being eval'ed would be useful to store,

Definitely

or having some mechanism to jump back to it.

Well, can't jump back to something if it no longer exists. We can only show it in an isolated, synthetic location.

[aeisenberg]

On a deeper look, I think that @adityasharad 's idea of opening the query text in an editor is probably the best way to go. Vscode has a good API for creating read-only virtual documents. And we can stuff the contents in there. We can also possibly get syntax highlighting for free.

[jcreedcmu]

When I test what I believe to be its current state, this PR still includes full query text in the case of regular queries, which I'm not sure I'm convinced is a good idea, and doesn't seem to have any extra information in the case of quick-eval, which doesn't justify closing #264. Am I doing something wrong?

[aeisenberg]

Yes, I kept the full text in for regular queries. Not sure if this works or not. Probably not necessary any more now that you can access the full text elsewhere.

As for extra information on quick eval. What extra information are you thinking of? The full context of the evaluation?

[aeisenberg]

OK...I removed the query text on hover. Now, the hover behaviour is as it was. The way to see query text is to right click and select "Show Query Text" in the history actions. This will show the text of the file (or the selected quick eval text) in a read-only editor.

[aeisenberg]

In terms of extra context that we store for quick eval queries. I'm not finding it in vscode objects. Can you point me to where it can be found?

[adityasharad]

Perhaps just the position:

vscode-codeql/extensions/ql-vscode/src/run-queries.ts

Line 58 in 21500f0

public readonly quickEvalPosition?: messages.Position,

or right next to where you added the quick-eval text in this PR.

[aeisenberg]

From @jcreedcmu's comment earlier, I had assumed that the extra context describes the implicit bindings and types of the variables used in the query. The text position of the query is already available in the default hover on the history item.

Though, maybe I'm misunderstanding what's being asked for and what's available.

[jcreedcmu]

Given that we have the position, we could extract the text at the time of querying and store that somewhere --- or store the location, and have a mechanism for jumping to that location from the context menu of the stored query, or something? I think we can tag treeview items with tags and condition what's in the context menu based on them.

[aeisenberg]

That's mostly what this PR does. It adds a new context menu. Though, it's true that we could change the "Open Query" command so that it selects the text in the query (though this would be incorrect if the underlying text changes). It seems like this change would be part of a different PR, though.

Let's discuss on slack what exactly should be included here and what I should do for later.

[aeisenberg]

Thanks for the approval @jcreedcmu. There was a misunderstanding on my part. It turns out that you can run a quick eval query by simply placing the caret in a particular location (with a selection length of 0). In this case, the query text being shown was an empty string.

In this situation, I made the change so that the entire line is shown, which I think is a reasonable compromise.

Ideally, we could reach into the query server and get detailed access about the quick eval query (eg- bound variables) but that is a task for another time.