On Sun, Apr 24, 2011 at 10:23:43PM +0900, Randy Bush wrote: > > What does the included termcap for xterm-xfree86 look like? > > xterm-new|modern xterm:\ ... looks ok - no hidden "ti" or "te" capabilities lurking in that. > > odd - even if you were using an application that uses the terminfo > > entry rather than the modified termcap, that should prevent the > > screen-switching. > > i test with less normally I test with ded (using ncurses and terminfo). But "less" behaves consistently (referring to the testing mentioned below). > > What does "xterm -v" say? > > no xterm on the remote sys. the local sys is macosx snow leopard, and > > % xterm -v > XTerm(251) Actually, I "have" that in my current configuration, but don't use it (their insistence on using the option/command buttons in the "emulate three-button mouse" rather than shift is cumbersome). So (except for testing), I use my compiled #269 (with the toolbar). However... the menu-entry seems to work for me here, testing with the bundled #251. > note that my ti_at_:te_at_: hack works when the remote sys is 7-stable or > releng_8. it's just 9-current I don't have 9-current (8.1 is here, as a VM). But I'm puzzled: if you were reporting the reverse case (expecting alternate screen-switching to occur), it would be good to collect a typescript from "script" and verify if the control sequences were sent. But this doesn't offer that possibility since it's doing a function that the menu entry itself should prevent. While it's possible to have conflicting resource-settings, the menu entry isn't affected by that (discarding another possibility). If I saw something like this first-hand, I'd compile a copy of xterm to compare (and look at its debugging trace). My local compiles on Mac OS X are only x86_64 so far - -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:13 UTC