all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Daniel Brockman <drlion@deepwood.net>
Subject: Re: doc string of `local-variable-if-set-p'
Date: Fri, 15 Oct 2004 07:01:10 +0200	[thread overview]
Message-ID: <878ya8mv6x.fsf@wigwam.deepwood.net> (raw)
In-Reply-To: 200410150412.i9F4CUD12762@raven.dms.auburn.edu

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> The space constraint is 67 characters or less, so it will not look
> bad in the apropos output. So 66 is perfectly acceptable.

You're right.  I was just being defensive:  If all the docstrings are
to be consistently worded, those extra seven characters might not fit
as easily the next time you're writing a docstring for a function that
takes a buffer but not a name.

> OK, so what about:
>
> DEFUN ("local-variable-if-set-p", Flocal_variable_if_set_p, Slocal_variable_if_set_p,
>        1, 2, 0,
>        doc: /* Non-nil if VARIABLE will be local in BUFFER when set there.
> More precisely, this means that setting the variable \(with `set' or`setq'),
> while it does not have a `let'-style binding that was made in BUFFER,
> will produce a buffer local binding.  See Info node
> `(elisp)Creating Buffer-Local'.
> BUFFER must be a buffer \(not a buffer name) and defaults to
> the current buffer.  */)

I think this is good.  I would just rearrange the clauses slightly:

DEFUN ("local-variable-if-set-p", Flocal_variable_if_set_p, Slocal_variable_if_set_p,
       1, 2, 0,
       doc: /* Non-nil if VARIABLE will be local in BUFFER when set there.
More precisely, this means that setting the variable (with `set' or `setq')
will produce a buffer-local binding, unless the variable already has
a `let'-style binding that was made in BUFFER.
See Info node `(elisp)Creating Buffer-Local'.
BUFFER must be a buffer \(not a buffer name) and defaults to
the current buffer.  */)

> Actually there is a convention in the Elisp manual to call the
> argument BUFFER if it has to be a buffer and BUFFER-OR-NAME if it
> can be a buffer or a buffer name.  That convention is consistently
> followed in the Elisp manual, but not in docstrings.  So one can not
> just rely on it in docstrings.

OK, so we'll at least be following the convention --- that's good. :-)

-- 
Daniel Brockman
drlion@deepwood.net

  reply	other threads:[~2004-10-15  5:01 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-13 16:48 doc string of `local-variable-if-set-p' Masatake YAMATO
2004-10-13 17:13 ` Stefan
2004-10-13 17:22   ` Masatake YAMATO
2004-10-13 17:35     ` Stefan
2004-10-13 17:57       ` David Kastrup
2004-10-13 18:25         ` Luc Teirlinck
2004-10-13 18:23       ` Andreas Schwab
2004-10-15  0:26         ` Richard Stallman
2004-10-15  0:53           ` Miles Bader
2004-10-15  1:52           ` Luc Teirlinck
2004-10-15  2:12             ` Daniel Brockman
2004-10-15  2:40               ` Luc Teirlinck
2004-10-15  3:12                 ` Daniel Brockman
2004-10-15  4:12                   ` Luc Teirlinck
2004-10-15  5:01                     ` Daniel Brockman [this message]
2004-10-16  3:30                       ` Luc Teirlinck
2004-10-13 17:53     ` Luc Teirlinck
2004-10-13 22:24       ` Masatake YAMATO
2004-10-14  0:33         ` Luc Teirlinck
2004-10-15  0:26   ` Richard Stallman

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=878ya8mv6x.fsf@wigwam.deepwood.net \
    --to=drlion@deepwood.net \
    /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 external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.