Since some time (but I didn't change anything in .emacs), I have some errors with emacs's behaviour :
Remember mode will not kill the temporary buffer on "Ctl-C Ctl-C"
Orgmode will not refile any entry
Both operations complain with error "Not bookmark format"
I restored an old .emacs to make sure that I didn't mess it up but the error persists.
Where can I investigate to find out the problem ?
I have Emacs 24.2.1 since end of august.
The built in orgmode version is 7.8.11 (I see 7.9.2 is out ...)
It's always best to start debugging problems such as this by seeing if the problem still happens when you ignore your init file altogether - try starting emacs with --no-init-file and seeing if you still get the problem. If you don't then it's clearly something in your init file.
You can also get odd behaviour if you've got a local install of Org-mode in addition to the one bundled with Emacs itself - eg if you pull in a newer one through ELPA. If you have a local install through ELPA then you can try uninstalling the Org-mode package and trying again using the built-in Org-mode.
I have something similar to the following in my init file to make it switch to the ELPA-installed Org-mode to avoid such problems (this variant is untested so forgive me if it's not quite right):
(package-initialize) ; load and initialise ELPA-installed packages
(org-reload) ; restart Org-mode with the ELPA package
I filed a bug to the emacs team and they found out that the error comes from a corrupted bookmark file.
I removed my ~/.emacs.d/bookmark file (it was empty) and everything is fine now.
Related
My ultimate goal is to get magit working again with Emacs 27.1 on openSUSE Tumbleweed, but the problem ahead of that is getting (melpa?) package management working - so that is really what this post is about. I run into these problems with other packages; magit is just the example, because want teh awesome. I had not installed any packages recently with Emacs 26.3, but my assumption is that it was OK. Magit was certainly working.
Attempt is to start from bare wood:
rm .emacs
rm -r .emacs.d
Need melpa to get magit, so I create a new .emacs with only this inside:
(require 'package)
(add-to-list 'package-archives
'("melpa" . "https://melpa.org/packages/") t)
(package-initialize)
Restarting emacs, the package-list command shows a ton of melpa stuff in there (yay!). Including magit!
So I install that (version 20200820.227) by clicking on the Install button, then "Yes" when it asks for confirmation. Here is what happens at the end of the "Messages" buffer:
Wrote /home/tcarroll/.emacs.d/elpa/magit-20200820.227/magit-autoloads.el [2 times]
Loading async...done
Contacting host: melpa.org:80
error in process sentinel: async-handle-result: End of file during parsing
error in process sentinel: End of file during parsing
At this point magit is "installed" - and magit-status even works. But if I restart Emacs, running magit-status results in:
load-history-filename-element: Wrong type argument: stringp, (require . info)
...and I don't actually get any Git status.
Some output I get that I don't recall ever getting when starting Emacs 26.3:
Warning: game dir '/var/games/emacs': Permission denied
Loading loadup.el (source)...
dump mode: nil
Using load-path (/usr/share/emacs/27.1/site-lisp /usr/share/emacs/site-lisp /usr/share/emacs/27.1/lisp /usr/share/emacs/27.1/lisp/emacs-lisp /usr/share/emacs/27.1/lisp/progmodes /usr/share/emacs/27.1/lisp/language /usr/share/emacs/27.1/lisp/international /usr/share/emacs/27.1/lisp/textmodes /usr/share/emacs/27.1/lisp/vc)
Loading emacs-lisp/byte-run...
Loading emacs-lisp/byte-run...done
Loading emacs-lisp/backquote...
Several screenfuls of "Loading" this and that; I can include more if helpful. My speculation is that this has something to do with the new portable dumper?
There are a great many clean-shaven yaks in my vicinity (and the rest are scared). Trying to keep this from getting too long.
Adding new info at request:
openSUSE Tumbleweed update today to emacs. Still at version 27.1 but dated today:
GNU Emacs 27.1 (build 1, x86_64-suse-linux-gnu, GTK+ Version 3.24.22, cairo version 1.16.0) of 2020-08-25
Toggled on debugging via toggle-debug-on-error. Installation behavior nothing new, unfortunately; still
async-handle-result: End of file during parsing
Again, thanks for any help!
Turns out the /usr/bin/emacs is a script not a binary (old news to most of you, I'm sure) and it decides between different ways of invoking Emacs. For me, the key thing is that at the end it does this:
exec -a emacs /usr/bin/emacs-gtk
which causes Emacs to emit lots of messages about "Loading" this and that, including loadup.el, and finally not work properly with regard to packages (Org and Magit both affected, probably others).
When I invoke this instead:
/usr/bin/emacs-gtk
...I don't see any of those "Loading" messages. And Magit and Org both work fine.
From my limited understanding of this "exec -a" thng it seems that there "should" not be this difference in behavior, so maybe it is some dumb thing in my environment that I overlooked. But stuff works now.
After updating outdated packages, auto-complete (and its dependencies like ac-slime) broke with the error "Required feature 'popup' is not provided". Inspection of the elpa directory revealed that popup is there. Recompilation of everything in elpa directory with byte-recompile-directory did not solve the problem (both popup.el and popup.elc are present but auto-complete still fails).
PS. Further inspection revealed that some other packages are failing because xml-prc is absent, but Emacs shows that it is installed and it is indeed is present in elpa directory.
What are my steps to make Emacs work again?
Since there are no other answers yet (I hope there will be a real one!), here is what have worked in meantime:
Basically, during the package update something has gone wrong -- don't know what exactly. Usually, byte-recompile-directory on elpa directory helps to sort out the issue: it recompiles all the package files and after restart Emacs is usually can load them without problems. This time, however, it didn't help. So I used a more drastic measure: I deleted elpa directory form ~/.emacs.d (or actually I moved it away), and restarted Emacs.
My .emacs file contains the list of packages that need to be installed if missing, so all the package re-installation happened automatically, I just needed to wait (circa 30 min) for Emacs to start.
(This is a well known trick, but if you interested, here is the source on github)
But this solution is not ideal, I was hoping for something cleaner.
Using the latest emacs 24.3 I want rainbow parenthesis for my lisp editing. I'm following the instructions on this page.
Here is what I get after I setup everything:
File error: Cannot open load file, rainbow-delimiters
To ensure normal operation, you should investigate and remove the
cause of the error in your initialization file. Start Emacs with the
`--debug-init' option to view a complete error backtrace.
The byte compile proceded fine and created a .elc file. Is there a missing step in the instructions? How would emacs know where this compiled is located if there is no path mentioned anywhere in the .emacs file?
Not a direct answer I'm afraid but I would recommend watching this as rainbow-delimiters is available in MELPA and this will make managing Emacs extensions MUCH easier.
Installed GNU Emacs 23.2.1 (i686-pc-linux-gnu) and I'm getting constant save errors. The following line is repeated over and over again with maybe 30sec intervals.
byte-code: Beginning of buffer [6 times]
Error Writing Table: #<semanticdb-table ctype.h>
Save Error: "\"Error in macro \\\"name\\\"\"": /home/user/.emacs.d/semanticdb/!usr!include!semantic.cache
Any useful tips as to why or maybe even a solution? Stripped my .emacs only to the following 2 lines but the problems still persists
(global-ede-mode 1)
(semantic-mode 1)
Tried deleting the cached files under the /sematicsdb/ folder but still the error pops up.
There is a macro somewhere in one of your header files that CEDET can't handle. Newer versions of CEDET (the one from the bzr repository on cedet.sf.net) work around the problem first by fixing some macro parsing problems, and secondarily by ignoring those problems during a save.
The newer version of CEDET that doesn't come with Emacs has a different install than what is in Emacs, but it should still work if you follow the installation instructions (which excludes 'semantic-mode').
I recently had to reimage my windows laptop, and emacs is now giving me a strange error:
"Starting new Ispell process [default]
Enabling flyspell mode gave an error"
I have aspell installed, and it is accessible via emacs. I have attached a picture to show this. I also have (setq-default ispell-program-name "aspell") in my emacs configuration. This same configuration works properly on my other windows machines. What might be the problem here? Image: Aspell in emacs-shell http://img145.imageshack.us/img145/4497/emacsaspell.jpg
You can add the line:
(setq flyspell-issue-welcome-flag nil) ;; fix flyspell problem
to your personal emacs initialization file (~/.emacs.d/init.el, ~/.emacs, ~/.emacs.el, whatever...) and that should bypass the problem for you.
EDIT: This it seems is not the best solution: see the comment below and see Dennis' answer for a better alternative.
EDIT2: As the comment below indicates, deleting the files recommended in this post causes problems when upgrading. If you followed the advice on this post and now regret it (sorry), then to reinstall the deleted files you want to type:
sudo apt-get --reinstall dictionaries-common
You should now be able to upgrade and follow Dennis' solution.
Google sent me here first so I thought I would add another common reason for this error message (at least on Ubuntu systems)
My ubuntu 10.10 fresh install had the following bug:
https://bugs.launchpad.net/ubuntu/+source/dictionaries-common/+bug/619015
which is fixed (as indicated in the link) by deleting
/usr/share/emacs/site-lisp/dictionaries-common/debian-ispell.el
/usr/share/emacs/site-lisp/dictionaries-common/flyspell.el
/usr/share/emacs/site-lisp/dictionaries-common/ispell.el
and all the .el .elc files in
/usr/share/emacs23/site-lisp/dictionaries-common
The reason it seems is the above files are already installed in the emacs23-common,
and the .el and .elc files retain the conflict on live systems (from reading the bug report).
I think there are other problems that can cause this error message, but this solved it for me, and I felt ubuntu is common enough for this to mensioned as another answer.
EDIT: There seems to be a less intrusive solution - see Dennis Sheil's answer
Blessings,
Tom
Writing an answer in order to mark this as accepted:
paprika's comment helped me track the problem -
"Did you check if aspell works outside of Emacs, i.e. something like cat foobar.txt |aspell -a -l en?"
Turns out aspell-en had not been installed. my bad.
I ran into this problem as well when upgrading to emacs24. My aspell was working fine. I tried some of the techniques here with dictinaries-common and settting flyspell-issue-welcome-flag to nil as above but running emacs24 kept hanging on ispell.
I ended up purging my previous emacs23 install (making sure all their .el/.elc files were deleted in the uninstall), making sure there were no emacs processes in the background, and removing my cruft collecting ~/.emacs.d directory (taking care to save code in there I still needed).
I then freshly installed emacs24 (24.1.50.1 as it happens) and ran it and flyspell worked flawlessly.