Date: Sun, 20 Oct 1996 22:48:23 +0200 (MET DST) From: cracauer@wavehh.hanse.de (Martin Cracauer) To: dawes@rf900.physics.usyd.edu.au (David Dawes) Cc: cracauer@wavehh.hanse.de, pst@freefall.freebsd.org, freebsd-current@FreeBSD.org Subject: Re: xterm termcap definition Message-ID: <9610202048.AA27538@wavehh.hanse.de> In-Reply-To: <199610201202.WAA07479@rf900.physics.usyd.edu.au> from "David Dawes" at Oct 20, 96 10:02:25 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >IN additional to the unusual behaviour of alternate screen, things in > >FreeBSD are even worse. More's default behaviour is to exit immediatly > >when EOF is hit, so people don't have a chance to see the last page > >when an alternate screen is availiable. One could call it is bug in > >more/less that is alternate screen is used at all when the option to > >exit on the first EOF is set. While I think this should be fixed in > >FreeBSD's more sources (so that end-on-eof enabled more *never* uses > >the second screen), I still think the default xterm shouldn't use an > >alternate screen. Just for people how use an alternate screen (like I > >do sometimes), less should behave in a way that one can see the last > >page :-) > > Yes, I'd like to see the behaviour of more changed. A problem is that > xterm's alternate screen function isn't set using any 'enable/disable > alternate screen' termcap function (I don't think there is one), but > with ti/te: > > te str String to end programs that use termcap. > ti str String to begin programs that use termcap. > OK, so we can't change more/less in the way I'd like. The only option is to make `more` default to something else than exit-on-first-eof. This option is useful only for people without alternate screen support. Sad... >One should get in contact with XFree to discuss things. Do they realy > >have a default xterm termcap entry that doesn't work when logged in > >from non-Xfree xterms? I can't beleive it. Do they feel they're alone > >in the world (Could drop a nasty comment about Linux here)? Is there > >some XFree hacker on this list? > > The 'xterm' termcap we (XFree86) have does make use of our xterm > enhancements. With 3.2, it will also include an xterm-r6 entry which > is the standard X Consortium termcap entry from X11R6, and an xterm-r5 > entry from X11R5. However, none of the entries from our termcap file > get put into /etc/termcap without the installer explicitly editing > /etc/termcap themselves, so this isn't forced on anyone. The postinst.sh > XFree86 script mentions this, and warns about the incompatibility. Hm, just an idea, maybe a stupid one. Could we intruduce an additional environment variable - say - "TERM_V"? While TERM would be "xterm", TERM_V could be "TERM_V" would be "6.1". Then, in termcap implementations that are aware of this feature, the termcap database could be search for an entry that matches the TERM variable, a "-" and a version number that is equal or higher ten "TERM_V" (just like with shared libs). In this example, termcap entries "xterm-6.2", "xterm-6.3", "xterm-7.1" would match, "xterm-5.7" wouldn't. If no entry with a matching version number is present, it falls back to the entry that matches TERM, "xterm". Machines that don't have these capabilities would fall back to "xterm" automatically. If we loose TERM_V (i.e. looging in over a telnet version that haven't been told to transport TERM_V as well as TERM), the fallback is still what is in TERM. The only potential problem is the usage of just another environment vaiable for system-specific features and therefore a conflict with applications or users using this variable name for other things. If we ignore any string in TERM_V that aren't exactly a version number ns the right syntax, most cases will be caught. Of course, the whole thing only works for strickly upward-compatibale evolution of an termial emulator. I think such a scheme has a number of potential advantages, not only for xterm, but for Console terminal emulators, too. Opinions? -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer <cracauer@wavehh.hanse.de> http://cracauer.cons.org Fax +49 40 522 85 36
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9610202048.AA27538>