unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: martin rudalics <rudalics@gmx.at>
To: Drew Adams <drew.adams@oracle.com>, 28947@debbugs.gnu.org
Subject: bug#28947: 26.0; doc string of `window-normalize-buffer' and similar
Date: Mon, 23 Oct 2017 10:06:01 +0200	[thread overview]
Message-ID: <59EDA2E9.902@gmx.at> (raw)
In-Reply-To: <c2a45513-581e-4cdc-91e7-c93b47b67233@default>

 > The doc string does not tell anything more than what the doc of
 > `get-buffer' tells you.  In fact, it tells you less.
 >
 > Why does the function name start with `window-'?  Is it just because it
 > is in file window.el?  If so, consider moving it.  If the function has
 > some relation to a window (I don't see anything in the code that
 > indicates that) then please describe that in the doc string.
 >
 > It looks like this should be called something like `get-live-buffer',
 > and the doc string should say that if no live buffer can be found then
 > an error is raised.
 >
 > The doc string should also say explicitly that if the arg is nil then
 > the current buffer is returned.

I rewrote the doc-string as follows:

Return buffer specified by BUFFER-OR-NAME.
BUFFER-OR-NAME must be a live buffer, a string naming a live
buffer or nil which means to return the current buffer.

This function is commonly used to process the (usually optional)
"BUFFER-OR-NAME" argument of window related functions where nil
stands for the current buffer.

 > Actually, if the arg is a buffer name that names a dead buffer then that
 > dead buffer is returned, so that wouldn't exactly be reflected in the
 > name `get-live-buffer'.
 >
 > I wonder why that behavior.  Should the 3rd cond branch perhaps check
 > that the result is a live buffer (in effect using the 2nd cond branch on
 > the buffer gotten)?

Right.  This should have been fixed in the release version.

 > Similar remarks apply to function `window-normalize-frame'.  Not
 > specific to a window.  Mention that a nil arg returns selected frame.

Done.

 > And similar remarks apply to function `window-normalize-window'.
 > In this case the function is about windows, but the suffix `-window' is
 > enough.  No need for prefix `window-'.

These three functions did not have the `window-' prefix initially.  The
prefix was requested by a maintainer and added later.

Thanks for the report, martin





  reply	other threads:[~2017-10-23  8:06 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-22 20:21 bug#28947: 26.0; doc string of `window-normalize-buffer' and similar Drew Adams
2017-10-23  8:06 ` martin rudalics [this message]
2017-10-23 13:16   ` Drew Adams
2017-10-31  8:41     ` martin rudalics

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=59EDA2E9.902@gmx.at \
    --to=rudalics@gmx.at \
    --cc=28947@debbugs.gnu.org \
    --cc=drew.adams@oracle.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).