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. 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'
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
--
--
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.
No comments:
Post a Comment