Closed ukch closed 6 years ago
That does not seem like a valid URL, having that extra colon. I think it must be escaped as %3A, and probably the python lib is doing that for you on the fly.
Well, after a simple test I saw that my assumption about the URL encoding problem was wrong. I did the following:
$ cd
$ touch 'x:1'
$ echo file:///home/dsboger/x\:1
Then Ctrl+clicking the result opened "x:1" in gedit correctly (again, no regex needed).
On the other hand, I saw that GNOME (GNOME Files, probably) complains if the file does not exist, so maybe that is your case?
Works for me too, provided that the file is indeed called my.file:1
.
I'd rather suspect however that this notation intends to refer to file my.file
, line 1, in which case we do have something much more generic to talk about...
I think the problem is that the default built-in regex picks this up and thus never gets to the custom regex that you entered. Only the custom regex supports splitting the regex into groups and passing the values for those groups to applications like gedit.
I'll have a look this in more detail to see if I can make the custom ones be loaded first in order to take precedence.
I've fixed this by loading the custom regex first so it always takes predence. I also re-worked the custom link dialog so that items can be re-ordered to take leverage precedence when appropriate, see the screenshot below:
Do you guys happen to know if there's an official URI syntax for referring to a particular line of a local text file? (I couldn't find anything on the web.)
Colon is often used in practice after the filename (like my.file:1
), but I haven't seen it combined with URI-style filenames yet. I'm afraid that introducing special meaning to the :
characters might break backwards compatibility, but I'm not sure.
The fragment feature (the #
character) is the one in HTML that most resembles this feature, so another convention to consider might be to use e.g. #L1234
. The problem is that it may conflict with the HTML ID if the local text file happens to be an HTML. Still, this might be the cleanest approach, and choosing the right interpretation of the fragment would be up to the application depending on the context and/or the MIME type of the document.
The use case I have in mind would be the explicit hyperlink feature, e.g. compilers, or the grep
command turning the filename along with the corresponding line into a URI.
I haven't seen a standard URI for thus though colon seems to be the most common. If there was a standard URI for it, it would simplify the handling of it since presumably text editors could handle the URI. The situation as it is now is that every text editors has its own way of handling it via parameters.
As per the screenshot above, tilix handles this by allowing groups in regex and then allowing the user to specify a handler using the values of those regex groups as parameters. It works well but a standard URI would be simpler.
I don't know if there's anything standard. The above is the format that Mocha outputs when a test fails.
I've seen most commonly the following URI: <line start>:<column>:<line_end>:<column_end>
, ex 30:5:30:8
I have a Node.JS script which outputs file URLs in its stacktrace, and I would like to be able to ctrl-click on these URLs to open the relevant file in my editor. Here is an example of the types of URLs it is outputting:
I am trying to use the following Regex to handle this type of file:
I have validated the regex in the Python shell and it correctly matches the URL. However, when I ctrl-click on the URL I receive the message 'Error Opening Match: Could not open match file:///home/ukch/my.file:1'. I suspect this may be something to do with GNOME's built-in URL handling (which does not support
file:
URLs).