I'd welcome a test, please provide one. I actually wrote a small test 
code so I could understand the problem, but didn't include it. 

The 'grep dialog' sends its output to an OutputWindow labelled *Output* 
as a series of lines.  This is entirely separate from the "go to file/
line" code and the path issue raised in this bug.  The line being 
queried may also be a PyShell traceback.

When you right click on a line (any line in an OutputWindow), the 
string is passed to OutputWindow.goto_file_line(), which uses 
_file_line_helper() to try to find a valid file. The problem was the 
regex couldn't handle spaces (or tabs) correctly, and also the code gave 
up if the first match didn't result in a valid file.  Typically, it was 
trying a path which started with the first character after the last 
embedded space.  A match, but invalid. To get to the correct pattern, 
the code must not give up.

We are just trying patterns on a string w/o going back to the *Output* 
window.  That's reasonable, because, for example, the traceback line 
looks quite different from the grep dialog output and needs a different 
regex. It's certainly not inefficient, because the human right-clicked a 
single line and won't wake up for 500 ms, at least :-)

We have a simple problem to fix, and don't want use it as an excuse to 
tear up a lot of code which is working well.

Actually, I ran into this myself this morning while hacking trunk IDLE 
on Windows from a DOS box using python 2.6, and I had the problem half 
fixed before I saw this bug!  Amazing it took this long to raise it, the 
code here hasn't changed for many, many years.

The regex I added is specifically for Win paths.  It ltrims, then takes 
everything up to the first ':'.  The trick is to be non-greedy.

Do you have a case the corrected code doesn't handle?