[TUHS] Termcap vs terminfo

[TUHS] Termcap vs terminfo

[David Barto]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 428 bytes --]

<much discussion about quadratic search removed>

All I remember (and still support to this day) is that I’ve got a TERMCAP=‘string’ in my login scripts to set termcap to the specific terminal I’m logging in with.

Long ago this made things much faster. Today I think that it is just a holdover that I’m not changing due to inertia, rather than any real need for it.

	David
— 
	David Barto
	david at kdbarto.org

[TUHS] Termcap vs terminfo

[Lyndon Nerenberg]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2233 bytes --]

On Jan 10, 2015, at 2:15 PM, David Barto <david at kdbarto.org> wrote:

> All I remember (and still support to this day) is that I’ve got a TERMCAP=‘string’ in my login scripts to set termcap to the specific terminal I’m logging in with.
> 
> Long ago this made things much faster. Today I think that it is just a holdover that I’m not changing due to inertia, rather than any real need for it.

There is still a need for this.

Most modern curses capability entries for 'xterm' and friends use the memory buffer windowing capability (a term I made up) such that when you - say - run less to display a file, it switches to a dedicated region in the terminal memory buffer while printing its output, then restores the buffer to back where you were to begin with when you exit the pager.

This drives me insane!  When I 'man foo' and find the relevant bits in the document, when I quit out of the pager I want those bits to stay on the screen so I can refer to them, dammit!  There are two shortcuts to this, both involving custom termcap/terminfo entries.

In the termcap case, you can define a $TERMCAP capability that describes an 'xterm' without the memory buffer hopping.  In the terminfo case, you tic(1) your custom 'xterm' definition into $HOME/.terminfo/...

These days - naturally - everyone knows the universe exists inside an ANSI terminal window, so who gives a fsck about term{cap.info}?  Well, I do, for this very reason.  A pox on everyone who has not 'setenv TERM aaa-48-s' !!!

--lyndon

P.S.  Terminfo entry attached for your enjoyment. (It's a text/plain. I have no idea what the hell Apple's Mail.app will do with it.)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: xterm.terminfo
Type: application/octet-stream
Size: 1339 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150110/582ebbd1/attachment.obj>
-------------- next part --------------


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150110/582ebbd1/attachment.sig>

[TUHS] Termcap vs terminfo

[Lyndon Nerenberg]

On Jan 10, 2015, at 2:43 PM, Lyndon Nerenberg <lyndon at orthanc.ca> wrote:

> Most modern curses capability entries for 'xterm' and friends use the memory buffer windowing capability (a term I made up)

Umm ... I meant 'just made up' as in "I can't think of a better name this second."  I'm pretty sure somebody else invented memory buffers and sliding pointers.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150110/b0b8aa7b/attachment.sig>

[TUHS] Termcap vs terminfo

[Christian Neukirchen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1347 bytes --]

Lyndon Nerenberg <lyndon at orthanc.ca> writes:

> On Jan 10, 2015, at 2:15 PM, David Barto <david at kdbarto.org> wrote:
>
>> All I remember (and still support to this day) is that I’ve got a
>> TERMCAP=‘string’ in my login scripts to set termcap to the specific
>> terminal I’m logging in with.
>> 
>> Long ago this made things much faster. Today I think that it is just
>> a holdover that I’m not changing due to inertia, rather than any
>> real need for it.
>
> There is still a need for this.
>
> Most modern curses capability entries for 'xterm' and friends use the
> memory buffer windowing capability (a term I made up) such that when
> you - say - run less to display a file, it switches to a dedicated
> region in the terminal memory buffer while printing its output, then
> restores the buffer to back where you were to begin with when you exit
> the pager.
>
> This drives me insane!  When I 'man foo' and find the relevant bits in
> the document, when I quit out of the pager I want those bits to stay
> on the screen so I can refer to them, dammit!  There are two shortcuts
> to this, both involving custom termcap/terminfo entries.

Or just use: xterm -xrm '*titeInhibit: true'
Just for less: export LESS="-X"
Just for vim: set t_ti= t_te=

-- 
Christian Neukirchen  <chneukirchen at gmail.com>  http://chneukirchen.org

[TUHS] Termcap vs terminfo

[Lyndon Nerenberg]

On Jan 10, 2015, at 3:02 PM, Christian Neukirchen <chneukirchen at gmail.com> wrote:

> Or just use: xterm -xrm '*titeInhibit: true'
> Just for less: export LESS="-X"
> Just for vim: set t_ti= t_te=

Please provide the list of workarounds for all other curses consumers used worldwide and forever.

Wouldn't it be nice if I could just do this in one place?  Oh, wait ...

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150110/525f7f9a/attachment.sig>

