After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 637134 - Last character is not included in URL for some URLs
Last character is not included in URL for some URLs
Product: gnome-terminal
Classification: Core
Component: general
Other Solaris
: Normal normal
: ---
Assigned To: GNOME Terminal Maintainers
GNOME Terminal Maintainers
Depends on: 756038
Reported: 2010-12-13 09:25 UTC by Marcel Telka
Modified: 2016-02-21 15:21 UTC
See Also:
GNOME target: ---
GNOME version: ---

Description Marcel Telka 2010-12-13 09:25:40 UTC
If I have in the terminal then the latest c is not included in the URL on mouse hover, so just is recognized as URL.
Comment 1 Christian Persch 2010-12-13 13:01:58 UTC
Confirmed. Happens when there's only one character after the last slash.
Comment 2 Egmont Koblinger 2013-10-11 19:12:57 UTC
More interestingly, such URLs are not highlighted at all (not even up to the last "/") if the mouse enters from the right.
Comment 3 Egmont Koblinger 2013-10-11 21:07:57 UTC
The regex definition (PATHTERM_CLASS and URLPATH) in g-t/src/terminal-screen.c are the source of problem.

In URLPATH if there's at least one character following the "/" then it's swallowed by the first PATHCHARS_CLASS, and then at least one other character is required for the trailing PATHTERM_CLASS.

Other issues I'm not sure about:

URLPATH seems to contain a "loop" for matching all path components separately, yet PATHCHARS_CLASS also contains an embedded "/". It's not a problem per se, but I'm not sure about the intent.

PATHTERM_CLASS seems to exclude only a few characters, meaning that e.g. a lone "(" (or many other characters) at the URL is considered part of it, but subsequent characters aren't, which is not ideal.

I can't even see the purpose of PATHTERM_CLASS, I mean why do the valid characters in the last position differ from any other position?

I randomly found this:

Updating the two aforementioned classes that this patch changes seems to fix the problem. I haven't studied their regexps.

I'm clueless about the reason for the behavior mentioned in my previous comment. Perhaps it's about Vte incorrectly caching the negative result of failed regex match attempt.
Comment 4 Egmont Koblinger 2015-09-13 12:20:33 UTC
(off: comment 2 is fixed in bug 754949)
Comment 5 Christian Persch 2016-02-21 15:12:59 UTC
Fixed with the URL regex rewrite from bug 756038.