Fix: 'visualbell' doesn't work #1789
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Codecov Report
@@ Coverage Diff @@
## master #1789 +/- ##
==========================================
- Coverage 75.11% 75.11% -0.01%
==========================================
Files 76 76
Lines 125109 125173 +64
==========================================
+ Hits 93978 94026 +48
- Misses 31131 31147 +16
Continue to review full report at Codecov.
|
|
Sorry, I wrote an incorrect content of "cause". I have revised it. |
|
Ozaki Kiichi wrote:
### repro steps
test-environments:
* macOS 10.12.5, Terminal.app
* Ubuntu 16.04, gnome-terminal
```
vim -Nu NONE -c 'set vb'
```
and input `h`, but expected visual-bell (flashing screen) doesn't happen.
### details
Vim sends terminal-control-sequences at visualbell event when `t_vb` is `^[[?5h$<100/>^[[?5l`:
expected: `CSI ?5h` (reverse video) → 100ms delay → `CSI ?5l` (normal video)
actual: 100ms delay → `CSI ?5h` (reverse video) → `CSI ?5l` (normal video)
### cause
At visualbell event, `tputs()` in `out_str(T_VB)` is called,
and `out_char_nf()` is called by every characters of `T_VB` except `$<100/>` (terminfo string).
`$<100/>` is interpreted and executed in `tputs()` in advance of calling `out_char_nf()`.
```
in tputs():
[100ms delay by "$<100/>"]
out_char_nf('\e')
out_char_nf('[')
out_char_nf('?')
out_char_nf('5')
out_char_nf('h')
out_char_nf('\e')
out_char_nf('[')
out_char_nf('?')
out_char_nf('5')
out_char_nf('l')
```
This may depend on the implementation. For me it appears there is no
delay at all.
### proposal of fix
`T_VB` has to be flushed, at least, before `$<...>`.
desirable sequence:
```
tputs("\e[?5h")
out_flush()
tputs("$<100/>\e[?5l")
```
This patch adds `out_str_cf()` to check `$<` in `T_VB` and to insert flushing.
It appears this doesn't work for me. I actually liked the tiny flash,
making it flash for 200 msec would be a problem. Especially when it
repeats.
How about this solution, using your patch but changing out_str_cf():
void
out_str_cf(char_u *s)
{
#ifdef ELAPSED_FUNC
static int did_init = FALSE;
static ELAPSED_TYPE start_tv;
#endif
if (s != NULL && *s)
{
char_u *p;
#ifdef FEAT_GUI
/* Don't use tputs() when GUI is used, ncurses crashes. */
if (gui.in_use)
{
out_str_nf(s);
return;
}
#endif
if (out_pos > OUT_SIZE - 20)
out_flush();
#ifdef HAVE_TGETENT
for (p = s; *s; ++s)
{
/* flush just before delay command */
if (*s == '$' && *(s + 1) == '<')
{
char_u save_c = *s;
*s = NUL;
tputs((char *)p, 1, TPUTSFUNCAST out_char_nf);
*s = save_c;
# ifdef ELAPSED_FUNC
/* Only sleep once per second, otherwise a sequence of beeps
* would freeze Vim. */
if (!did_init || ELAPSED_FUNC(start_tv) > 1000)
{
do_sleep(100);
ELAPSED_INIT(start_tv);
did_init = TRUE;
}
p = vim_strchr(s, '>');
if (p == NULL)
p = s;
else
++p;
# else
/* Rely on the terminal library to sleep. */
out_flush();
p = s;
# endif
break;
}
}
tputs((char *)p, 1, TPUTSFUNCAST out_char_nf);
#else
while (*s)
out_char_nf(*s++);
#endif
/* For testing we write one string at a time. */
if (p_wd)
out_flush();
}
}
This way we can make the delay configurable with a option, instead of a
weird terminal-dependend escape code.
…--
hundred-and-one symptoms of being an internet addict:
85. Choice between paying Compuserve bill and paying for kids education
is a no brainer -- although a bit painful for your kids.
/// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
|
|
I updated patch.
I agree, but I think it would be better not to include specific process for visual-bell into I set 200msec intervals of visualbell. I felt 1sec intervals are less responsiveness of flashing to input (e.g. at key-repeat). |
|
Thanks. I think we should apply the restriction of once per second also to the normal bell. I don't think anyone counts on lots of bells :-) |
|
Ozaki Kiichi wrote:
I updated patch.
* Add `do_visualbell()` to adjust the interval of visualbell flashing
> It appears this doesn't work for me. I actually liked the tiny flash,
> making it flash for 200 msec would be a problem. Especially when it
> repeats.
I agree, but I think it would be better not to include specific
process for visual-bell into `out_str_cf()` and better to add new
function to control. I'd like to make `out_str_cf()` purely handle
terminal-strings.
OK, but I think we should also limit the normal bell. I know terminals
that turn it into a visual bell and then one has to wait for the
flashing to finish.
I set 200msec intervals of visualbell. I felt 1sec intervals are less
responsiveness of flashing to input (e.g. at key-repeat).
I found 200 msec too short, since the visual flash could be 200 msec.
Half a second seems like a good compromise.
I submitted the change, please check if it works OK now.
…--
You can't have everything. Where would you put it?
-- Steven Wright
/// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
|
dpelle
pushed a commit
to dpelle/vim
that referenced
this pull request
Jul 31, 2017
Problem: When using a visual bell there is no delay, causing the flash to
be very short, possibly unnoticeable. Also, the flash and the
beep can lockup the UI when repeated often.
Solution: Do the delay in Vim or flush the output before the delay. Limit the
bell to once per half a second. (Ozaki Kiichi, closes vim#1789)
janlazo
added a commit
to janlazo/neovim
that referenced
this pull request
Jul 17, 2018
Problem: When using a visual bell there is no delay, causing the flash to
be very short, possibly unnoticeable. Also, the flash and the
beep can lockup the UI when repeated often.
Solution: Do the delay in Vim or flush the output before the delay. Limit the
bell to once per half a second. (Ozaki Kiichi, closes vim/vim#1789)
vim/vim@2e147ca
janlazo
added a commit
to janlazo/neovim
that referenced
this pull request
Apr 13, 2019
Problem: When using a visual bell there is no delay, causing the flash to
be very short, possibly unnoticeable. Also, the flash and the
beep can lockup the UI when repeated often.
Solution: Do the delay in Vim or flush the output before the delay. Limit the
bell to once per half a second. (Ozaki Kiichi, closes vim/vim#1789)
vim/vim@2e147ca
janlazo
added a commit
to janlazo/neovim
that referenced
this pull request
Apr 13, 2019
Problem: When using a visual bell there is no delay, causing the flash to
be very short, possibly unnoticeable. Also, the flash and the
beep can lockup the UI when repeated often.
Solution: Do the delay in Vim or flush the output before the delay. Limit the
bell to once per half a second. (Ozaki Kiichi, closes vim/vim#1789)
vim/vim@2e147ca
janlazo
added a commit
to janlazo/neovim
that referenced
this pull request
Apr 13, 2019
Problem: When using a visual bell there is no delay, causing the flash to
be very short, possibly unnoticeable. Also, the flash and the
beep can lockup the UI when repeated often.
Solution: Do the delay in Vim or flush the output before the delay. Limit the
bell to once per half a second. (Ozaki Kiichi, closes vim/vim#1789)
vim/vim@2e147ca
janlazo
added a commit
to janlazo/neovim
that referenced
this pull request
May 25, 2019
Problem: When using a visual bell there is no delay, causing the flash to
be very short, possibly unnoticeable. Also, the flash and the
beep can lockup the UI when repeated often.
Solution: Do the delay in Vim or flush the output before the delay. Limit the
bell to once per half a second. (Ozaki Kiichi, closes vim/vim#1789)
vim/vim@2e147ca
I do actually, and it took me quite some time to figure out that this was the cause of this (reason for this is below). I am currently using a recompiled version of Vim (with a part of misc1.c commented out) but I would appreciate an option to adjust the half a second delay to, say, 0.
That is a good reasoning, but even in that case, some other terminals do audible bells. VX Connectbot (Android) even uses vibrate. In any case, the 200 ms delay for the visual bell could also be configurable. If the first two people who write to this issue are already disagreeing on the length of time, other people will want it differently, too. In case anyone is interested in the reason why I sometimes hold down a key to hear the bell repeating: the bell sound I use is kind of soothing and repeating it adds rhythm to that. It lets me relax in between the programming work :-). Plus, it's always good to know that no programs are currently slowing down the computer. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
repro steps
test-environments:
and input
h, but expected visual-bell (flashing screen) doesn't happen.details
Vim sends terminal-control-sequences at visualbell event when
t_vbis^[[?5h$<100/>^[[?5l:expected:
CSI ?5h(reverse video) → 100ms delay →CSI ?5l(normal video)actual: 100ms delay →
CSI ?5h(reverse video) →CSI ?5l(normal video)cause
At visualbell event,
tputs()inout_str(T_VB)is called,and
out_char_nf()writes characters ofT_VBexcept$<100/>(terminfo string) toout_buf.$<100/>is interpreted and executed beforeout_bufis flushed.proposal of fix
T_VBhas to be flushed, at least, before$<...>.desirable sequence:
This patch adds
out_str_cf()to check$<inT_VBand to insert flushing.Ozaki Kiichi