Re: Mapping <*-CR>

On 25/08/13 16:04, Michael Henry wrote:
> On 08/20/2013 05:38 AM, John Little wrote:
>>
>>> Documentation can be confusing and can conflict with empirically
>>> determined behavior.
>>
>> A plug for xterm.
>>
>> xterm is well maintained by Thomas Dickey, who has been seen
>> on vim_dev. If you have a problem with its documentation, I
>> think he'd welcome a report of it.
>
> I agree. While looking around for information, I came across
> many postings from Thomas and found him to be quite
> knowledgeable. Xterm is probably the best-supported terminal
> available when it comes to accurately reproducing the keycodes,
> following standards (incomplete and inconsistent though they
> are), and implementing the complete feature set of vtxxx
> terminals. Much of my complaint regarding terminal
> documentation probably can't be helped, as the material itself
> is confusing because of the wild history of hardware terminals.
> I got a lot of benefit reading the Xterm documentation, and I
> found nothing there that contradicts Xterm's current behavior.
> But there is a lot of misleading documentation hanging around in
> blog posts, online articles, bug reports, Vim's help pages, and
> manpages for other terminal emulators. Much of that information
> conflicts with the actual behavior of modern terminal emulators,
> often because of changes made in the software over time.
>
> Lots of programs (Vim included) have hacks that check the TERM
> environment variable for a specific terminal name in order to
> make some assumptions about the terminal that can't be derived
> from the termcap or terminfo databases. For example, Vim uses
> the General Purpose Mouse library (libgpm) for mouse support on
> a terminal, and this library has a hardwired check of TERM; if
> it begins with "xterm", Gpm_Open() avoids trying to connect to
> the GPM daemon. Without this hack, Gpm_Open() can hang after a
> few invocations. This appears to be a known problem in GPM
> itself, but Vim falls victim to it.

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". By
default, $TERM is set to "linux" in the Linux console (reachable by
Ctrl-Alt-F1 to Ctrl-Alt-F6 for the six which have getty/login/sh (or
similar: getty could be mingetty, sh could be bash or tcsh or ksh or
zsh, etc.) running on them; you get back to the X11 GUI by Ctrl-Alt-F7
or sometimes Ctrl-Alt-F8), and _that_ console can benefit of having gpm
enabled; OTOH gpm is of no use on an terminal which emulates a text
console by displaying your text on an X11 window.

In my vimrc, I normally set t_Co to 256 to take advantage (with the help
of the CSApprox plugin) of my "gui" color settings, but only if the
terminal name includes "xterm" or "mlterm", because those have an
underlying 16777216-color X11 server supporting them; in the Linux
console I leave it at its default of 8, and syntax highlighting follows
the cterm= ctermbg= ctermfg= settings.

> You can see this on Fedora
> 19 by launching the following in an X11-based terminal emulator
> (it doesn't much matter which one; I've tried it using Xterm and
> KDE Konsole):
>
> TERM=konsole vim -u NONE '+set mouse=n'

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.

>
> After a few times of entering and exiting, Vim will appear to
> lock up. From another terminal, you can fix it by restarting
> the GPM daemon:
>
> sudo systemctl restart gpm
>
> Many terminals masquerade as Xterm so they can take advantage of
> hacks that check TERM for "xterm". For example, KDE's Konsole
> team has decided that it will from now on always masquerade as
> Xterm, and they will treat any behavior deviations from Xterm as
> a bug. Gnome-terminal always sets TERM to contain "xterm" as
> well.
>
> The terminal emulator ecosystem as a whole is currently a giant
> mess with a number of problems. Fixing it right is a large
> amount of work, most particularly because it's a chicken-and-egg
> problem. Changes are required to terminfo, ncurses, terminal
> emulators, and applications. Until all of these changes are
> in-place, there's no way to derive the full benefit of the
> redesign. And unless someone thinks of a clever way to remain
> backward-compatible while migrating to the overall solution,
> terminal support would become temporarily worse, making adoption
> almost impossible.
>
> Michael Henry
>

Best regards,
Tony.
--
Cthulhu for President!
(If you're tired of choosing the lesser of two evils.)

--
--
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.