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/
Related
Yesterday, after Ubuntu (or maybe Dell) installed some updates and I restarted, my snap applications were not showing on my sidebar, nor are they present in "show applications" or a normal search.
They are still installed and snap list still shows them, and they will still run via snap run <application>.
I've tried uninstalling them all (although I did not use --purge when I ran snap remove <application>), followed by uninstalling snap itself, then re-installing everything. They are still present but not showing up.
More searching has brought me to sites referencing the XDG_DATA_DIRS environment variable (explained HERE). If I understand correctly this should link all the folders where applications are stored, and the paths within should be separated by colons, not spaces. Thus I ran echo $XDG_DATA_DIRS and was rewarded with:
/usr/local/share/:/usr/share/:/var/lib/snapd/desktop /var/lib/snapd/desktop /var/lib/snapd/desktop
So I suspect my issue is the facts that the snapd directory is listed three times, and it is separated by spaces.
Does anyone have any ideas how I could fix this? I suspect, but am not certain that this is the issue.
I'm on Ubuntu 20.04, using fish shell.
I've found THIS post showing a possible solution, and upon running sudo ag "XDG_DATA_DIRS=" / 2>/dev/null | grep -v snap (and waiting a while) I got the following output (minus a few auth.log references which I've removed) Apologies for the big, possibly irreverent, "data dump"
/etc/profile.d/xdg_dirs_desktop_session.sh:4:DEFAULT_XDG_DATA_DIRS='/usr/local/share/:/usr/share/'
/etc/profile.d/xdg_dirs_desktop_session.sh:18: XDG_DATA_DIRS="$DEFAULT_XDG_DATA_DIRS"
/etc/profile.d/xdg_dirs_desktop_session.sh:21: XDG_DATA_DIRS=/usr/share/"$DESKTOP_SESSION":"$XDG_DATA_DIRS"
/etc/profile.d/apps-bin-path.sh:12: export XDG_DATA_DIRS="/usr/local/share:/usr/share"
/etc/X11/Xsession.d/55gnome-session_gnomerc:17: XDG_DATA_DIRS=/usr/share/gnome:/usr/local/share/:/usr/share/
/etc/X11/Xsession.d/55gnome-session_gnomerc:19: XDG_DATA_DIRS=/usr/share/gnome:"$XDG_DATA_DIRS"
/etc/X11/Xsession.d/60x11-common_xdg_path:5:DEFAULT_XDG_DATA_DIRS='/usr/local/share/:/usr/share/'
/etc/X11/Xsession.d/60x11-common_xdg_path:17: XDG_DATA_DIRS="$DEFAULT_XDG_DATA_DIRS"
/etc/X11/Xsession.d/60x11-common_xdg_path:20: XDG_DATA_DIRS=/usr/share/"$DESKTOP_SESSION":"$XDG_DATA_DIRS"
/usr/share/doc/gnome-software/README.md:24:$ XDG_DATA_DIRS=install/share:$XDG_DATA_DIRS ./install/bin/gnome-software
I'm not certain I have found the correct places to think about updating the environment variable, as none of these referenced /var/lib/snaped/desktop...And this might not be the issue causing the problem at all! Any help would be welcome!
You are running into https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1957948 which will require a fix in snapd.
Using a different shell as your login shell, and then executing fish once it has started, is the right workaround.
I am also having the same problem (suddenly Firefox disappeared in Gnome Shell) and I'm using Ubuntu 21.10 with fish shell. And just like you I could not figure out what caused this XDG_DATA_DIRS modification with the separation by spaces. Because you apparently also use fish I tried switching back to bash as login shell (chsh -s /bin/bash), rebooted and voila, the desktop files are loaded again. After that I set fish as the command to start with in gnome-terminal.
TLDR: My quickfix/workaround was chsh -s /bin/bash to switch to bash as login shell (instead of fish) and reboot.
After following Zanchy's links and reading around the issue I found the solution here!!!
I needed to replace
set XDG_DATA_DIRS $XDG_DATA_DIRS $snap_xdg_path
with
set XDG_DATA_DIRS $XDG_DATA_DIRS:$snap_xdg_path
in /usr/share/fish/vendor_conf.d/snapd.fish
Update: After another update I found my snaped.fish file had reverted, and I needed to edit it again - so this solution may need to be re-applied until fish updates it's snap?
I had the same problem on Linux Lite 6.0 (basically same as Ubuntu 22.04). Snap applications (Spotify, Prospect Mail) would not show up our could not even be found when searching for them. Just logging out and back in again put the application shortcuts in the Menu and all worked fine.
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 have problem with running EplSite program. This program is written in Perl. I'm new in Perl. I tried to run it, but Perl command line displays errors. Can you help me? https://sourceforge.net/projects/eplsiteetl/
CODE one of many files: http://pastebin.com/yM9srKGn
Don't waste your time with EplSite ETL. There's no useful documentation. I've wasted two days trying to install it with no success. Maybe something would work if there was some info about using hypertextperl.pl (especially with Apache server on Windows) but link to developer's site is dead.
Just find some other software for ETL, because if you somehow manage to install Eplsite ETL you would have to guess how to use it properly. It's not worth the time and effort.
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.
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.