all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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




  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.