GNOME Bugzilla – Bug 406134
mutt in gnome-terminal truncates long URLs at page boundary
Last modified: 2015-12-26 12:48:38 UTC
Please describe the problem: Using mutt (mutt-1.5.13-28) in gnome-terminal (gnome-terminal-2.16.1-22) on openSUSE 10.2, URLs opened via the "Open Link" option in gnome-terminal truncate at the page boundary. If you increase the width of gnome-terminal so the whole URL fits on one line, Open Link opens it correctly. Strangely, this only happens inside mutt. If you cat or vi a text file with a long URL in gnome-terminal, the Open Link does the correct thing and spans the page boundary to include the whole URL. Steps to reproduce: 1. In gnome-terminal, run mutt 2. View an email message with a URL that is longer than the width of the terminal and wraps to the next line. 3. Right click on the URL and select "Open Link" or "Copy Link Address". Actual results: You will see that the URL gets truncated at the page boundary. Expected results: The URL should not be truncated at the page boundary. Does this happen every time? Yes. Other information: This used to work correctly in the openSUSE 10.1 gnome-terminal.
Quick link for testing: http://www.this-is-an-extremely-long-url.abcdefghijklmnopqrstuvwxyz.qwertyuiopasdfghjklzxcvbnm.are-we-nearly-there-yet.net/its/just/around/the/corner/and/over/the/hill/beyond/the/valley.html * hopes bugzilla doesn't line wrap that!
In mutt (v1.5.13 2006-08-11), I have little '+' indicating that mutt has line wrapped the url for me - which breaks both the URL and the matching regex. What versions of mutt and g-t did openSUSE 10.1 use?
Add these lines to your .muttrc file to keep it from using the '+'. unset smart_wrap # Don't break lines unset markers # Don't use "+" to show wrapped lines
I believe it worked correctly with: mutt-1.5.9i gnome-terminal-2.12.0 I also remember that I tried running the older mutt with the newer gnome-terminal, and it still failed.
Just did a man muttrc and a google... I've found no option to disable mutt's line wrapping, just the smart_wrap which determines where to break the line. The regexes between g-t 2.12 and HEAD appear identical and do not include '\n' as a valid URL character. So I'm thinking something changed in vte... Okay between vte-0.12.2 and HEAD, this /* If the last visible column on this line was selected and * it contained whitespace, append a newline. */ became /* Else, if the last visible column on this line was selected and * not soft-wrapped, append a newline. */ which look likes the appropiate change. So I'm guessing there's a bit of history here... r1302 | behdad | 2006-04-23 09:39:08 +0100 (Sun, 23 Apr 2006) | 7 lines 2006-04-23 Behdad Esfahbod <behdad@gnome.org> Bug 339448 – selection doesn't respect hard newlines * src/vte.c (vte_terminal_get_text_range_maybe_wrapped): Add newline to the end of each line that is not soft-wrapped. "You can please some of the people some of the time..."
Yeah, known problem with mutt, less, and other apps that break the line where they shouldn't. Not sure how we want to "fix" this. I'd say this is an app bug. vte doesn't have this problem for example.
(In reply to comment #6) > Not sure how we want to "fix" this. I'd say this is an app bug. vte doesn't > have this problem for example. Oops, meant "vim doesn't have this problem".
If an app is putting "+" markers then there is no hope of handling it, I guess. Maybe we can add those newlines only when the app using vte asks for selected text?
I don't know how this is related, but I've noticed that vim doesn't have this problem if TERM=xterm, but it does if TERM=gnome.
(In reply to comment #9) > I don't know how this is related, but I've noticed that vim doesn't have this > problem if TERM=xterm, but it does if TERM=gnome. > So that seems to imply that vim is using some terminal capability that is defined in the xterm terminfo entry but missing from the gnome entry?
Tony, what problem do you mean you see in vim?
(In reply to comment #11) > Tony, what problem do you mean you see in vim? > The URL gets truncated at the page boundary. But only if I set TERM=gnome.
OK, so here's a summary of everything we know about this right now. Using the following: gnome-terminal-2.18.2-3 mutt-1.5.16-35 vim-7.1-44 With these lines to the .muttrc file to keep mutt from breaking lines and inserting a '+' on wrapped lines. unset smart_wrap # Don't break lines unset markers # Don't use "+" to show wrapped lines View an email message with a URL that is longer than the width of the terminal and wraps to the next line. Right click on the URL and select "Open Link" or "Copy Link Address". You will see that the URL gets truncated at the page boundary. This used to work correctly with gnome-terminal-2.12.0. I've noticed that vim also truncates the URL at the page boundary, but only if you set TERM=gnome. With TERM=xterm, it works correctly. So here are the many questions I have: 1. Where is the bug? gnome-terminal? vte? mutt? 2. If this was caused by the vte change that Chris shows in Comment #5, was that change really correct? 3. If this is considered to be mutt's fault, what should mutt be doing differently? 4. What does "soft-wrapped" mean. 5. Since vim also exhibits this problem when TERM=gnome, but not when TERM=xterm, does that imply that vim gets around this by using some terminal capability that is defined in the xterm terminfo entry but missing from the gnome entry? (If true, maybe mutt could be changed to do the same?) Does anyone have any idea how we can move this bug forward? Thanks.
Yep. As I can see, it affects any application that uses the curses library and doesn't cheat. In a curse screen, which is aware of the terminal size, when the cursor reaches the border of the screen, the line is simply hard-wrapped.
I see the same when I run irssi inside of a screen. Long links are broken onto 2 lines, but the mouse only highlights on the first line. When I resize the terminal window, IRSSI redraws and when the URL is on one line, it does work.
*** This bug has been marked as a duplicate of bug 754936 ***