Re: address@hidden: Wrong behavior of bs-delete, bs-delete-backward if buffer is not actually killed]

[Stefan Monnier]

> 
> On Fri, 16 Nov 2001 02:30:54 -0500, "Stefan Monnier" 
> <monnier+gnu/address@hidden> wrote:
> 
> > I'm not 100% sure about the change to bs-delete-backward: maybe bs-delete
> > should return a success/failure code so that we don't need to infer the
> > result with (eq current (bs--current-buffer)).
> 
> I would have done that in my patch if the status of the deletion were
> more generally used/useful; but bs-delete is a user-level, interactive
> function. Returning a code for another interactive function to test
> seemed wrong to me; before going that route, I think it'd be better to
> extract the buffer-deletion functionality to an auxiliary routine to
> be used by both delete functions instead of preserving the call to
> bs-delete from bs-delete-backward.

Just because a function can be called interactively doesn't mean
that it can't have a meaningful return value.

> > Or maybe we should simply do (error "Buffer was not deleted")
> > instead of (bs-message-without-log "Buffer was not deleted").
> Why?

It also gives the message to the user and it additionally shortcuts the
rest of the code in `bs-delete-backward' so we don't need to do anything
special there any more.
Basically, the success/failure return value is encoded in whether or
not the function returned with an error.
But maybe the beeping of `error' is annoying for the user, I don't know.


        Stefan