Author Topic: double click in output tab does not take to line number/col anymore?  (Read 111 times)

rowbearto

  • Senior Community Member
  • Posts: 1481
  • Hero Points: 112
I use the "Output" tool window (not process buffer) to print the output of an external process that then prints:

fullfilepath:line#:col#

In v23, I was able to double click on this line, and it would open the file "fullfilepath" (a source file in my project) and take me to the line# and col#.

Now in v24 it is just opening fullfilepath and it doesn't take me to the line#/col#. If the file was not opened before it takes me to line 0. If the file was opened previously it just opens that file at whatever line# it was at last, and doesn't take me to the desired line#.

Would like to have it also take me to the line# and col# like I it does in v23.
« Last Edit: November 04, 2019, 01:01:24 am by rowbearto »

patrick

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 1135
  • Hero Points: 107
Re: double click in output tab does not take to line number/col anymore?
« Reply #1 on: November 06, 2019, 03:50:45 pm »
That should be controlled by the error parsing setup.  If an error regex is matched that extracts the line number, that 's used to jump to that line.

Looking at your configuration you sent in a week or so ago, the first error regex that would match something like "/tmp/harness.cpp:34:10" is the NJikes error under the java heading, which is disabled in your setup.  Turning that on makes it work for me using your config.

rowbearto

  • Senior Community Member
  • Posts: 1481
  • Hero Points: 112
Re: double click in output tab does not take to line number/col anymore?
« Reply #2 on: November 06, 2019, 03:57:19 pm »
Thanks for the info Patrick. I will look into that. I turned off many of the error parsers because it was way too permissive and I was getting too many false positives - thats why I had so many exclusions in the past. But in my output window I may be getting different formatted errors so I will look into adding a more restrictive parser for that - or I can modify my output to the output window to pick this up. Thanks for letting me know this.