From: MON KEY <monkey@sandpframing.com>
To: emacs-devel@gnu.org
Subject: lexbind, global namespace prefixes, `byte-compile-defvar', and `custom-guess-name-alist'
Date: Wed, 12 Jan 2011 16:00:40 -0500 [thread overview]
Message-ID: <AANLkTiknzoiGMMLPR2TrOayOM_deAHHKtKBrQvNWo5OT@mail.gmail.com> (raw)
It would be nice if `custom-guess-name-alist' recognized the
convention of naming global variables `*with-earmuffs*'.
I propose adding the following element:
("\\`\\*.*\\*\\'" variable)
In its current configuration the lexbind branch introduces new
treatmeant around declared special variables.
Specifically, there are these new symbols and primitives:
`special-variable-p', `declared_special',
`Vinternal_interpreter_environment',
`Qinternal_interpreter_environment',
which affect (at least) the following symbols and primitives:
`defvar_per_buffer', `defvar', `defvaralias', `setq', `defconstant',
`let*', `let', `make-symbol', `funcall_lambda', etc.
Likewise, bzr revno: 101441 of 2010-09-15 in trunk says:
,----
|
| (byte-compile-file-form-defvar, byte-compile-defvar): Warn about
| global vars which don't have a prefix and could hence affect lexical
| scoping in unrelated files.
|
`----
The above change means that `byte-compile-defvar' now warns when
(byte-compile-warning-enabled-p 'lexical)
returns non-nil and the symbol-name of a putatively special variable
does not match the regexp "[-*/:$]".
Currently this regexp is "optimized" under the assumption that if any
of the tokens "-" "*" "/" ":" "$" are present in a symbol-name then
that symbol is a potential global/dynamic var which does not lack a
prefix.
Given the warning issued and the regexp which triggers it, there seems
to be an implication that global "special variables" may be named
without a "namespace" so long as one or more magic tokens are present.
Indeed the warning even acknowledges certain lexical lisp conventions
of naming global/special variable symbols `*with-earmuffs*'.
Disregarding the (future) mechanisms by which one may declare a variable
special, there are perhaps unintended consesequence with the current
regexp in that where a symbol is named as `*earmuff', `/slashy',
`-dashy', `:colonic', `%fractured', it will regarded by the
byte-compiler as properly prefixed even though these aren't
file/library contexting namespaces...
As such, it might be be nice to see these pairs included of
`custom-guess-name-alist' as well:
("\\`[%$]" function) ;; `%private-fun', `$internal-fun'
("!\\'" function) ;; `set-foo!', `mutate-bar!'
("\\`\\+.*\\+\\'" variable) ;; `+superior-lisp+', `+constant-name+'
("\\`-" variable) ;; `--some-var--', `-her-buddy-', `--his-pal'
The general thrust of these suggestions is that users should be
presented with a consistent interface to help with disambiguating
global variables in the lexbind esp. where there is potential for
introduction of confusion around local-variables, permanent-locals,
etc. which might otherwise go unnoticed, become difficult to
gain access to and/or become informed of.
--
/s_P\
reply other threads:[~2011-01-12 21:00 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=AANLkTiknzoiGMMLPR2TrOayOM_deAHHKtKBrQvNWo5OT@mail.gmail.com \
--to=monkey@sandpframing.com \
--cc=emacs-devel@gnu.org \
/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).