Community
Participate
Working Groups
Bug 563015 added Ctrl-Click support for the terminal. There are other common output formats that should be supported. High on that list is Java Stack Traces. See some commentary in Bug 563015 Comment 6
I think we should see if we can support consolePatternMatcherListeners[1] extension point here. [1]https://help.eclipse.org/2021-03/topic/org.eclipse.platform.doc.isv/reference/extension-points/org_eclipse_ui_console_consolePatternMatchListeners.html
The Java stacktrace parser for consoles is contributed in org.eclipse.jdt.debug.ui - it is only enabled under some conditions. For example, if you do an external launch with java as the executable it is enabled, but if the executable is bash it won't be enabled.
New Gerrit change created: https://git.eclipse.org/r/c/cdt/org.eclipse.cdt/+/179257
I created a proof of concept of using consolePatternMatcherListeners and it worked fairly well. It is a little spaghetti at the moment because we have to "look" like a Console to the consolePatternMatcherListeners, but it looks pretty good. My decision in the first phase was to use consolePatternMatcherListeners after the user clicks on a word, rather than to identify all hyperlinks ahead of time. I don't know if that was correct, and if perhaps what should happen is the consolePatternMatcherListeners is used to identify where hyperlinks could be in the document in the first place - which is what the Console view does. I don't think we should identify all hyperlinks ahead of time though and limit the search to what is being hovered. However, the console view does the hyperlink searching off the UI thread and ahead of time. That may mean that existing consolePatternMatcherListeners are too slow to be run at hover time as that means running in the UI thread.
One possible option is to take a snapshot of the console content (possibly limited to a certain amount of lines before/after the current screen) when the user presses Ctrl and start a thread to do the search on that snapshot (one could even run each contributor in parallel using a thread pool, but that may probably be overkill) Then, from the UI side I see two options: 1. wait for a result from the thread with a timeout, if exceeded the parsing is aborted. 2. provide the hover selection asynchronously, invalidating it if in the meantime the console content has changed. What do you think? I will give it a shot by running the current basic detector in a worker thread and see how it goes.
I think that is a good idea. The detection actually looks pretty fast if done a line at a time (how long can a few regexes take run in a separate thread?). One of the drawbacks to my PoC is that it didn't pay attention to enablements, as a result for some items there are many hits. May want a popup like the hyperlink detector has in the editor?
There were a lot of other higher priority Terminal bugs & features that got addressed, unfortunately that has bumped this to another release.
(Sorry - Covid summer used up too much of my time and these items did not make it into CDT 10.4. Retargetting for 10.5)
I am working on this in the background - but not sure which version of CDT I will get this resolved in.
