bug#1305: Emacs for new users

bug#1305: Emacs for new users

[Chong Yidong]

Chong Yidong <cyd@stupidchicken.com> writes:

>>> * beeping is often disturbing and unexpected, in particular for
>>> scrolling past the beginning or end of the
>>>   buffer with the scroll wheel. (I agree. That's hardly an error.)
>>
>> yes, I agree with you, beeping is often disturbing.  You can disable it,
>> changing the value of visible-bell to t:

> This is bug#1305.  That discussion never came to a conclusion.

One complication, now that I recall, is that we really do want to signal
an error for beginning-of-buffer and end-of-buffer, so that keyboard
macros will terminate.

The problem is that we have no mechanism for telling Emacs not to ring
the bell for certain classes of errors.

But I'm not sure Emacs should even be in the bell-ringing business,
anyway; it's a barbaric practice, and an echo-area message IMHO
suffices.

bug#1305: Beeping (was: Emacs for new users)

[Juri Linkov]

>>>> * beeping is often disturbing and unexpected, in particular for
>>>> scrolling past the beginning or end of the
>>>>   buffer with the scroll wheel. (I agree. That's hardly an error.)
>>>
>>> yes, I agree with you, beeping is often disturbing.  You can disable it,
>>> changing the value of visible-bell to t:
>
>> This is bug#1305.  That discussion never came to a conclusion.
>
> One complication, now that I recall, is that we really do want to signal
> an error for beginning-of-buffer and end-of-buffer, so that keyboard
> macros will terminate.
>
> The problem is that we have no mechanism for telling Emacs not to ring
> the bell for certain classes of errors.

I suggest to implement this mechanism by adding a new symbol property,
e.g. `error-bell' by analogy with properties `error-message' and
`error-conditions', with possible values t, nil and `visible'.

And to put this property with the value nil on `beginning-of-buffer',
`end-of-buffer' and `keyboard-quit' - most annoying beeping commands.

> But I'm not sure Emacs should even be in the bell-ringing business,
> anyway; it's a barbaric practice, and an echo-area message IMHO
> suffices.

Yes, this practice comes from ancient times of beeping keyboards :-)

-- 
Juri Linkov
http://www.jurta.org/emacs/

bug#1305: Beeping (was: Emacs for new users)

[Lennart Borgman]

On Thu, Nov 26, 2009 at 11:35 PM, Juri Linkov <juri@jurta.org> wrote:
>>
>> The problem is that we have no mechanism for telling Emacs not to ring
>> the bell for certain classes of errors.
>
> I suggest to implement this mechanism by adding a new symbol property,
> e.g. `error-bell' by analogy with properties `error-message' and
> `error-conditions', with possible values t, nil and `visible'.
>
> And to put this property with the value nil on `beginning-of-buffer',
> `end-of-buffer' and `keyboard-quit' - most annoying beeping commands.


Maybe the problem is a bit different. There is currently no dedicated
mechanism in Emacs to go to command level. Instead a lot of functions
throws an error when they want to go to command level.

Could we not implement something like (command-level) akin to (top-level)?

bug#1305: Beeping

[Stefan Monnier]

> Maybe the problem is a bit different. There is currently no dedicated
> mechanism in Emacs to go to command level. Instead a lot of functions
> throws an error when they want to go to command level.

> Could we not implement something like (command-level) akin to (top-level)?

I think there's a misunderstanding here.  Emacs usually tries to make
sure commands do *something*, because it' good to return feedback.
So when they don't, they often like to beep to indicate that they
couldn't do what they were asked to do.

I dislike the beep, so I always use the visual-bell instead.  I don't
think turning the bell into nothing at all is a good option.  I'd rather
try and address the reasons that prevent the visual-bell from being
the default.


        Stefan

bug#1305: Beeping

[Lennart Borgman]

2009/11/27 Stefan Monnier <monnier@iro.umontreal.ca>:
>> Maybe the problem is a bit different. There is currently no dedicated
>> mechanism in Emacs to go to command level. Instead a lot of functions
>> throws an error when they want to go to command level.
>
>> Could we not implement something like (command-level) akin to (top-level)?
>
> I think there's a misunderstanding here.  Emacs usually tries to make
> sure commands do *something*, because it' good to return feedback.
> So when they don't, they often like to beep to indicate that they
> couldn't do what they were asked to do.


As an example of what I mean look at what windmove-left does when
there is no window to the left. It then raises an error.

If debug-on-error is true I then get a chance to debug my behaviour. I
am not sure that makes sense.

The behaviour is different, but I think it should be similar to what
scroll-down/up does when it reaches the border. I think there should
be a unified behaviour. Making the visual bell default seems good, but
why not implement it as `command-level'?


> I dislike the beep, so I always use the visual-bell instead.  I don't
> think turning the bell into nothing at all is a good option.  I'd rather
> try and address the reasons that prevent the visual-bell from being
> the default.
>
>
>        Stefan
>

bug#1305: Beeping

[Stefan Monnier]

> As an example of what I mean look at what windmove-left does when
> there is no window to the left. It then raises an error.
> If debug-on-error is true I then get a chance to debug my behaviour. I
> am not sure that makes sense.

That's a problem between windmove and debug-ignored-errors.
BTW, I'd welcome a patch that introduces a new error `user-error' and
then changes calls to `error' where the error message is in
debug-ignored-errors to signal `user-error' instead.

> The behaviour is different, but I think it should be similar to what
> scroll-down/up does when it reaches the border. I think there should
> be a unified behaviour. Making the visual bell default seems good, but
> why not implement it as `command-level'?

That's already what "an error that's in debug-ignored-errors" does.


        Stefan

bug#1305: Beeping

[Lennart Borgman]

2009/11/27 Stefan Monnier <monnier@iro.umontreal.ca>:
>> As an example of what I mean look at what windmove-left does when
>> there is no window to the left. It then raises an error.
>> If debug-on-error is true I then get a chance to debug my behaviour. I
>> am not sure that makes sense.
>
> That's a problem between windmove and debug-ignored-errors.
> BTW, I'd welcome a patch that introduces a new error `user-error' and
> then changes calls to `error' where the error message is in
> debug-ignored-errors to signal `user-error' instead.


You mean that debug-ignored-errors should just be '(user-error)?

Isn't there still a problem with condition-case then? Or perhaps it
could be tamed to pass on user-error?


>> The behaviour is different, but I think it should be similar to what
>> scroll-down/up does when it reaches the border. I think there should
>> be a unified behaviour. Making the visual bell default seems good, but
>> why not implement it as `command-level'?
>
> That's already what "an error that's in debug-ignored-errors" does.
>
>
>        Stefan
>