* Byte-compilation warning in eldoc.el
@ 2020-07-10 6:53 Eli Zaretskii
2020-07-10 7:20 ` João Távora
0 siblings, 1 reply; 10+ messages in thread
From: Eli Zaretskii @ 2020-07-10 6:53 UTC (permalink / raw)
To: João Távora; +Cc: emacs-devel
In toplevel form:
emacs-lisp/eldoc.el:540:2: Warning: unintern called with 1 argument, but
requires 2
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Byte-compilation warning in eldoc.el
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
` (2 more replies)
0 siblings, 3 replies; 10+ messages in thread
From: João Távora @ 2020-07-10 7:20 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
> In toplevel form:
> emacs-lisp/eldoc.el:540:2: Warning: unintern called with 1 argument, but
> requires 2
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.
By the way, the only reason I had to do this (I rarely use this outside
interactive contexts) is to make eldoc.el work in Emacs 26.3. I explain
this in the commit message, but I'm still uncertain of the cause of the
problem:
Author: João Távora <joaotavora@gmail.com>
Date: Fri Jul 10 01:47:10 2020 +0100
Fix Eldoc problem when loading on Emacs 26.3
When defining the obsolete variable alias for old
eldoc-documentation-function (which now points to the newer
eldoc-documentation-strategy), one gets the error "don't know how to
make a localized vareiable an alias". I'm not sure, but I suspect
this is because Eldoc is preloaded in Emacs 26.3 and the
eldoc-documentation-function variable is already set locally by some
Elisp buffer.
Uninterning the symbol shortly before defining the alias seems to fix
it.
Separately, I also noticed that calling `package-install` for Eldoc in
Emacs 26.3, will _not_ load eldoc, and neither will `require`. One has
to `load` it specifically, even after calling `package-initialize`.
João
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Byte-compilation warning in eldoc.el
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
2 siblings, 0 replies; 10+ messages in thread
From: Eli Zaretskii @ 2020-07-10 7:43 UTC (permalink / raw)
To: João Távora; +Cc: emacs-devel
> From: João Távora <joaotavora@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Fri, 10 Jul 2020 08:20:37 +0100
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > In toplevel form:
> > emacs-lisp/eldoc.el:540:2: Warning: unintern called with 1 argument, but
> > requires 2
>
> 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.
That's because we want the optional 2nd argument be explicitly
mentioned.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Byte-compilation warning in eldoc.el
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
2 siblings, 0 replies; 10+ messages in thread
From: Noam Postavsky @ 2020-07-10 9:36 UTC (permalink / raw)
To: João Távora; +Cc: Eli Zaretskii, Emacs developers
On Fri, 10 Jul 2020 at 03:20, João Távora <joaotavora@gmail.com> wrote:
> When defining the obsolete variable alias for old
> eldoc-documentation-function (which now points to the newer
> eldoc-documentation-strategy), one gets the error "don't know how to
> make a localized vareiable an alias". I'm not sure, but I suspect
> this is because Eldoc is preloaded in Emacs 26.3 and the
> eldoc-documentation-function variable is already set locally by some
> Elisp buffer.
>
> Uninterning the symbol shortly before defining the alias seems to fix
> it.
makunbound might fit better.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Byte-compilation warning in eldoc.el
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
2 siblings, 2 replies; 10+ messages in thread
From: Stefan Monnier @ 2020-07-10 14:41 UTC (permalink / raw)
To: João Távora; +Cc: Eli Zaretskii, emacs-devel
> 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.
> 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.
[ Using it with a second argument is quite different, because then it
usually corresponds to a simple `remhash`. ]
> When defining the obsolete variable alias for old
> eldoc-documentation-function (which now points to the newer
> eldoc-documentation-strategy),
Which reminds me: I think it'd be better not to make it an alias.
> Separately, I also noticed that calling `package-install` for Eldoc in
> Emacs 26.3, will _not_ load eldoc, and neither will `require`.
Not sure what you mean with the "_not_ load" part, but as for `require`,
it's normal because it's preloaded.
Stefan
^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: Byte-compilation warning in eldoc.el
2020-07-10 14:41 ` Stefan Monnier
@ 2020-07-10 15:05 ` Drew Adams
2020-07-10 15:31 ` João Távora
1 sibling, 0 replies; 10+ messages in thread
From: Drew Adams @ 2020-07-10 15:05 UTC (permalink / raw)
To: Stefan Monnier, João Távora; +Cc: Eli Zaretskii, emacs-devel
> > 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.
Why? What are those 99% (or what is the 1%)?
What's the (undocumented) behavior of calling it
with no second arg? Isn't it just to use the
value of `obarray' (the standard obarray)?
What's the reason that the 2nd arg isn't called
out as optional, with the doc string saying that
it defaults to the value of variable `obarray'?
What's good about having an optional parameter
that's not advertised as such? What's the real
point here, that calls for this exception?
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Byte-compilation warning in eldoc.el
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
1 sibling, 1 reply; 10+ messages in thread
From: João Távora @ 2020-07-10 15:31 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Eli Zaretskii, emacs-devel
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> 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'?
>> 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.
>> Separately, I also noticed that calling `package-install` for Eldoc in
>> Emacs 26.3, will _not_ load eldoc, and neither will `require`.
>
> Not sure what you mean with the "_not_ load" part, but as for `require`,
> it's normal because it's preloaded.
Sorry, it means two different things:
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?
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.
João
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Byte-compilation warning in eldoc.el
2020-07-10 15:31 ` João Távora
@ 2020-07-10 21:29 ` Stefan Monnier
2020-07-10 21:48 ` João Távora
0 siblings, 1 reply; 10+ messages in thread
From: Stefan Monnier @ 2020-07-10 21:29 UTC (permalink / raw)
To: João Távora; +Cc: Eli Zaretskii, emacs-devel
>>> 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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Byte-compilation warning in eldoc.el
2020-07-10 21:29 ` Stefan Monnier
@ 2020-07-10 21:48 ` João Távora
2020-07-10 22:08 ` Stefan Monnier
0 siblings, 1 reply; 10+ messages in thread
From: João Távora @ 2020-07-10 21:48 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Eli Zaretskii, emacs-devel
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> 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).
Sounds reasoable. But can these changes ever reach Emacs 26.3? How?
Only by updating package.el itself, right? Is that possible?
I'm afraid I don't have time to do either of those things, right now, so
I'm just going to hack it in Eglot, for now. But I'm also reporting
this as a bug, so we can track it.
João
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Byte-compilation warning in eldoc.el
2020-07-10 21:48 ` João Távora
@ 2020-07-10 22:08 ` Stefan Monnier
0 siblings, 0 replies; 10+ messages in thread
From: Stefan Monnier @ 2020-07-10 22:08 UTC (permalink / raw)
To: João Távora; +Cc: Eli Zaretskii, emacs-devel
>> 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).
> Sounds reasoable. But can these changes ever reach Emacs 26.3?
Probably not, no, but in a few years nobody will care.
The important thing is to fix it in `master` so that in a few years the
problem is solved.
Stefan
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2020-07-10 22:08 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
2020-07-10 21:48 ` João Távora
2020-07-10 22:08 ` Stefan Monnier
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).