From: Drew Adams <drew.adams@oracle.com>
To: Kaushal Modi <kaushal.modi@gmail.com>, 26564@debbugs.gnu.org
Subject: bug#26564: Document that only functions and not variables can end with "-p"
Date: Wed, 19 Apr 2017 10:26:53 -0700 (PDT) [thread overview]
Message-ID: <fc6d6749-73a0-4dd8-bf28-428bdaa21d32@default> (raw)
In-Reply-To: <CAFyQvY2Jhe7d7tFMgqQH+oHOHhx2_OXT3UBDYqjbUaXLw-KrNg@mail.gmail.com>
> The discussion on whether variables should end in "-p" came up few time on emacs-devel, at least the ones I was part of:
>
> 1. https://lists.gnu.org/archive/html/emacs-devel/2016-07/msg00734.html
> 2. http://lists.gnu.org/archive/html/emacs-devel/2017-04/msg00540.html
>
> Doing a rudimentary search in emacs/lisp/ code-base shows a sign of an undocumented convention that predicate functions, functions that return either nil or non-nil can end in "-p" (if the function name is multi-word, like nested-alist-p), or just "p" (if the function name is a single word, like stringp).
>
> I ran ag[1] in emacs/lisp:
>
> 1. 1511 matches -- defuns and defsubsts ending in -p -- ag 'def(un|subst)\s+[^ ]+-p\s+' --stats
> 2. 149 matches -- defvars, defconsts and defcustoms ending in -p -- ag 'def(var|const|custom)\s+[^ ]+-p\s+' --stats
> 3. 65 matches -- Just the user-facing defcustoms -- ag 'defcustom\s+[^ ]+-p\s+' --stats
>
> That corroborates that more functions tend to end in "-p" than variables.
A better measure would be # of `-p' vs number of NON-`-p',
for both functions and variables. But I'm sure that the
same result holds: far more `-p' functions than `-p' vars.
Stefan, at least, has actively discouraged the use of vars
with `-p' names, in emacs-devel. That could partly explain
the numbers. Also, there is nothing in the Elisp manual
coding conventions about `-p' for var names, so users
wouldn't get the idea to do that from the manual. That too
could partly explain the numbers.
> This bug report is to make a request to incorporate this unspoken rule as a rule in the Elisp manual.
>
> What would be the correct section to do so?
>
> [1]: https://github.com/ggreer/the_silver_searcher
FWIW, I disagree with a guideline to not name Boolean vars
using `-p'.
1. Variables and functions are already in separate spaces -
they can be examined/found separately (`boundp' vs `fboundp').
What do you hope to gain by outlawing/discouraging `-p' for
Boolean variable names? It cannot be to avoid confusing a
variable and a function, since the those kinds of animal are
already separate in Emacs Lisp.
2. A variable is, abstractly (e.g., in a formal abstract
data type), a nullary function. It makes just as much
sense to name a Boolean variable using `*-p' as it does
to name a Boolean function using that convention.
Just one opinion. Stefan disagrees, for instance (but
with no reasons given).
3. Is there a proposal for a _different_ naming convention
for Boolean variables? I'd argue that we should have some
such a naming convention. And I'd argue that it should be
different for options and non-option variables.
I use `-flag' for Boolean options and `-p' for Boolean
non-option variables. (I did not come up with the `-flag'
convention, BTW. Someone else did, long ago. I thought it
was a GNU Emacs convention, (maybe it was?) so I stuck to it.
Stefan is not a fan of `-flag' (or any naming convention for
vars).
4. There should be some easy way to ask for help on Boolean
variables. Better yet would be a way to ask for help on
a user option, filtering by defcustom type.
FWIW, I have code that does that. It provides help commands
that let you show the help for things based on different
criteria, and for options that includes the custom type.
You can match the type in different ways, depending on the
prefix argument:
- None: OPTION is defined with TYPE or a subtype of TYPE.
TYPE is a regexp.
- `C-u': OPTION is defined with TYPE or a subtype of TYPE,
or its current value is compatible with TYPE.
TYPE is a type definition or its first symbol.
- Negative: OPTION is defined with TYPE (exact match).
TYPE is a regexp.
- Positive: OPTION is defined with TYPE,
or its current value is compatible with TYPE.
TYPE is a type definition or its first symbol.
- Zero: OPTION is defined with TYPE or a subtype of TYPE.
TYPE is a type definition or its first symbol.
- `C-u C-u': OPTION is defined with TYPE (exact match).
TYPE is a type definition or its first symbol.
_Without_ such a capability, it should be possible, at a
minimum, to get only Boolean options, using a name-pattern
match.
Again, just one opinion.
next prev parent reply other threads:[~2017-04-19 17:26 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-19 15:47 bug#26564: Document that only functions and not variables can end with "-p" Kaushal Modi
2017-04-19 16:08 ` Eli Zaretskii
2017-04-19 16:22 ` Kaushal Modi
2017-04-19 21:49 ` Michael Heerdegen
2017-04-19 22:04 ` Drew Adams
2017-04-19 22:18 ` Michael Heerdegen
2019-10-12 20:27 ` Lars Ingebrigtsen
2019-10-12 20:47 ` Kaushal Modi
2019-10-12 23:18 ` Drew Adams
2019-10-14 1:50 ` Richard Stallman
2019-10-14 2:22 ` Drew Adams
2019-10-14 7:24 ` Eli Zaretskii
2019-10-14 7:21 ` Eli Zaretskii
2017-04-19 17:26 ` Drew Adams [this message]
2017-04-19 21:44 ` Michael Heerdegen
2017-04-19 22:01 ` Drew Adams
2017-04-19 22:23 ` Michael Heerdegen
2017-04-19 22:28 ` Drew Adams
2017-04-20 1:42 ` 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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=fc6d6749-73a0-4dd8-bf28-428bdaa21d32@default \
--to=drew.adams@oracle.com \
--cc=26564@debbugs.gnu.org \
--cc=kaushal.modi@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 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.