From: "Stephen J. Turnbull" <stephen@xemacs.org>
To: "Drew Adams" <drew.adams@oracle.com>
Cc: 'Juanma Barranquero' <lekktu@gmail.com>, emacs-devel@gnu.org
Subject: RE: delete-windows-on
Date: Sat, 03 Oct 2009 03:27:26 +0900 [thread overview]
Message-ID: <87hbuhirch.fsf@uwakimon.sk.tsukuba.ac.jp> (raw)
In-Reply-To: <1EC435DE2A694911BE4AB26857D8C2C3@us.oracle.com>
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 :-)?
next prev parent reply other threads:[~2009-10-02 18:27 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-02 16:16 delete-windows-on Drew Adams
2009-10-02 16:30 ` delete-windows-on Juanma Barranquero
2009-10-02 16:47 ` delete-windows-on Drew Adams
2009-10-02 16:51 ` delete-windows-on Juanma Barranquero
2009-10-02 17:25 ` delete-windows-on martin rudalics
2009-10-02 17:55 ` delete-windows-on Drew Adams
2009-10-02 20:31 ` delete-windows-on Drew Adams
2009-10-03 5:52 ` delete-windows-on Stephen J. Turnbull
2009-10-02 17:37 ` delete-windows-on Drew Adams
2009-10-02 18:27 ` Stephen J. Turnbull [this message]
2009-10-02 17:25 ` delete-windows-on martin rudalics
2009-10-02 17:39 ` delete-windows-on Drew Adams
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87hbuhirch.fsf@uwakimon.sk.tsukuba.ac.jp \
--to=stephen@xemacs.org \
--cc=drew.adams@oracle.com \
--cc=emacs-devel@gnu.org \
--cc=lekktu@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).