From: "Drew Adams" <drew.adams@oracle.com>
To: "'Stefan Monnier'" <monnier@iro.umontreal.ca>
Cc: 10879@debbugs.gnu.org, 'Chong Yidong' <cyd@gnu.org>
Subject: bug#10879: 24.0.93; doc for `find-file' et al is missing the return value
Date: Sat, 25 Feb 2012 08:37:10 -0800 [thread overview]
Message-ID: <0A371FF1256B461F9D58E0D784C4751F@us.oracle.com> (raw)
In-Reply-To: <jwvk43bmego.fsf-monnier+emacs@gnu.org>
> > but not for 3rd-party coders. Either it is "crap" for both
> > or useful for both.
>
> It's crap.
Interesting view. I guess the original Emacs coders were crap, then, since
*each* of the `find-file-*' commands makes a point of returning the buffer(s).
And this has been true since at least Emacs 20.
And each time the code was rewritten/updated, the maintainers again made sure to
return the buffer(s). Not just some inadvertent mistake, this crap.
Here, for instance, is `find-file-read-only' for Emacs 20 & Emacs 24. The other
`find-file-*' commands are all similar.
20:
(defun find-file-read-only (filename &optional wildcards)
"Edit file FILENAME but don't allow changes.
Like \\[find-file] but marks buffer as read-only.
Use \\[toggle-read-only] to permit editing."
(interactive "fFind file read-only: \np")
(find-file filename wildcards)
(toggle-read-only 1)
(current-buffer)) ; <==== make sure we return the buffer
24:
(defun find-file-read-only (filename &optional wildcards)
"Edit file FILENAME but don't allow changes.
Like \\[find-file], but marks buffer as read-only.
Use \\[toggle-read-only] to permit editing."
(interactive
(find-file-read-args "Find file read-only: "
(confirm-nonexistent-file-or-buffer)))
(unless (or (and wildcards find-file-wildcards
(not (string-match "\\`/:" filename))
(string-match "[[*?]" filename))
(file-exists-p filename))
(error "%s does not exist" filename))
(let ((value (find-file filename wildcards))) ; <=== use return
(mapc (lambda (b) (with-current-buffer b (toggle-read-only 1)))
(if (listp value) value (list value)))
value)) ; <============ make sure we return the buffer
In the latter, the function not only takes pains to return the buffer(s). It
also takes advantage of the fact that `find-file' does likewise.
Maybe you also think it's crap for `switch-to-buffer' & compagnie to return the
buffer, and that mention of that fact should be removed from the doc?
next prev parent reply other threads:[~2012-02-25 16:37 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-24 17:07 bug#10879: 24.0.93; doc for `find-file' et al is missing the return value Drew Adams
2012-02-25 3:54 ` Chong Yidong
2012-02-25 6:03 ` Drew Adams
2012-02-25 9:48 ` Stefan Monnier
2012-02-25 16:37 ` Drew Adams [this message]
2014-02-09 5:09 ` Lars Ingebrigtsen
2014-02-10 23:30 ` Drew Adams
2014-02-12 1:04 ` Stefan Monnier
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=0A371FF1256B461F9D58E0D784C4751F@us.oracle.com \
--to=drew.adams@oracle.com \
--cc=10879@debbugs.gnu.org \
--cc=cyd@gnu.org \
--cc=monnier@iro.umontreal.ca \
/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).