* 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).