bug#5616: 23.1.92; `delete-frame' deletes the last frame when emacsclient runs

[Drew Adams]

I wonder if `delete-frame' really should act differently in this way for
emacsclient. What's the rationale for this? Was this exceptional behavior an
explicit design decision or just a side effect of some implementation changes
for emacsclient?

It does make sense that there be a way to delete the sole frame when emacsclient
is used. But should `delete-frame' itself do that by default? I wonder.

Until now (Emacs 23), `(delete-frame FRAME)' has always raised an error if there
is only one visible frame. This means that some existing code will expect this
behavior, and it will now be broken.

Such existing code will now need to be modified to test, itself, whether the
frame is the only visible one, something it has always counted on the default
behavior of `delete-frame' to do. Similarly, new code will now need to test for
this special case, if it doesn't want the last frame to disappear when
emacsclient is used.

Programmers who don't immediately think about the emacsclient special case
(which probably means most programmers) are likely to write code that mistakenly
deletes the last frame when emacsclient is used, unless they bother to consult
the new (amended) doc for `delete-frame' (an old function).

`delete-frame' already has an optional FORCE parameter to handle this case
explicitly. And, FWIW, that is how this client/server use case has been handled
in the past. For example, the `gnuserv.el' client/server code calls
`server-edit' when finished with a buffer. And that calls `delete-frame' with a
non-nil FORCE arg, to force deletion for the client/server case. It achieves the
same client/server behavior as Emacs 23, but without changing the default
behavior of `delete-frame'.

IOW, in `gnuserv.el', the code to treat the special case of client/server is
handled in the client/server code itself. The default behavior of `delete-frame'
is unchanged when you use a client+server.

The Emacs 23 code instead puts this behavior change into the default behavior of
`delete-frame' itself: even with no FORCE arg, the frame is deleted if
client+server is used. This means that the default `delete-frame' behavior is
now context-dependent.

This effectively nullifies the usefulness of the normal sole-visible-frame test
by `delete-frame', since calling code must now explicitly test for that itself,
because of the new, exceptional (but default) behavior for the special case.

In effect, we now have an implicit non-nil FORCE arg when client+server is used.

Shouldn't `delete-frame' with null FORCE arg always raise an error, preventing
deletion of the last visible frame? Shouldn't the client/server code just
explicitly call `delete-frame' with a non-nil FORCE to do what it wants?

Just wondering. It seems like not deleting the last frame has always been part
of the definition of `delete-frame'. This new behavior (with emacsclient)
breaks/changes that. Is that really necessary or a good idea?