Re: Mapping <*-CR>

On Aug 25, 2013 7:57 PM, "Tony Mechelynck"
<antoine.mechelynck@gmail.com> 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 vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.