screen-devel
[Top][All Lists]
Advanced

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

[screen-devel] [bug #52271] 'Bell in window' announcement freezes displa


From: Bela Lubkin
Subject: [screen-devel] [bug #52271] 'Bell in window' announcement freezes display
Date: Mon, 23 Oct 2017 20:56:56 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3188.4 Safari/537.36 OPR/49.0.2705.0 (Edition developer)

URL:
  <http://savannah.gnu.org/bugs/?52271>

                 Summary: 'Bell in window' announcement freezes display
                 Project: GNU Screen
            Submitted by: filbo
            Submitted on: Tue 24 Oct 2017 12:56:55 AM UTC
                Category: Program Logic
                Severity: 3 - Normal
                Priority: 5 - Normal
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
                 Release: 4.3.1
           Fixed Release: None
         Planned Release: None
           Work Required: None

    _______________________________________________________

Details:

$ cat screen-bug-bell-freeze

# The bell-freeze which drives me bats
screen -X bash -c 'sleep 2; while :; do echo -ne \\a; sleep 6; done'
screen -X bash -c 'while :; do sleep 0.25; date; done'

$ screen -c screen-bug-bell-freeze

=================

What happens: `date` output stumps down the screen for a while, pauses for
several geological ages while the status line announces Bell in window 0',
then continues.

What I'd like to happen: 'Bell in window 0' appears in the status line for
just as long (5 seconds) -- but does not at all impede the flow of output on
that window.

I understand that this might be somewhat miserable to implement on a physical
terminal with weak capabilities (might have to erase the status line, scroll,
redraw status line -- repeatedly; and this might look horrible; if anyone were
actually using old physical terminals at old slow baud rates where the
redrawing would be noticeable).  It should be fine on a physical terminal with
an actual status line, scrolling regions, or insert-line capability.  In fact
I'd be OK with an implementation which retained the existing 5-second-freeze
behavior on physical terminals where it'd be a hassle to do better...

This appears to be controlled by :msgwait == MsgWait in the source, and
presumably applies to everything sent down the MakeStatus() pipeline (which
appears to have various entry points like Msg(), LMsg()); so improving this
would make life better all over the place.

Thanks!




    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?52271>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

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