Change:
{ key: 'editor/lineNumber/context', id: MenuId.EditorLineNumberContext, <del> description: localize('editorLineNumberContext', "The contributed editor line number context menu"), proposed: 'contribEditorLineNumberMenu' </del> <ins> description: localize('editorLineNumberContext', "The contributed editor line number context menu") </ins> }, { key: 'mergeEditor/result/title',

Discussion:
Re: Currently clicking on a line number in the editor selects the whole line, but right clicking on it does not show a context menu. To mirror the behavior that GitHub offers for generating deeplinks to a line in a file, we'd like to introduce a context menu attached to line numbers in an editor, like so: <img width="512" alt="image" src="https://user-"This new proposed menu should integrate well with the existing menus that appear in the editor gutter. We currently have the breakpoint editor contribution, which shows a menu of breakpoint actions on a right click in the editor gutter. Additionally, when test decorations are rendered, we show both breakpoint actions as well as testing actions. There is already a menu ID for the gutter when a testing decoration is rendered, , which accepts contributions from extensions. This is the behavior I'm currently looking to implement: If line numbers are enabled: Context menu for should contain actions for: Test Debug Copy If line numbers are disabled: Context menu for should contain actions for: Test Debug Reasoning: it doesn't seem like a natural interaction to want Share actions from the gutter if line numbers are turned off In other words, I plan to contribute actions to both and , and the when clause for the Copy contributions to the latter menu would be . (It's a little odd to have copy actions contributed to so I wonder if we could rename to and pull in any contributions to for backwards compatibility, cc
I think this is the way to go
Feedback from API sync: Overall idea seems fine Unsure whether this should be named or Context object is currently , perhaps it should be Unsure if each contrib's link implementation should hide itself when line numbers are disabled, arguably line numbers are a visual thing and I still want the copy actions. May be confusing, waiting for additional feedback
Hi, First of all, thank you for starting this API proposal. It will be really useful for some extensions I was able to play with it, and TBH, seems fairly simple to use. But, unless I'm missing something, the clause seems limited for this API. I mean, similar to how works, I would like to only display or menus if the current line has or not bookmarks. It doesn't seems possible today. I see two different approaches. An event to be fired prior to the context menu to be shown.

So, in this event, I could call with the that the event should pass as parameter, evaluating if the line has bookmarks. And it would be used as regular clauses The API also provides a context. So, I could use and conditional operators, evaluating with the list of bookmarks that the current file has, like: Am I missing something here, some additional documentation for this proposal that I should look for, or is this scenario still not covered? Thank you
Yeah I would assume you'd need to use the conditionals. This does kind of beg for another type of when clause to actually be an indexer. So that you could use the as an index into an array or object/map in another context value. That way you could access the value of that lookup to make further conditionals without having to create many other mapping calls. Maybe something that would be more possible with the new when clause parser.
What value would provide over just the number? Wouldn't the column value always be 0? Also I think being a position would make the usage of impossible (since I don't think you could access the line property)
Right now, it only provides and . Something like: That's the reason why I suggested the / conditional operators as an alternative
In fact, I didn't remember there was and conditional operators, up until the moment I noticed it wouldn't be possible to do what I need without something else. Then I navigated to the API documentation, in order to look for alternatives, and there it was. A good alternative, but that also requires additional info from the API.
what does it need to work with the operator? Is not provided to the when context?
Not that I'm aware of. Maybe it is called something else, but a quick look at the issues/PRs but didn't find anything that could confirm.
Ah I see. I think you need to do something like (untested): Here: Probably would also want to add other context keys similar to what gets set on the editor content menus: Probably via:
It makes sense to make the line number available via a context overlay.

I've opened a PR to add an context key and tested that it works to enable/disable actions in this context menu for a test extension: in my testing it seems like the other context keys are already set because of the active editor, so I'm not sure explicitly setting that for the context menu is necessary--please correct me if I'm mistaken.
Hi Just to let you know, the new context key is working perfectly. Thank you!
I had a few ideas for gutter annotations, and am wondering if all of the following are now possible after this change. I think and may be of particular interest to Clickable Annotations - Can open something like a diff view on left click Clickable Annotation - Can open a context menu Annotation - HTML tooltip fully controlled by an extension (hyperlinks, clickable buttons, images/graphs, etc?) -margin/padding annotations - An annotation can fully consume its assigned gutter space, allowing things like git diff / source control annotations which draw contiguous green lines without gaps for sections of code. Gutter Annotation Space - Allows gutter annotations from the same extension to be guaranteed to be displayed above and below each other. Ex: git diff, you want to guarantee the green lines are contiguous vertical lines across many lines of code. The downside is if there are 30 possible gutter annotations, of width X, this requires 30 X width. Gutter Annotation Space - Some gutter annotations can be share space and rarely appear (breakpoints, run test, hot line), for these annotations they can all stack together in the same gutter space. So if there are 30 possible optional annotations, but only 3 apply to this line, it only requires 3 X width. with Contiguous Ranges of Lines - Allow selecting a range of lines, and passing this as context to the extension. For example, you want to link to a range of code / snippet to show your coworker with Discontiguous Ranges of Lines - Allow selecting multiple ranges of lines, and passing this as context to the extension. Then share and link this snippet to your coworker. Some of the numerous use cases by extensions to keep in mind when thinking through this feature: Visual - Show contiguous green / red / yellow lines for where code matches / doesn't match / partially matches. Use Case - Extend VS diffing to allow diffing against arbitrary changes in the commit history, or between two arbitrary files the user is working on.

Left Click - Opens side by side diff or inline diff view Right Click - Context menu to allow changing revision to diff against, or arbitrary file to diff against. Hover - Revision or arbitrary file being diffed against Visual - Heatmap using a gradient from Red to Blue showing CPU time or Wall time spent on each line of code. Alternative visual - Just a glyph on lines above some threshold of resource usage. Use Case - Allows devs to identify expensive lines, to either improve or be cautious about changing or adding to. Left Click - Opens website with a of measured performance of that line of code. Alternative - Opens the flame chart in a pane owned by the extension. Right Click - Context menu to change/drilldown/slice the backing data source. For example, which benchmarks triggered the annotations. Or for which services/users is this considered a hot line versus others it is not. Hover - Shows a panel with the callstack that contributed most to the performance, with hyperlinks that will open those code locations in vs code. Also shows the backing data source. You can imagine numerous different linters running (syntax error, style enforcement, common typos, banned words/regex, etc). Next to logging lines allows seeing a sampling of the values that were output at that line, along with drilling down and slicing those values.
Feedback from API sync: This is good to finalize in April Maybe we want to also expose in the editor context menu (versus the editor line number context menu) in future, but that can be done independently of this proposal
Sorry, I do not clearly understand the current status of editor/lineNumber/context, can I use it for contributions point/menu, I downloaded but it is empty.
you should be able to reference the new menu in the of your extension provided it specifies 1.78 as its minimum VS Code version. That also means you will have to use Insiders until 1.78 ships as the standard release (aka Stable), which is due by the end of next week.
Works great in