RE: delete-windows-on

[Drew Adams]

> > 1. What "default buffer"? No such default is 
> > defined/implemented here, AFAICT.
> 
> My mistake.
> s/default/current/

No, my bad in this case.

Prior to Emacs 23, BUFFER was not optional, and nil did not represent the
current buffer. I had in mind the Emacs 21-22 treatment of nil - wasn't aware of
the change.

Dunno whether that change broke/breaks any code, but it is a user-observable
behavior change. Prior to Emacs 23, (delete-windows-on nil) was a no-op; now it
deletes windows on the current buffer. Since it is a user-visible change, it
probably should be documented (e.g. in NEWS).

Thanks for helping me become aware of this change. That doesn't affect my
overall questions/suggestions, but it does affect the parts about nil BUFFER.

> > 2. Besides, it is not the purpose of `delete-windows-on' to 
> > determine whether the BUFFER arg in fact corresponds to an
> > existing buffer or someone just fucked
> > up. Its purpose is to delete a window (or do nothing).
> 
> No. Its purpose is to "[d]elete all windows showing BUFFER-OR-NAME."
> An incorrect BUFFER-OR-NAME is an error.

Yes to the first sentence. The second sentence is currently true, but (a) it's
not documented and (b) it need not be true - I guess I disagree with that design
choice.

Why should it be an error? We have ways to check whether an object is a buffer -
code can always do that. Why do that here also (in effect)? (And interactively
there is no possibility of passing a non-buffer.)

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. But if the return value tells you nothing, then yes,
there could be some value in raising an error. 

> > a. What to return, and whether the return value is significant
> > (hence documented) or the function is instead called only for
> > its side effect.
> 
> In general, I prefer functions that clearly state what do they return,
> even if it is always nil.

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.