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 [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
