GNOME Bugzilla – Bug 169295
builtin termcap parser not needed
Last modified: 2014-04-23 18:12:47 UTC
The termcap parser doesn't have to live in vte. All the functionality is provided in a termcap or curses library vte depends upon anyway. Besides, it necessiates maintaining an up-to-date termcap file even for terminfo-only systems.
Created attachment 38299 [details] [review] Replace builtin termcap parser with library calls This proof-of-the-concept patch removes the builtin termcap parser with the calls to standard libtermcap functions. Applies to 0.11.1x. Tested for many months with ncurses.
Has it been tested on different distros and platforms? I have the impression that the termcap database has been an area where many people disagree how it should behave...
> Has it been tested on different distros and platforms? No I didn't have the facilities to do so (nor the motivation :) > I have the impression that the termcap database has been an area where many people disagree how it should behave... At any rate there seems to be no reason to use a terminal capability library in some parts of the code, and the internal termcap parser in some other. With the patch, it's up to the packager which particular termlib implementation is to be used (termcap, ncurses, etc.) - it'll be used consistently everywhere. BTW the patch needs an update to the latest vte version and a whitespace cleanup; if there's any interest I can do it.
Like the idea. Roman, can you submit an updated final patch? Or does it need more work?
It certainly does. I'll try to find some time this week to beat it into shape.
Roman: ping.
Created attachment 87581 [details] [review] Patch updated to apply against svn head Is there still an interest in this bug? I figured I'd update it, since the original submitter seems absent.
Created attachment 87802 [details] [review] Recognize 'Return' key
Ryan, do you have comments on this? I remember you hacking on it. Can't remember what happened to your work.
i believe our thinking at the time was that it would be better to rewrite the bad parser to not be so bad rather than replace it outright with a library call because we were afraid that the library call would end up causing all sorts of shifts in functionality that people would complain about
(In reply to comment #10) > i believe our thinking at the time was that it would be better to rewrite the > bad parser to not be so bad The problem is not in the quality of the parser, but rather in the quality and availablility of the data fed to it. E.g. on Fedora 8 all terminal-aware stuff is linked against ncurses or slang; both use the terminfo database. So /etc/termcap may be out of sync with the data used by apps running in the terminal, or may simply be missing. > because we were afraid that the library call would end up causing all sorts of > shifts in functionality that people would complain about Fair enough. OTOH note that these calls (as well as the original parser) are only used to populate the lookup tables, so it should be easy to check for regressions: one can take known-matching termcap and terminfo records, and feed them to the respective versions of the standalone lookup table dumper for comparison.
actually, the quality of the parser was quite bad. it had serious performance issues. the "rewrite" that i refer to is the one that was done (and committed) a while ago (bug 354061). if you have some time to show that the data read from terminfo is the same as the one from the termcap that we currently ship with gnome-terminal it would be very useful. should probably consider that terminfo might give different results on different systems. if you have a test program i can run, i'll do it on my ubuntu boxes :)
Lets look into this again. This has the potential to fix all kind of arrow keys, function keys, etc bugs...
I've looked a bit into using terminfo in vte. Using the ncurses terminfo doesn't look like a good match right now. We need to have per-VteTerminal terminfo, so we'd use newterm() and tiget*_sp(). However new_term takes a FD, and may read/write to that later, which would interfere with our code. Also, the *_sp functions apparently aren't enabled by default (at least here on my F13 libncurses doesn't have them). What we really want is to just use the terminfo database, not all the handling that ncurses does around it. So either write a terminfo database reader ourself (using code adapted from ncurses), or work with ncurses upstream to export some functions to create an object for a given terminfo entry, and add tiget* variants that take that. (Just FYI, if you're looking for a ncurses git, it's at git://ncurses.scripts.mit.edu/ncurses.git ).
Turned out to be easier than I thought. Pushed to wip/terminfo branch, which I'll merge in a few days if no issues pop up.
*** Bug 569627 has been marked as a duplicate of this bug. ***
*** Bug 532897 has been marked as a duplicate of this bug. ***
Let's try it on master.