2016-08-25 0:54 GMT+09:00 Tony Mechelynck <[email protected]>:
> On Wed, Aug 24, 2016 at 12:08 PM, Kazunobu Kuriyama > <[email protected]> wrote: > > 2016-08-24 4:45 GMT+09:00 Tony Mechelynck <[email protected]> > : > >> > >> With the following settings: > >> > >> :verbose set eb? vb? bo? t_vb? > >> errorbells > >> Last set from ~/.vimrc > >> visualbell > >> Last set from ~/.vimrc > >> belloff= > >> t_vb=^[|1000f > >> Last set from ~/.vimrc > >> > >> (the latter is set in a GUIEnter autocommand, the rest in the .vimrc > >> mainline code) > >> > >> when I hit <Esc> repeatedly, I hear no sound and I see no visual bell. > >> This is for gvim 7.4.2243 with GTK3 GUI. > >> > >> With the visual bell time set at a full second, it ought not to be too > >> fast for me to see it, don't you think? I have tested other values, > >> including the default, with the same result, or lack of one; and I > >> know about |option-backslash| to enter the vertical bar into the > >> option value. > > > > > > Hi Tony, > > > > As noted in gui_gtk_x11.c:6246--6249, that's not implemented yet. > > (Actually, it was once implemented in an early stage of the development.) > > > > Needless to say, the purpose of visual bell is to notify the user that > > something goes wrong with the editor, urging him to do something about > that > > (I mean this in a broad sense, including 'stop doing something'). > > > > Its effect is, however, to keep flashing the whole editor screen until > the > > problem causing visual bell is fixed, which prevents what he is typing to > > the editor from being legible on the screen. > > > > That deteriorates its purpose; while urging the user to do something, > visual > > bell interferes with what he does. > > > > Arguably, visual bell might be still useful for some simple use cases > where > > a problem causing annoying flash is gone once the user stops doing what > he's > > trying to do. > > > > But now that Vim supports asynchronous jobs. We need to take into > > consideration that visual bell may interfere with smooth interaction > between > > the user, Vim and a single or more external processes because visual bell > > exclusively occupies CPU cycles for drawing flash if we naively port the > > GTK+ 2 implementation to GTK+ 3. > > > > Best regards, > > Kazunobu > > > >> > >> > >> Best regards, > >> Tony. > >> > >> -- > >> -- > >> You received this message from the "vim_dev" maillist. > >> Do not top-post! Type your reply below the text you are replying to. > >> For more information, visit http://www.vim.org/maillist.php > >> > >> --- > >> You received this message because you are subscribed to the Google > Groups > >> "vim_dev" group. > >> To unsubscribe from this group and stop receiving emails from it, send > an > >> email to [email protected]. > >> For more options, visit https://groups.google.com/d/optout. > > I have a problem though: With or without 'visualbell', I don't hear > the beep. I had thought that a visible one would at least make it > noticeable, but if it isn't implemented... > Beep ((sound) bell) is implemented in both GTK+ 2 and GTK +3 using gdk_display_bell() (gui_gtk_x11.c:6222, gui_mch_beep()), and there's no interdependency between beep and visual bell. Accordingly, visual bell setting is irrelevant to the audibility of beep at all. And, on X11, gdk_display_bell() is implemented using either XkbBell() or XBell(), which tells us that the beep sound comes from X11. You probably need to check if X11 bell (beep) is enabled or not, by using, say 'xset -q'. > AFAICR, the GTK2 visual bell inverted the screen once, then after a > presettable delay it went back to normal. I never saw the Vim screen > flashing forever until the user had done something. > What if an external asynchronous process causes flash? To stop flash, the user must do something, and then, flash surely gets in the way. > > > Best regards, > Tony. > > -- > -- > You received this message from the "vim_dev" maillist. > Do not top-post! Type your reply below the text you are replying to. > For more information, visit http://www.vim.org/maillist.php > > --- > You received this message because you are subscribed to the Google Groups > "vim_dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
