Re: mutt window copy/paste (Correction)
On Mon, Jul 08, 2002 at 09:01:53PM -0700, Deb wrote: Thomas Dickey [EMAIL PROTECTED] had this to say, On Fri, Jul 05, 2002 at 01:13:47PM -0700, Deb wrote: I forgot to mention that I'm using xterm-166, with terminfo xterm-color, on Solaris, Sparc. Not sure the xfree86 is appropriate for this platform? But xterm-color usually says that the terminal doesn't implement back color erase (bce). In that case, most full-screen applications will write explicit blanks, which xterm's select/paste will preserve. Hold on. The behavior holds for *both* xterm and xterm-color, and I just tested F-secure ssh Windoze client - and it also exhibits the same behaviour - the only common denominator is using mutt and copying/ pasting text from a displayed message. not if we're talking about the same thing. xterm stores a null in each cell for places which are erased, and a non-zero code otherwise. When someone selects data, it supplies blanks in place of embedded nulls, but does not change trailing nulls to blanks. It stores a flag to tell if the text was wrapped, so selections of wrapped lines work as expected. So the only real issue (for xterm) is whether the application wrote trailing blanks to the screen. Since XFree86 xterm implements bce and (unless you're running FreeBSD ;-), xterm-color doesn't mention bce, applications using $TERM set to xterm-color will fill cells with explicit blanks, while using the terminfo which I supplied with xterm, they'll rely on the terminal's behavior - and generally not use blanks except where it's faster than some other way. Applications such as 'screen' tend to confuse the issue of course. -- Thomas E. Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net
Re: mutt window copy/paste (Correction)
On Mon, Jul 08, 2002 at 09:01:53PM -0700, Deb wrote: I would consider this a bug. ( sure - but not in mutt or xterm ;-) I still respectfully disagree (see above). You may find this enlightening (man xterm): highlightSelection (class HighlightSelection) If ``false'', selecting with the mouse highlights all positions on the screen between the beginning of the selection and the current position. If ``true'', xterm highlights only the positions that contain text that can be selected. The default is ``false.'' -- Thomas E. Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net
Re: mutt window copy/paste (Correction)
Thomas Dickey [EMAIL PROTECTED] had this to say, You may find this enlightening (man xterm): highlightSelection (class HighlightSelection) If ``false'', selecting with the mouse highlights all positions on the screen between the beginning of the selection and the current position. If ``true'', xterm highlights only the positions that contain text that can be selected. The default is ``false.'' Yes, it is. The F-secure window is vt100, which perhaps does confuse the issue. Thanks for taking the time... I have a bit of reading to do. deb
Re: mutt window copy/paste (Correction)
On Tue, Jul 09, 2002 at 08:23:17AM -0700, Deb wrote: Thomas Dickey [EMAIL PROTECTED] had this to say, You may find this enlightening (man xterm): highlightSelection (class HighlightSelection) If ``false'', selecting with the mouse highlights all positions on the screen between the beginning of the selection and the current position. If ``true'', xterm highlights only the positions that contain text that can be selected. The default is ``false.'' Yes, it is. The F-secure window is vt100, which perhaps does confuse the issue. F-secure isn't the same program as xterm anyway - but it's likely that it makes analogous tradeoffs for keeping track of selections. -- Thomas E. Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net
Re: mutt window copy/paste (Correction)
On Tue, Jul 09, 2002 at 08:23:17AM -0700, Deb wrote: | Thomas Dickey [EMAIL PROTECTED] had this to say, | Yes, it is. The F-secure window is vt100, which perhaps does confuse | the issue. You can also try Putty and Tera Term. I know that both of them (or at least putty) support the BCE feature that was mentioned elsewhere in the thread. Of course, their actual usefulness does depend on the termcap/terminfo entries on the host UNIX system. For example putty purports to be 'xterm' by default (but you can set it to whatever value you like). when connecting to solaris, mutt/vim have no color at all -- because the solaris 'xterm' termcap entry says that it doesn't support color. However if you set $TERM to 'dtterm', color works properly. When connecting to a linux (eg debian or redhat) system, their terminfo entry for 'xterm' includes color so putty gives nice colors then. I'm not sure what the original problem was, but maybe trying some other terminal emulators or $TERM settings will help lead to a solution. HTH, -D -- The righteous hate what is false, but the wicked bring shame and disgrace. Proverbs 13:5 http://dman.ddts.net/~dman/ msg29471/pgp0.pgp Description: PGP signature
Re: mutt window copy/paste (Correction)
Thomas Dickey [EMAIL PROTECTED] had this to say, On Fri, Jul 05, 2002 at 01:13:47PM -0700, Deb wrote: I forgot to mention that I'm using xterm-166, with terminfo xterm-color, on Solaris, Sparc. Not sure the xfree86 is appropriate for this platform? But xterm-color usually says that the terminal doesn't implement back color erase (bce). In that case, most full-screen applications will write explicit blanks, which xterm's select/paste will preserve. Hold on. The behavior holds for *both* xterm and xterm-color, and I just tested F-secure ssh Windoze client - and it also exhibits the same behaviour - the only common denominator is using mutt and copying/ pasting text from a displayed message. Mutt, in all cases I think, is using my color defaults, even when there is no color. I could eliminate that from the mix and test, I suppose. Next on the drawing board... deb I would consider this a bug. ( sure - but not in mutt or xterm ;-) I still respectfully disagree (see above). Kind Regards, deb
Re: mutt window copy/paste (Correction)
On Fri, Jul 05, 2002 at 07:40:17PM +0200, Vincent Lefevre wrote: On Fri, Jul 05, 2002 at 10:18:01 -0700, Deb wrote: When I copy multiple lines of text from a message I'm reading in mutt, then paste that text into a different window, all the lines are post-appended with space padding and a NL is on the end of the line at the window edge. This is a FAQ. You should use a terminal that have bce support (like the Xfree86 xterm) and terminfo data that announce bce. If you use ncurses 5.2 terminfos, TERM=xterm-xfree86 and TERM=xterm-vt220 should be OK for the Xfree86 xterm. BTW, this doesn't solve all the problems. I sometimes notice trailing spaces in headers. There's more than one possibility here (including bugs, of course). For instance, the header may have been written on top of some existing blanks, and the optimization takes that into account. For xterm, the spaces that are copied via mouse-selection are from explicit writes to those positions since the last clearing operation, e.g., erase-display, erase-line. -- Thomas E. Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net
Re: mutt window copy/paste (Correction)
I forgot to mention that I'm using xterm-166, with terminfo xterm-color, on Solaris, Sparc. Not sure the xfree86 is appropriate for this platform? I suspect what Thomas Dickey stated is closest to the truth, that the spaces are explicit writes to those positions. And a test with both the /usr/openwin/bin/xterm and xterm-166 both show this to be the case - but ONLY when using mutt. It doesn't seem related to the window interface at all, but instead to how mutt is drawing the picture. I would consider this a bug. deb * Thomas Dickey [EMAIL PROTECTED] [2002-07-05 13:56:52 -0400]: On Fri, Jul 05, 2002 at 07:40:17PM +0200, Vincent Lefevre wrote: On Fri, Jul 05, 2002 at 10:18:01 -0700, Deb wrote: When I copy multiple lines of text from a message I'm reading in mutt, then paste that text into a different window, all the lines are post-appended with space padding and a NL is on the end of the line at the window edge. This is a FAQ. You should use a terminal that have bce support (like the Xfree86 xterm) and terminfo data that announce bce. If you use ncurses 5.2 terminfos, TERM=xterm-xfree86 and TERM=xterm-vt220 should be OK for the Xfree86 xterm. BTW, this doesn't solve all the problems. I sometimes notice trailing spaces in headers. There's more than one possibility here (including bugs, of course). For instance, the header may have been written on top of some existing blanks, and the optimization takes that into account. For xterm, the spaces that are copied via mouse-selection are from explicit writes to those positions since the last clearing operation, e.g., erase-display, erase-line. -- Thomas E. Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net -- If it dies, it's biology. If it blows up, it's chemistry, and if it doesn't work, it's physics. -- University bathroom graffito ô¿ô ~
Re: mutt window copy/paste (Correction)
On Fri, Jul 05, 2002 at 01:13:47PM -0700, Deb wrote: I forgot to mention that I'm using xterm-166, with terminfo xterm-color, on Solaris, Sparc. Not sure the xfree86 is appropriate for this platform? But xterm-color usually says that the terminal doesn't implement back color erase (bce). In that case, most full-screen applications will write explicit blanks, which xterm's select/paste will preserve. I suspect what Thomas Dickey stated is closest to the truth, that the spaces are explicit writes to those positions. And a test with both the /usr/openwin/bin/xterm and xterm-166 both show this to be the case - but ONLY when using mutt. It doesn't seem related to the window interface at all, but instead to how mutt is drawing the picture. I would consider this a bug. ( sure - but not in mutt or xterm ;-) deb * Thomas Dickey [EMAIL PROTECTED] [2002-07-05 13:56:52 -0400]: On Fri, Jul 05, 2002 at 07:40:17PM +0200, Vincent Lefevre wrote: On Fri, Jul 05, 2002 at 10:18:01 -0700, Deb wrote: When I copy multiple lines of text from a message I'm reading in mutt, then paste that text into a different window, all the lines are post-appended with space padding and a NL is on the end of the line at the window edge. This is a FAQ. You should use a terminal that have bce support (like the Xfree86 xterm) and terminfo data that announce bce. If you use ncurses 5.2 terminfos, TERM=xterm-xfree86 and TERM=xterm-vt220 should be OK for the Xfree86 xterm. BTW, this doesn't solve all the problems. I sometimes notice trailing spaces in headers. There's more than one possibility here (including bugs, of course). For instance, the header may have been written on top of some existing blanks, and the optimization takes that into account. For xterm, the spaces that are copied via mouse-selection are from explicit writes to those positions since the last clearing operation, e.g., erase-display, erase-line. -- Thomas E. Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net -- If it dies, it's biology. If it blows up, it's chemistry, and if it doesn't work, it's physics. -- University bathroom graffito ô¿ô ~ -- Thomas E. Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net