[TUHS] Termcap vs terminfo

[Dave Horsfall]

On Sat, 10 Jan 2015, Lyndon Nerenberg wrote:

> This drives me insane!  When I 'man foo' and find the relevant bits in 
> the document, when I quit out of the pager I want those bits to stay on 
> the screen so I can refer to them, dammit!  There are two shortcuts to 
> this, both involving custom termcap/terminfo entries.

I'm glad I'm not the only one annoyed by this "feature".

-- 
Dave Horsfall DTM (VK2KFU)  "Bliss is a MacBook with a FreeBSD server."
http://www.horsfall.org/spam.html (and check the home page whilst you're there)

[TUHS] Termcap vs terminfo

[Diomidis Spinellis]

On 11/01/2015 04:06, Dave Horsfall wrote:
> On Sat, 10 Jan 2015, Lyndon Nerenberg wrote:
>
>> This drives me insane!  When I 'man foo' and find the relevant bits in
>> the document, when I quit out of the pager I want those bits to stay on
>> the screen so I can refer to them, dammit!  There are two shortcuts to
>> this, both involving custom termcap/terminfo entries.
>
> I'm glad I'm not the only one annoyed by this "feature".

I agree it's maddening!  This is what I have on my .bashrc file to avoid 
this behavior.

# Don't restore screen, quit at EOF, more-like prompt, pass color 
control chars
export LESS=-XEmR

This problem, and the desire to use the vi key bindings instead of the 
Emacs ones for command-line editing, are the reason I invested effort to 
place my login configuration under Git control, and replicate it on the 
tens of hosts I find myself logged in over a working day.  Now a simple 
"git clone" restores sanity to my working environment.

[TUHS] Termcap vs terminfo

[Christian Neukirchen]

Lyndon Nerenberg <lyndon at orthanc.ca> writes:

> On Jan 10, 2015, at 3:02 PM, Christian Neukirchen <chneukirchen at gmail.com> wrote:
>
>> Or just use: xterm -xrm '*titeInhibit: true'
>> Just for less: export LESS="-X"
>> Just for vim: set t_ti= t_te=
>
> Please provide the list of workarounds for all other curses consumers
> used worldwide and forever.
>
> Wouldn't it be nice if I could just do this in one place?  Oh, wait ...

I did: xterm -xrm '*titeInhibit: true'

-- 
Christian Neukirchen  <chneukirchen at gmail.com>  http://chneukirchen.org

[TUHS] Termcap vs terminfo

[Clem Cole]

+1

On Sat, Jan 10, 2015 at 9:06 PM, Dave Horsfall <dave at horsfall.org> wrote:

> On Sat, 10 Jan 2015, Lyndon Nerenberg wrote:
>
> > This drives me insane!  When I 'man foo' and find the relevant bits in
> > the document, when I quit out of the pager I want those bits to stay on
> > the screen so I can refer to them, dammit!  There are two shortcuts to
> > this, both involving custom termcap/terminfo entries.
>
> I'm glad I'm not the only one annoyed by this "feature".
>
> --
> Dave Horsfall DTM (VK2KFU)  "Bliss is a MacBook with a FreeBSD server."
> http://www.horsfall.org/spam.html (and check the home page whilst you're
> there)
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150112/03579331/attachment.html>

[TUHS] Disable "less" screen swapping was: Re: Termcap vs terminfo

[Russell Rezaian]

On Sat, Jan 10, 2015 at 9:06 PM, Dave Horsfall <dave at horsfall.org 
<mailto:dave at horsfall.org>> wrote:
>
>     On Sat, 10 Jan 2015, Lyndon Nerenberg wrote:
>
>     > This drives me insane!  When I 'man foo' and find the relevant
>     bits in
>     > the document, when I quit out of the pager I want those bits to
>     stay on
>     > the screen so I can refer to them, dammit!  There are two
>     shortcuts to
>     > this, both involving custom termcap/terminfo entries.
>
>     I'm glad I'm not the only one annoyed by this "feature".
>
I am also not happy with this behavior.

There is at least one "fix" I have found for this particular annoyance.

A little background: this behavior uses a pair of termcap entries called 
"ti" and "te" which, on most recent xterm implementations, switch 
between alternate screens.  Many programs on startup switch to the 
alternate screen to keep their displays separate from the normal command 
scroll buffer.

There is an xterm resource "titeInhibit" which, if set to true, will 
disable the remarkably annoying mode switch that is used by less (and 
also any other application that tries to use the screen swap).

Given this started out as a termcap thread, hopefully this will be 
appropriate!

This complete disable of the screen swap may not be what everyone is 
looking for, but it certainly was what I wanted.
--
Russell
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150112/5a2613a0/attachment.html>