Let terminal consumers provide click handlers and pattern recognizers for buffer text #9679

Open
opened 2026-01-31 02:00:47 +00:00 by claunia · 5 comments
Owner

Originally created by @ghost on GitHub (Jul 17, 2020).

Description of the new feature/enhancement

Terminal consumers have a need to provide their own handlers for clickable regions of text in the terminal. For example: In VS this could enable clicking on build errors and opening up a document to the line and column called out in the error.

Proposed technical implementation details (optional)

There needs to be two additions to the terminal in order to enable this:

  • Consumers of the terminal must be able to provide a pattern that will identify regions of clickable text
  • Consumers will provide a callback that is called with the clicked text as a parameter
Originally created by @ghost on GitHub (Jul 17, 2020). <!-- 🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨 I ACKNOWLEDGE THE FOLLOWING BEFORE PROCEEDING: 1. If I delete this entire template and go my own path, the core team may close my issue without further explanation or engagement. 2. If I list multiple bugs/concerns in this one issue, the core team may close my issue without further explanation or engagement. 3. If I write an issue that has many duplicates, the core team may close my issue without further explanation or engagement (and without necessarily spending time to find the exact duplicate ID number). 4. If I leave the title incomplete when filing the issue, the core team may close my issue without further explanation or engagement. 5. If I file something completely blank in the body, the core team may close my issue without further explanation or engagement. All good? Then proceed! --> # Description of the new feature/enhancement Terminal consumers have a need to provide their own handlers for clickable regions of text in the terminal. For example: In VS this could enable clicking on build errors and opening up a document to the line and column called out in the error. <!-- A clear and concise description of what the problem is that the new feature would solve. Describe why and how a user would use this new functionality (if applicable). --> # Proposed technical implementation details (optional) There needs to be two additions to the terminal in order to enable this: - Consumers of the terminal must be able to provide a pattern that will identify regions of clickable text - Consumers will provide a callback that is called with the clicked text as a parameter <!-- A clear and concise description of what you want to happen. -->
claunia added the Issue-FeatureArea-OutputProduct-TerminalArea-WPFControl labels 2026-01-31 02:00:47 +00:00
Author
Owner

@DHowett commented on GitHub (Jul 31, 2020):

This will require some part of #204/#574, but is a distinct ask that control consumers be able to add matching conditions and intercept click events.

@DHowett commented on GitHub (Jul 31, 2020): This will require some part of #204/#574, but is a distinct ask that control consumers be able to add matching conditions and intercept click events.
Author
Owner

@DHowett commented on GitHub (Jul 31, 2020):

Triaged into BL, Spec needed.

@DHowett commented on GitHub (Jul 31, 2020): Triaged into BL, Spec needed.
Author
Owner

@vnagarnaik commented on GitHub (Sep 7, 2021):

Would it be possible to work on this FR, now that the #204/#574 have been closed?

@vnagarnaik commented on GitHub (Sep 7, 2021): Would it be possible to work on this FR, now that the #204/#574 have been closed?
Author
Owner

@zadjii-msft commented on GitHub (Sep 7, 2021):

I don't see why not, but whatever design we come up with should appropriately account for #8849, #7562, #8294, #2671, et. al. in #5001.

Actually, should this just be duped to some combination of those?

@zadjii-msft commented on GitHub (Sep 7, 2021): I don't see why not, but whatever design we come up with should appropriately account for #8849, #7562, #8294, #2671, et. al. in #5001. Actually, should this just be duped to some combination of those?
Author
Owner

@zadjii-msft commented on GitHub (Sep 8, 2021):

I'm leaving this open and separate from #8849 because of one key factor:

For example: In VS this could enable clicking on build errors and opening up a document to the line and column called out in the error.

The ControlInteractivity needs a way of raising these events up to the hosting application to figure out what to do with them, not just the TermControl. Right now the control only really recognizes "ShellExecute this URL" as an action. People using the WPFControl will need to be able to say "If you see this pattern, then raise some identifier type of event", and be able to handle that event.

@zadjii-msft commented on GitHub (Sep 8, 2021): I'm leaving this open and separate from #8849 because of one key factor: > For example: In VS this could enable clicking on build errors and opening up a document to the line and column called out in the error. The `ControlInteractivity` needs a way of raising these events up to the hosting application to figure out what to do with them, not just the `TermControl`. Right now the control only really recognizes "ShellExecute this URL" as an action. People using the `WPFControl` will need to be able to say "If you see `this pattern`, then raise `some identifier` type of event", and be able to handle that event.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#9679