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').
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.
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.
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.
I'm using the latest nXhtml checked out from the repo, and using GNU Emacs version 24.0.91.1. When I open a PHP file it shows as un-syntax-highlighted text, and I get a compile error:
Error: Wrong type argument: number-or-marker-p, nil
and a message in the log:
File mode specification error: (cl-assertion-failed (functionp byte-compiled-fun))
I'm avoiding my .emacs and .emacs.d by running emacs with this command:
emacs -Q --eval '(load "/path/to/nxhtml/autostart")' /path/to/nxhtml/tests/in/heredoc.php
Even if you don't have a fix, how can I go about debugging this issue?
There seem to be a fair amount of such wrong-type-argument errors lately with the development version of Emacs (24). This might represent an Emacs bug. Or it might represent an nXhtml bug.
I suggest starting by notifying Lennart, the nXhtml author, trying to give him a clear recipe, starting from emacs -Q.
If that doesn't help, consider filing an Emacs bug: M-x report-emacs-bug.
To try to debug it a bit yourself, be sure to load only source files (e.g. for nXhtml), i.e., *.el, not *.elc, starting preferably with emacs -Q (no init file). Do M-x set-variable debug-on-error t to see where the error is raised. Then perhaps use M-x debug-on-entry FUNCTION, where FUNCTION is the function where the error seems to have been raised. Then step through the Emacs debugger, hitting d to step and c to skip through a step.
But again, I suggest starting with Lennart.
Try the newest version of Emacs.
I had the same problem (on Windows 7):
Error: Wrong type argument: number-or-marker-p, nil
at line 1471 of nxhtml-loaddefs.el.
Nxhtml seems fine on Emacs 24.1.50.1 (23 April 2012).
http://alpha.gnu.org/gnu/emacs/windows/?C=M;O=D
I have decided to check out Emacs, and I liked it very much. Now, I'm using the Emacs Starter Kit, which sort of provides better defaults and some nice customizations to default install of Emacs.
I have customized it a little, added some stuff like yasnippet, color-themes, unbound, and other stuff. I've set up a github repository where I keep all of the customizations so I can access them from multiple places or in case something goes bad and I lose my .emacs.d directory.
All of this is very nice, but there is a problem: Emacs takes about 1-2 seconds to load. AFAIK I can compile individual .el files with M-x byte-compile-file to .elc, and it works. But there are a lot of .el files, and I wonder if there is a way to compile them all with a simple command or something, to speed up the loading of Emacs. My Emacs is not always open, and I open and close it quite frequently, especially after I've set it up as a default editor for edit command in Total Commander to get used to it faster (yeah, windows xp here).
My Emacs version is 22.3. And yes, the default Emacs installation without any customizations fires up instantly.
I am not sure which version is preferred when loading, the .el or compiled .elc one by the way O.o
So, is there an elisp command or Emacs command line switch to make Emacs byte-compile everything in .emacs.d directory?
C-u 0 M-x byte-recompile-directory
will compile all the .el files in the directory and in all subdirectories below.
The C-u 0 part is to make it not ask about every .el file that does not have a .elc counterpart.
To automatically byte compile everything that needs byte compiling each time I start emacs, I put the following after my changes to load-path at the top of my .emacs file:
(byte-recompile-directory (expand-file-name "~/.emacs.d") 0)
Surprisingly, it doesn't add much to my startup time (unless something needs to be compiled).
To speed up my emacs, I first identified the slow parts using profile-dotemacs.el and then replaced them with autoloads.
You can use the --batch flag to recompile from the command line.
To recompile all, do
emacs --batch --eval '(byte-recompile-directory "~/.emacs.d")'
or to recompile a single file as from a Makefile,
emacs --batch --eval '(byte-compile-file "your-elisp-file.el")'
This is swaying a bit from the question, but to solve the problem of loading slowly you can use the new daemon feature in Emacs 23.
"If you have a lot of support packages,
emacs startup can be a bit slow.
However, emacs 23 brings emacs
--daemon, which enables you to start emacs in the background (for example
when you log in). You can instantly
pop up new emacs windows (frames) with
emacsclient. Of course, you could
already have an emacs 'server' in
older versions, but being able to
start it in the background makes this
a much nicer solution"
From http://emacs-fu.blogspot.com/2009/07/emacs-23-is-very-near.html
The command I use is M-x byte-force-recompile RET, it then asks the directory so, for example, I give it ~/.emacs.d/elpa/. It then recompiles everything in there, usually no need to delete .elc files first or mess with it in other ways.
For my using spacemacs, the command is spacemacs/recompile-elpa. The command byte-recompile-directory does not compile any file.