RE: delete-windows-on

[Stephen J. Turnbull]

Drew Adams writes:

 > Why should it be an error? We have ways to check whether an object
 > is a buffer - code can always do that.

No.  Code *must* *check*.  So although signaling the result of the
check is in principal optional, there's no cost to signal an error if
the check fails.

 > Why do that here also (in effect)?

Errors should never pass silently.
Unless explicitly silenced.

Among other things, deleting windows on a buffer is a relatively safe
time to signal an error; you're not likely to be screwing anything up
by doing that, the user deals with an annoying beep and it's over.

 > To me, it makes sense to treat 42 here the same way we treated nil
 > in Emacs 21-22: a no-op. I'd sooner see both (a) a no-op here and
 > (b) a return value that indicates what happened.

Status values suck.  Programmers do not check them; that is one of the
few things you can truly rely on in software engineering.  Checking
them explicitly is indeed a PITA, and inefficient in Emacs Lisp
(requires a function call).

As for no-ops, I don't understand why you want GINO (garbage in, no
output).

 > It seems that that is the case here: nil is always returned. I have
 > no problem with our documenting that. But it might be even better
 > to return some useful info.

Status values are not useful.  Neither are the deleted windows, I
guess (don't know about the Emacs implementation, but in XEmacs
deleted windows are quarantined because their attributes are not
reliable -- they don't get updated at all).  What useful info do you
suggest (I'd like tomorrow's price of Oracle stock, preferably before
noon today, now *that* would be useful :-)?