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