all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Glenn Morris <rgm@gnu.org>
Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
Subject: Re: Warnings about keymaps
Date: Thu, 17 Sep 2009 10:02:49 -0400	[thread overview]
Message-ID: <jwvhbv11y2w.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <g2my4ugh64.fsf@fencepost.gnu.org> (Glenn Morris's message of "Thu, 17 Sep 2009 03:32:35 -0400")

>> - most importantly: it doesn't solve the problem at hand which is how
>> to get rid of the other warning.
> The other warning?
>> - what's its use?  It's not like we've seen lots of bugs where people
>> use both defconst and defvar for a variable.
> It simply replaces the current "variable assignment to a constant"
> warning with a slightly more informative one, as you suggested.

Sorry, I misread your patch.  So you actually completely remove the
defvar if var was already defconst'd.  That's an attractive approach,
tho it's a bit risky, because byte-compile-const-variables only contains
variables that "may have been defconst'd", not those that "we know for
sure have been defconst'd".  E.g. try it with code such as

  (when toto
    (defconst foo bar))
  (defvar foo nil)

with your patch, you'd end up with `foo' undefined in the case where
toto is nil.  It may seem like a braindead case, but when comparing
"broken code in corner cases" vs "incorrect warning in some cases",
I prefer the incorrect warning.

>> - Finally, if the defconst+defvar is really what you want to do (as in
>> the present case where the defconst and the defvar both come from
>> macros that we may not want to change), how do you silence
>> the warning?

> The same way you silence the current one about variable assignment to
> a constant. :)

The difference is that the current one is incorrect, so the act of
silencing it needs to be done in bytecomp.el.  Whereas yours is meant to
be correct, in which case silencing it would need to be done by tweaking
the code and/or using with-no-warnings (which I profoundly disklike).

> I think it would be better to change define-derived-mode to not defvar
> the map if it is already defined;

I don't know how to do that.

> or to change easy-mode-defmap to not use defconst

That might be an acceptable workaround.  But the underlying problem will
still be there.

> (are you saying users should not add key bindings to
> log-edit-mode-map, for example?).

That's unrelated: defconst only says that the variable's binding won't
change, not that the object it is bound to is immutable.  My locally
hacked Emacs has "strong defconst" which really makes the variable
immutable, so (setq log-edit-mode-map <blabla>) signals an error, but
(define-key log-edit-mode-map [foo] 'bar) still works just fine.


        Stefan




  reply	other threads:[~2009-09-17 14:02 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-11  9:04 Warnings about keymaps Eli Zaretskii
2009-09-11 17:34 ` Glenn Morris
2009-09-11 17:43 ` Stefan Monnier
2009-09-14 19:10   ` Glenn Morris
2009-09-14 21:46     ` Stefan Monnier
2009-09-15  2:45       ` Glenn Morris
2009-09-15 13:40         ` Stefan Monnier
2009-09-17  7:32           ` Glenn Morris
2009-09-17 14:02             ` Stefan Monnier [this message]
2009-09-18 22:25               ` Glenn Morris
2009-09-19  0:04                 ` Stephen J. Turnbull
2009-09-19  0:43                 ` Stefan Monnier
2009-09-15 15:13       ` 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=jwvhbv11y2w.fsf-monnier+emacs@gnu.org \
    --to=monnier@iro.umontreal.ca \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=rgm@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 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.