URL handling in gnome-terminal

[Jiang]

Binary package hint: gnome-terminal

A URL in gnome-terminal that comes with Hardy(2.22.1), when it's longer
than one line, is only recognized with the first line. For example, a
URL
http://aaa....b<-gnome-terminal width end here
.org
would be only recognized as "http://aaa...b", with ".org neglected.
This was handled correctly in Ubuntu Dapper, which is of version 2.14.2.
This bug degrades the usefulness of gnome-terminal URL recognition when
there is a long URL present.
A temporary workaround is to copy the binary of the gnome-terminal from
the Dapper release, and copy the following two libraries
liblaunchpad-integration.so.0 and libvte.so.4 from Dapper installtion
to a place where hardy recognized

[Pedro Villavicencio (pedro)]

thanks for your report, that's known upstream you can track it here: http://bugzilla.gnome.org/show_bug.cgi?id=118955

[Matt Beaumont-Gay (mattb-cs)]

That upstream bug is actually about the URL recognition code catching *too much* text. It looks like the current behavior is "broken as designed" -- since it's difficult (perhaps impossible) to tell the difference between a continued URL and unrelated text on the next line, gnome-terminal only considers the first line's worth as part of the URL. I'd like the opposite behavior (grab text until space or tab), but I can see how it would be reasonable to prefer the current behavior.

[Ian Goldberg (linux-paip)]

I also just upgraded from Dapper to Hardy, and am experiencing this. Long URLs only get their first line recognized. Oddly, sometimes it works fine. If I paste a long URL into vi or the command line, the whole thing is recognized. If I cat a file with a long URL, the whole thing is recognized. But viewing an email message within mutt, it is not. (Could it have something to do with curses, or an application doing a single write(2) containing the whole URL?)

I think it's better to err on the side of recognizing too much, since it's more rare for a URL to end exactly at a line boundary than it is for one to be arbitrarily longer.

[Lee Bradshaw (lee-sectioniv)]

I also just upgraded from Dapper to Hardy and am having this problem in mutt. It looks like someone fixed the corner case (where the url ended on the last character of the line) and broke the much more likely case where urls are longer than one line and don't end exactly at a line boundary.

I just looked at 10 emails in mutt on a gnome-terminal on a Dapper system. Long urls were all handled properly even when I adjusted the screen size so the last character of a multline url was the last character of a line. Maybe it's just my emails, but I couldn't trigger the corner case that apparently prompted the change. The urls in those emails would open firefox on the right page in Dapper, but wouldn't work in Hardy unless I made the terminal wide enough (wider than the screen) to get the whole url on a single line.

[Pedro Villavicencio (pedro)]

this is a wontfix bug, upstream comment:

"I do not think this is solvable.

The current behaviour is useful when the URL does continue in the next
line (because long URLs tend to do that) and there is no way of
knowing whether the first char in the next line is part or not of the
URL (because URL are rather arbitrary after the user@passs:host:port
part, cf.
http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc2068.html#sec-3.2.1 for
http urls and http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc1738.html
for the general mess)"

[Heinrich Langos (henrik-launchpad)]

Same problem with ubuntu 9.04.

@Pedro: Please reopen this bug. The upstream bug was closed as "wontfix" because it is the CORRECT behavior to include the next line! This bug here describes that the next line is NOT included.

The problem occurs when reading email with mutt and its internal pager in the terminal.
If I pipe the same email from mutt to "less", the complete multiline URLs get recognized.
If I pipe it to "more" only the the first line of the URLs gets recognized by the URL catcher.

I didn't test further but my guess is that is has indeed to do with ncurses.

[Heinrich Langos (henrik-launchpad)]

If you need an upstream bug to follow, I guess it would be this one here:

http://bugzilla.gnome.org/show_bug.cgi?id=469862

Though I wonder how the kde guys do it. In konsole (on debian lenny) the link recognition works even with mutt. No matter what http://bugzilla.gnome.org/show_bug.cgi?id=469862#c5 says.

[Victor Engmark (victor-engmark)]

I don't know where this (possibly related) bug belongs: When hovering over multi-line URLs in the output of the following program, Terminal highlights the whole URL and loads it properly in the browser.
./filterous.py
If I pipe the result through `more`, it only highlights single lines:
./filterous.py < all.xml | more

[Victor Engmark (victor-engmark)]

If the importance was yanked up, shouldn't the status be changed?