On Mon 10 Feb 2020 at 19:02, [email protected] wrote:
On Sun, Feb 09, 2020 at 12:52:00PM +0100, [email protected] wrote:Hi, does anybody know, why termcap/terminfo support is disabled in poplog? In pop/src/syscomp/x86_64/sysdefs.p it says 'No longer sets TERMINFO for Linux' and the same is the case in several other files.I was not there when it happened, so just a guess: portability problems. At that time some systems had real terminfo library, other declared it obsolete and provided 'ncurses' instead. This is actually current problem: some systems ship 'ncurses5' some ship 'ncurses6'. Once you link to ncurses it is impossible to have binary that runs on all reasonably current Linux systems. For Poplog V16 this is resolved in following way: corepop is linked in a bit hackish way so that it works without ncurses. Once you rebuild Poplog liner will link to version of ncurses library provided by the system, so Poplog will run fine on the same machine. But if you transfer binary to another machine which has different ncurses version it will no longer work (of course rebuilding will cure the problem, provided you have corepop which does not depend on ncurses).I reenabled it and removed the conditional test in pop/ved/src/vdinitseq.p: #_IF not(DEF LINUX) elseif testdef vedtermcapscreen then weakref vedtermcapscreen(name); #_ENDIF and it works without problems so far. Positive effect: If using a different terminal emulator then xterm, which doesn't set its TERM variable to xterm like e.g. urxvt (TERM=3Drxvt-unicode-256color) or many other terminals like alacritty, kitty etc. poplog does no longer ask about the terminal type when starting up, because there is a termcap/terminfo entry for these terminals (mostly identical to xterm). What was the reason for disabling it? I can see no problems so far. Everything works as expected.I did few test several years ago and it worked fine. But I did only few tests. There is a change: Poplog used to roll its own emulation of termcap, which did not keep up with changing environment. AFAIK now it uses system library. Apparently others had less motivation for testing other bits were not enabled.
Thanks for the info. That seems plausible. But it is not a good reason to do it now, since now we are always recompiling on the local machine anyway. And as I said, it works fine. You even can have the graphic characters, if you adapt your vedinit.p file appropriately. Mine is like that:
vedinit.p
Description: vedinit.p
-- ceterum censeo redmondinem esse delendam
