GNU bug report logs -
#66128
28.2; visible-bell breaks setterm --inversescreen on
Previous Next
Reported by: tom <at> logand.com
Date: Wed, 20 Sep 2023 20:16:01 UTC
Severity: normal
Found in version 28.2
Full log
View this message in rfc822 format
> From: Tomas Hlavaty <tom <at> logand.com>
> Cc: 66128 <at> debbugs.gnu.org
> Date: Fri, 22 Sep 2023 22:18:14 +0200
>
> On Thu 21 Sep 2023 at 08:00, Eli Zaretskii <eliz <at> gnu.org> wrote:
> > Emacs just sends to the terminal the sequence defined by the "vb"
> > termcap capability. Is that not correct when the screen colors are
> > inverted?
>
> I do not know.
>
> > Is this perhaps the problem of the terminal?
>
> No, I get the same behaviour in xfce4-terminal and kitty, so this does
> not seem to be specific problem with the linux console.
>
> I think I wrote it in the bug report too, under an X based terminal:
>
> $ emacs -nw -Q --eval '(setq visible-bell t)'
>
> then press PgUp.
>
> > Btw, we always use the termcap's "vb", even when terminfo is
> > available; should we use the terminfo's "flash" instead?
>
> I do not know.
Thomas, could you perhaps help us out here? This is about sending the
"visible bell" sequence to a terminal after "setterm --inversescreen on".
The original report is:
$ setterm --inversescreen on
$ emacs -Q --eval '(setq visible-bell t)'
Then in Emacs do something that causes a bell, like try moving beyond
the buffer's end. This causes the Emacs background to become white,
i.e. the visible-bell somehow countermands the inversescreen state.
Can you think of any reason for this behavior? Do terminals honor
inversescreen when they perform the visible-bell function? Emacs just
sends the sequence reported by the "vb" termcap capability of the
terminal when the visible-bell is triggered.
Thanks.
This bug report was last modified 1 year and 272 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.