search

alphapapa / burly.el

Save and restore frames and windows with their buffers in Emacs
GNU General Public License v3.0
301 stars 14 forks source link

Any idea how to fix `burly-bookmark-handler: Symbol’s value as variable is void: _`? #64

Closed hubisan closed 5 months ago

hubisan commented 5 months ago

When I call burly-open-bookmark and then select a bookmark to open I get burly-bookmark-handler: Symbol’s value as variable is void: _ and the bookmark is not opened. This started to happen when I updated all my packages. Reinstalled Emacs and all packages, but I still get this error.

Then I tried to debug the error and tracked it down to burly--bufferize-window-state. But as soon as I debug this function (or evaluate it) the error disappears. If I restart Emacs the error is back and evaluating burly.el or just burly--bufferize-window-state makes it go away.

Might have something to do with those two warnings:

burly.el 389 warning reference to free variable  _  
burly.el 439 warning reference to free variable  _

Thanks in advance :-)

alphapapa commented 5 months ago

Short answer: Stop running unreleased versions of Emacs. I don't mean to be rude, but that is the problem here, that you are running pre-release code that contains this recent change: https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=806759dc0a6a3b049ce35d0497011464e5fc4dcb

You'll have to forgive me if I sound a little grumpy about this, but this is not the first time this specific issue has been reported to me as a bug on one of my packages, when it's nothing to do with me, and appears to be caused again by running unreleased versions of Emacs. See https://github.com/alphapapa/bufler.el/issues/70#issuecomment-1949928135.

The upstream change in question is not even present on the emacs-29 branch, but only in master, so how are you ending up with that code in a "29.2.50" build? It should only be present in a "30.0.50" build. (Is this another case of Straight.el pulling a version of map.el from master into a build from emacs-29? If so, then whoever is responsible for that behavior, please stop.)

Since this problem only happens on an unreleased version of Emacs, and since this package hasn't changed recently (so no changes in this package could have caused it), you should report this bug to Emacs upstream, not to whichever package you happen to notice the problem while using. Essentially the only reason for using an unreleased version of Emacs should be to discover bugs before release and report them to the Emacs maintainers (but only if a bug actually exists, and running a mixed installation of "29.2.50" and "30.0.50" is more like a user-error).

Also, since the bug goes away when you reevaluate the code, you should probably package-recompile.

@monnier I don't know if there's really a bug to be fixed or if this is just another case of mixed library versions, possibly Straight.el pulling an unreleased map.el from master into an emacs-29 branch build, or what.

@progfolio Not to blame you, but since Straight.el seems to be implicated in at least one of these two cases, it seems like a good idea to bring you into the loop.

monnier commented 5 months ago

Short answer: Stop running unreleased versions of Emacs. I don't mean to be rude, but that is the problem here, that you are running pre-release code that contains this recent change: https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=806759dc0a6a3b049ce35d0497011464e5fc4dcb

Indeed, it looks like I forgot that map.el is also distributed via GNU ELPA for older Emacsen.

alphapapa commented 5 months ago

Indeed, it looks like I forgot that map.el is also distributed via GNU ELPA for older Emacsen.

Yes, however ELPA still has v3.3.1, which is the version distributed with Emacs 29. AFAICT the problem is that a few users are getting map from master loaded into a non-master build that has the non-master version of pcase. But that can't happen without something like DOOM and/or Straight forcing it to happen.

So the question seems to be, who and what is causing an unreleased version of map from master to be installed into an older, non-master build of Emacs?

hubisan commented 5 months ago

Thank you for taking the time to identify the problem. Indeed, I am using straight.el.

And it installed map version 3.3.1 from https://github.com/emacs-straight/map.git.

alphapapa commented 5 months ago

Thank you for taking the time to identify the problem. Indeed, I am using straight.el.

And it installed map version 3.3.1 from https://github.com/emacs-straight/map.git.

That is not map 3.3.1. Look here: https://github.com/emacs-straight/map/blob/613340b2b8770ce53b6d2c66491ce0f67a7e52be/map.el#L611 The version header at the top of the file is still at 3.3.1, but that code is copied from emacs.git's master branch as of last week, having changes that will be released in Emacs 30. That's producing "chimera" installations having files mixed from multiple Emacs versions, including unreleased ones.

progfolio commented 5 months ago

@progfolio Not to blame you, but since Straight.el seems to be implicated in at least one of these two cases, it seems like a good idea to bring you into the loop.

Thanks. please see:

https://github.com/alphapapa/bufler.el/issues/70#issuecomment-1956827054 https://github.com/radian-software/straight.el/issues/1146#issuecomment-1956957385