From: Stefan Monnier <monnier@iro.umontreal.ca>
To: "João Távora" <joaotavora@gmail.com>
Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
Subject: Re: Byte-compilation warning in eldoc.el
Date: Fri, 10 Jul 2020 17:29:10 -0400 [thread overview]
Message-ID: <jwvmu479ihx.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <87v9ive69l.fsf@gmail.com> ("João Távora"'s message of "Fri, 10 Jul 2020 16:31:18 +0100")
>>> Thanks, fixed. But curiously it doesn't. You can call it (and I always
>>> do call it) with one argument, as one does in CL.
>> Technically, you can call it with one argument.
>> But in 99% of the cases it's a really bad idea.
> What's the difference to `intern'? or `intern-soft'?
Interning a new symbol doesn't affect existing ones, and interning an
old symbol doesn't do anything, so those two are perfectly harmless.
`unintern` on the other hand can render your Emacs session inoperable.
>>> By the way, the only reason I had to do this (I rarely use this outside
>>> interactive contexts)
>> Exactly: it might make sense occasionally while debugging, but is
>> usually an error in code.
> Not arguing but, like Drew, I wonder why. FWIW in Common Lisp, intern,
> unintern, find-symbol, etc all assume the "current package" as the thing
> to operate on.
Same here. `unintern` on the global obarray is really dangerous and
very rarely needed. Most cases I've found were misuses better served
by something different (e.g. `makunbound`).
> 1. when you `package-install` the new eldoc 1.2.0 package in Emacs 26.3
> for the first time, it just compiles it, it doesn't load it. We had
> witnessed this with Flymake too, remember?
`package-install` is not supposed to "load" the package (it installs
it, activates it, and compiles it). But yes, it is also supposed to
*reload* already loaded files (right before compiling), so it looks like
there might be a bug somewhere.
You might want to trace through `package--load-files-for-activation` to
see why eldoc.el is not reloaded even though it should be in
`load-history`.
> 2. When you shut down that Emacs session, start it again, run
> package-initialize, you _still_ don't have the new eldoc.el file
> (1.2.0) loaded. This is only for eldoc.el, flymake.el works
> correctly in this use case.
Yes, this is because it's preloaded in Emacs, so when package.el comes
to activate the package, the autoloads in `eldoc-autoloads.el` won't have any
effect because all its functions are already defined (since `eldoc.el`
is already loaded).
This is not a really bug in package.el but arguably a missing feature,
indeed. When `package-activate-all` is called, it should probably
reload all packages that were already loaded before (when the version
already loaded is different from the one that's just been activated).
Stefan
next prev parent reply other threads:[~2020-07-10 21:29 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-10 6:53 Byte-compilation warning in eldoc.el Eli Zaretskii
2020-07-10 7:20 ` João Távora
2020-07-10 7:43 ` Eli Zaretskii
2020-07-10 9:36 ` Noam Postavsky
2020-07-10 14:41 ` Stefan Monnier
2020-07-10 15:05 ` Drew Adams
2020-07-10 15:31 ` João Távora
2020-07-10 21:29 ` Stefan Monnier [this message]
2020-07-10 21:48 ` João Távora
2020-07-10 22:08 ` Stefan Monnier
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=jwvmu479ihx.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=joaotavora@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.