I just finished upgrading to emacs 24.5. After starting up emacs, I got the error message:
"run-hooks: Args out of range: #, 9017, 10107"
This error does not show up when using emacs 24.3,
I suspect it's related to yassnippet but not sure. Does anybody encounter similar problem?
I was running emacs 24.5 for quite a few months and never encountered that particular error. It is almost certainly being caused either by something in your init file or one of the packages you have installed. Try running with -q and see if you get the error - if you don't, then it is definitely something being done in your innit file.
In general, compiled elisp is backwards compatible, but I have found it good practice to re-compile all *.elc files when you upgrade to a new version. If you haven't done that, highly recommend doing that and see if that fixes the problem.
Use the --debug-init command line option when starting emacs to get a more meaningful backtrace which will help you identify where in your init the problem is being generated. At the vary least, this should provide you with enough info to post a more targeted quesiton, which will usually provide more useful assistance.
Related
I use emacs org-mode heavily, but don't usually use emacs otherwise. I am still using emacs 25.3 but also have 26.3 installed. This evening, after a Windows Update (likely cause of the problem?), when I restarted emacs (runemacs) under 25.3 I received the following error message.
error: Required feature ‘ht’ was not provided
I have also tried running it under emacs 26.3 and receive a slightly more helpful error message "c:etc. etc. /AppData/Roaming/.emacs.d/elpa/ht-20190924.704/ht.elc failed to provide feature ‘ht’"
I have not changed or updated any of the packages in several weeks. So, it is unlikely to be a change in org-mode or emacs.
I have experimented around with a variety of different approaches but without any luck. Among other things I restored the elpa files and my customization files from a back-up of a couple of days ago without getting a different results.
package-list-package with emacs 25.3 works with the error message, and I can upgrade the packages (2) that can be upgraded. However that also makes no difference to the error message I receive when I restart emacs. This does imply that ht.elc is working since, without it, you can't install packages since the new package needs to have its hash code checked. If I delete the ht package and try to update packages without it, updates fail on the hash code check.
package-list-package with emacs 26.3 is a whole other problem which might be why I'm not using it. TLS connections fail, and it can't connect to melpa, orgmode.org, etc.
In any case, I can't load my customization files and can't use org-mode at this point. Anyone have any ideas, questions or suggestions?
Thanks in advance.
This is a solution, without being an answer.
Using package-list-packages, and looking at the details for the ht package, it showed an "alternative" version being available from melpa; same release number. So, I chose to install it and a refreshed list of packages then showed that I had the same version installed twice.
I then closed emacs and restarted it. It started with a similar error message, but this time referring to the dash package. Repeated the duplicate install process as described above.
I again closed emacs and restarted it, and now it loads and runs correctly.
I had tried previously to just delete the ht package from the elpa directory, but doing that and attempting to install a fresh package resulted in a shower of errors. I don't remember all of them but at least one of them was that emacs was unable to read the package signature.
So, problem solved, but I still have no idea why it occurred in the first place, since it had been weeks since I had updated any packages, nor why the restore of the directories from several days ago didn't solve the problem.
And before anyone yells at me about moving to the current emacs, I have now installed the missing dependencies and am running on 26.3.
I updated today my packages in emacs with ELPA and after the update I'm stuck with the
Variable binding depth exceeds max-specpdl-size
error.
Since it is not easy to debug, is it possible to downgrade the packages that were updated? Where can I find an ELPA log where I can get the previous version of these packages?
I second #lawlist's recommendation to (setq debug-on-error t) early in your ~/.emacs file. You can also use emacs --debug-init to get a similar result. This said, sometimes the kind of error you get here can also prevent the debugger from showing up. I recommend you M-x report-emacs-bug and describe the problem, along with any additional info you find, including the solution you found, if any.
As for downgrading a package, it's technically possible, but there is no UI support for it. And there's no log of package installs either. Please do mention this in the bug-report as well, since it's indeed a good idea to try and keep track of those things.
Sorry.
I came across this article
about speeding up the emacs startup.
I wanted to try it, but I get a segfault.
Has anyone managed to do this for recent emacs versions?
Here's the makefile I'm using:
emacs=/usr/local/bin/emacs
fast-emacs: /usr/local/bin/emacs ~/.emacs
$(emacs) -Q --batch -l "~/.emacs" \
--execute "(dump-emacs \"fast-emacs\" \"$(emacs)\")"
This trick stopped working sometime after emacs21, and dump-emacs now only works with the bootstrap temacs to turn it into a full-blown emacs. When emacs has been dumped once, it can't be dumped again.
The site-init.el trick referenced on the wiki might do the trick, but I suspect you're going to run into serious stability problems once you start including a bunch of packages in the image. All in all, really not worth it.
An another solution is posted on Reddit in the case if the linked page above is not working or dead, and the suggested solution should be faster too (time startup: 0.00 seconds).
http://www.reddit.com/r/emacs/comments/2rietp/dumpemacs_truly_speeds_up_emacs_startup/
For a couple of years I used to use the sierotki.el package (NonbreakableSpace) in Emacs for my LaTeX writing. It worked very well in my configuration (Ubuntu 12.04, emacs 23 or emacs 24 (24.2.1)). Some time ago I've installed the emacs-snapshot (emacs 24.3.50.1) (from ppa:cassou/emacs ppa) and sierotki.el doesn't work anymore (without any errors).
Anybody knows what is wrong?
For the sake of completeness, the package just inserts ~ (nonbreakable space in LaTeX) after one-letter words (like I, a in English, or many others in my native language).
The reason is that sierotki.el used to use the variable last-command-char, which was changed to last-command-event in more recent Emacsen. You might want either to upgrade sierotki.el (I contacted the author some time ago with this fix, and he applied it), or fix it yourself.
This is my first post and I am hoping someone can point me in the right direction. I have tried Google but am not coming up with anything; actually, there are hardly getting any hits so I assume this is going to be a pretty obscure error.
I am trying to run a perl application (squeezecenter-7.3.3) on Solaris 10 and get the following error:
"ld.so.1: perl: fatal: relocation error: file /opt/squeezecenter-7.3.3/CPAN/arch/5.10.0/i86pc-solaris/auto/Class/XSAccessor/Array/Array.so: symbol get_next_arrayindex: referenced symbol not found"
ld.so.1 is in the search path, but I can't figure out what—ld.so.1 or Array.so—is causing the error. Any help will be appreciated.
Thanks
LATE UPDATE 2009-12-04
The current version of Class::XSAccessor contains both Class::XSAccessor itself and Class::XSAccessor::Array. It does not use AutoXS.pm to generate AutoXS.h any more but ships a static copy. Therefore, the problem giving rise to the question shouldn't occur (ever) again.
While Chris Simmons' idea is a good one, this is most certainly not the problem you're having. It is most likely an incompatibility between the version of Class::XSAccessor::Array you're using and the AutoXS::Header version it was compiled with.
A practically guaranteed* fix would be to reinstall Class::XSAccessor from CPAN. It should pick up a compatible version of AutoXS::Header. Maybe you should also post on the SlimDevices/Logitech forum about this.
On a more general note, as the author of both modules in question, I'm not sure why this problem is occurring at all. The dependency on version 1.02 of AutoXS::Header is part of the most recent Class::XSAccessor::Array release. Therefore, if dependencies are met correctly, everything should be fine. It may be some peculiarity of how the SqueezeCenter folks update their bundled modules. If not, feel free to get them in touch with me.
*The one problem remaining may be that the Class::XSAccessor::Array that comes with SqueezeCenter is prefered over the one you installed from CPAN (potentially into the system). In that case, you can try to install it into your /opt/squeezecenter.../CPAN directory.
Reinstall the offending module. Run this as root:
cpan -i Class::XSAccessor::Array Class::XSAccessor
Or manually install it.