On Aug 25, 2013 7:57 PM, "Tony Mechelynck" <[email protected]> wrote: > GPM can only work on a pure-text console which is not an > emulator but the hardware of your monitor and video in text > mode. As such, it has no connection to X and therefore > should NEVER have $TERM set to "xterm".
Mainly I was trying to give an example of an application (or a library, in this case) that checks the value of the TERM variable to infer details of the terminal setup, rather than going through the termcap/terminfo abstraction to query the database about the terminal's capabilities. It may well be wrong for a program to call Gpm_Open() when TERM=xterm. I haven't looked up how to correctly use that library. Though the author thought it worth coding a hack for xterm to prevent bad behavior, no such hack exists for TERM=konsole, so users of old KDE konsole that want to set their TERM variable correctly will not benefit from the Gpm_Open() hack. Modern KDE Konsole's authors recommend using TERM=xterm (or a derivative). They are willing to treat differences with xterm as bugs in Konsole. Given a correct-enough emulation of xterm's capabilities, that can be a reasonable plan (IMO), but there are always going to be differences between the real xterm and imitators. The open question is whether these differences cause more problems than the alternative of setting TERM to something other than xterm. In any event, for a Vim user, the fact that GPM is used in support of the 'mouse' option could be considered a detail. :help 'mouse' claims support on xterm (among others): > :help 'mouse' > Enable the use of the mouse. Only works for certain terminals > (xterm, MS-DOS, Win32 |win32-mouse|, QNX pterm, *BSD console with > sysmouse and Linux console with gpm). For using the mouse in the Ideally, Vim would allow the user to :set mouse=a without guarding against TERM values that might cause Gpm_Open() to be called illegally. Or perhaps GPM should have the burden to gracefully degrade when given an invalid TERM value. Either way, IMO the user shouldn't have to have a tree of logic in his .vimrc to avoid setting 'mouse' when his terminal isn't suitable. I first tripped on the 'mouse' problem when a plugin I was using performed a :set mouse=n during its operation (and restored it afterward). It was non-trivial to figure out why Vim was hanging when I changed from TERM=xterm to TERM=gnome (the old TERM value for gnome-terminal; it now wants to be xterm, too) when I was trying to figure out why Shift-F3 wasn't working for a friend using my Vim settings. Normally, I use Konsole, but gnome-terminal (with TERM=xterm) wasn't working. When I switched to TERM=gnome, Vim would hang when this plugin was activated. > AFAICT, the normal setting of the KDE konsole is to > masquerade as an xterm, setting $TERM to "xterm" (there may > be other possibilities but I'm not sure how to get at them), > so setting $TERM to "konsole" in konsole (or, /a fortiori/, > in a genuine xterm) seems unsupported. Yes, that's the recommendation from the Konsole developers for "modern" Konsole. But for older Konsoles (I'm not sure how old), setting TERM=konsole is needed to correctly match the behavior of the terminal. Michael Henry -- -- You received this message from the "vim_use" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
