bug-ncurses
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Remove delay in `tset`


From: Thomas Dickey
Subject: Re: Remove delay in `tset`
Date: Sat, 9 Mar 2024 10:05:23 -0500

On Fri, Mar 08, 2024 at 10:32:20PM -0600, G. Branden Robinson wrote:
> At 2024-03-08T21:51:30+0000, Tim Hutt wrote:
> > Would it be possible to remove the 1 second delay from `reset` (which
> > is symlinked to `tset` on most systems)? Or failing that, reduce it to
> > 100ms.

fwiw, this is prompted by 

https://news.ycombinator.com/item?id=39638021

(nothing to be seen there...)

Regarding "nobody uses", that's demonstrably untrue:

https://invisible-island.net/ncurses/NEWS.html#index-t20231104

20231104
        + modify reset command to avoid altering clocal if the terminal uses a
          modem (prompted by discussion with Werner Fink, Michal Suchanek,
          OpenSUSE #1201384, Debian #60377).

> > It's quite annoying, and as far as I understand it entirely
> > unnecessary in 2024. I couldn't find the exact reason it ever existed.
> > Presumably it was just a hack to give the terminal time to reboot?
> 
> It _is_ documented in ncurses, and that _is_ the reason.
> 
> tset(1):
>      ā€¢   unless the ā€œ-Iā€ option is enabled, the terminal and tab
>          initialization strings are sent to the standard error output,
>          and tset waits one second (in case a hardware reset was
>          issued).

sure - if someone points out a reliable method for determining if the
delay's unneeded, that could be incorporated into ncurses.

Otherwise, the tools are available for someone to write a custom-script
that does what's asked.
 
> If you've ever used a dumb terminal, you will be aware that a hardware
> reset indeed takes measureable time to happen.
> 
> > I found one comment in some random code saying 'In 1979 3BSD's tset
> > had a sleep(1) to let mechanical printer-and-ink8 terminals "settle
> > down".' but I'm unsure if it was really because of mechanical
> > terminals or if later ones needed time to reset too.
> 
> ...even video terminals, in my experience, stop reading from the serial
> line while hard-resetting.
> 
> > In any case, nobody uses real terminals any more, whereas millions of
> > people use terminal emulators and have to endure the delay.

I've only seen one of the millions, which is kind of a low reporting rate.
 
> Why are you often having to reset your terminal?  Is some application
> scrambling its state?  Are you filing bugs against it for not putting
> things back the way it found them when starting up?
> 
> > Of course it is trivial to disable it for one system, but it is yet
> > another thing I have to disable on every system I use, when I really
> > shouldn't have to. The default should be sensible. Linux users
> > everywhere will thank you!
> 
> You could use tput(1) instead of tset(1).
> 
> Conceivably, tset could be changed to check for the NCURSES_NO_PADDING
> environment variable, which serves a similar purpose.  But I'm just
> spitballing.
> 
> Regards,
> Branden



-- 
Thomas E. Dickey <dickey@invisible-island.net>
https://invisible-island.net

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]