GNU bug report logs - #1305
All code that currently beeps should use visual bell instead

Previous Next

Full log

Message #781 received at 1305 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: Alan Third <alan <at> idiocy.org>, 1305 <at> debbugs.gnu.org,
 Michael Welsh Duggan <mwd <at> md5i.com>, Stefan Kangas <stefan <at> marxist.se>,
 jasonspiro4 <at> gmail.com, Stefan Monnier <monnier <at> iro.umontreal.ca>,
 Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: Re: bug#1305: All code that currently beeps should use visual bell
 instead
Date: Fri, 30 Apr 2021 02:23:54 +0300

On 30.04.2021 00:46, Gregory Heytings wrote:

> I know you like the current default on GNU/Linux, and it will remain 
> available.  And what you like is not the default (you need to set 
> visible-bell in your init file), so from that point of view nothing 
> changes.

Fair enough. Still, it's more "proven" that yours, so to speak.

I don't mind putting it to the vote sometime, here or some other place.

>>> Would you imagine such a behavior in Visual Studio, Sublime or Atom?
>>
>> Briefly flashing some UI elements in a neutral fashion, without extra 
>> colors that may look out of place?
>>
> 
> Using inverse-video also creates extra colors, unless your frame happens 
> to display only black on white or white on black elements on the first 
> and last line.  Moreover with my patch the colors are fully 
> configurable, so you can adapt them to your theme.

It uses only the colors that are already there, though. Just in inverse. 
Maybe it looks worse on some alternative themes, I have really only 
tried it with the default one, and themes that are similar enough to it.

>> That's also why I asked whether somebody knows a corresponding UI 
>> element/animation in either of these editors we could, uh, "get 
>> inspired by".
>>
> 
> AFAICS in other editors error signals are far less frequent (e.g. they 
> do nothing when you try to move past the beginning or end of the buffer, 
> or when you press a key binding with no corresponding action, or when 
> you enter characters in a read-only file, ...), they only signal 
> "critical" errors.  So I'm not sure it's possible to get inspired by 
> what they do. What they use are typically popups; I attach two examples 
> with Visual Studio and Atom, one when a non-readable file is opened, 
> another when a non-writable file is saved.

Thanks for the screenshots.

I do not consider the 'ding' to be a warning or error notification, 
though: I far more often see it after pressing C-g myself, not when 
something unexpected happens. Otherwise a yellow notification, 
Atom-style, would be more pertinent.

But it would be interesting to try some icon-based animation in the echo 
area, like the red circle on VSCode's pic.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.