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.
Related
Update
Apparently, the auto-complete package is not the culprit.
Emacs fails to download melpa archive.
A quick google search indicates that this is a reappearing problem both on windows and unix machines.
As there are already threads concerning failed to download 'melpa' archive (none of which helped unfortunately) this thread may or may not be closed.
Inital Question
I'm trying to set up emacs for Common Lisp.
I installed sbcl and the slime package.
Some time ago I used to have auto completion for Common Lisp keywords in emacs such that - while typing - it suggested a word via a greyed out completion (TAB for acceptance) or via drop down or both. (I can't remember exactly.)
I'm struggling to get this working again.
At https://github.com/purcell/ac-slime it is suggested to first install auto-complete but when I type package-list-packages there is no such package. (But there are plenty named auto-complete-*).
(I set up Melpa with:
(require 'package)
(add-to-list 'package-archives
'("melpa" . "http://melpa.org/packages/")))
The provided link http://cx4a.org/software/auto-complete/ is dead as well.M-x install-package [RET] auto-complete [RET] also fails. Emacs says: [No match]
So my question is:
If there is no auto-complete package anymore, what is a good way to set up Common Lisp auto completion in emacs in the way mentioned above (greyed out word or dropdown)?
The current home-page for auto-complete is https://github.com/auto-complete/auto-complete
Installing it should be enough to allow you to use ac-slime (there is also a completion version using company).
Here is how I got it to work.
Download the .ZIP archive with repository here.
Unzip
Run M-x package-install-file
On the prompt, specify the path to the downloaded repository and the file named auto-complete.el.
Make sure that installation returns something along the lines of "Successful"
Add this line to your Emacs initialization file (.emacs):
(ac-config-default)
To auto-complete in SLIME, follow similar step to install ac-slime (requires SLIME and Auto-complete)
P.S. There is another package called company (stands for Complete Anything), which is quite good as an alternative. I am trying it out now. Getting it to work was very simple.
I have just upgraded org-mode to the latest available in ELPA. According to the official documentation, the installation has to be done in fresh emacs session where no org-related scripts/files have been loaded. The installation is successful, and org-version reports that I have updated to 8.2.6 (from 7.9.3f). However, as soon as I put back my old org-related scripts, and reload emacs, I'd get 7.9.3f when I run org-version. To track what's causing it I retrace my steps by adding my org-related scripts one by one. I found out that when I add back (require 'org-publish), the version downgrades to the built-in one. I don't know why this is happening.
The problem was primarily due to the way my emacs initializes (initialization script).
In the latest version of org (8.2.6 at the time of writing), org-publish is now ox-publish, so I needed to call (require 'ox-publish') instead. I think calling org-publish or any older version modules causes the confusion in the setup.
However, after changing the reference, I got an error about ox-publish not being found.
To trace the problem further, I removed all org-related scripts from my init.el (that's how I named my initialization script), and run emacs again. When I ran org-version that time, I saw that it's 8.2.6.
To check if ox-publish is getting loaded, I used the scratch buffer, and executed (require 'ox-publish') manually; it returned fine, confirming that the module was actually loaded. This means that ox-publish is only getting loaded after initialization.
My first work around was to load my org publishing script after initialization using the after-init-hook:
(add-hook 'after-init-hook (lambda() (load-file "/path/to/org-publish-project.el")))
That solved the problem, and I could see my org installation upgraded correctly. However, I didn't feel good about loading the script through after-init-hook. Some people in the official orgmode mailing list suggested that I should check if I'm calling (package-initialize) in my init.el. I didn't. The operation loads the packages installed through the package manager. If it's not specified in the init script, it will be called after initialization by default. Learning that, I added a call to (package-initialize) somewhere at the beginning of my init.el. Afterwards, I called load-file to my org publishing script directly.
(load-file "/path/to/org-publish-project.el")
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'm trying to get JSHint to work with Flymake.
jshint is indeed installed in /opt/bin and works. /opt/bin is in Emacs' exec-path.
I've followed the directions on the EmacsWiki and have this in my init.el:
(defun flymake-jshint-init ()
(let* ((temp-file (flymake-init-create-temp-buffer-copy
'flymake-create-temp-inplace))
(local-file (file-relative-name
temp-file
(file-name-directory buffer-file-name))))
(list "jshint" (list local-file))))
(setq flymake-err-line-patterns
(cons '("^ [[:digit:]]+ \\([[:digit:]]+\\),\\([[:digit:]]+\\): \\(.+\\)$"
nil 1 2 3)
flymake-err-line-patterns))
(add-to-list 'flymake-allowed-file-name-masks
'("\\.js\\'" flymake-jshint-init))
When I open JavaScript files, my modeline appears as:
[(Javascript Flymake* AC)]
This is odd because the * usually doesn't appear when I'm using Flymake with C++ or Python. According to the Flymake docs, Flymake* means "Flymake is currently running." However, Flymake isn't showing any errors.
I've checked the *Messages* buffer but it only lists a few lines of Fontifying foo.js... (regexps...................). No errors.
Other suggestions?
Try using M-: to execute (setq flymake-log-level 3), which will cause flymake to print debug info into *Messages*.
Here's how I use flymake with jslint, which works nicely for me -- that code might give you a clue about what's going wrong for you.
You might also consider js2-mode, which provides some language-aware lint-like warnings without resorting to running an external process.
I found a project called jshint-mode and tried that. It created a buffer called *jshint-mode* which revealed the error: JSHint couldn't find the formidable module.
I ran M-x setenv in Emacs to set NODE_PATH so that jshint could find the formidable library. I also set NODE_PATH in /etc/profile.
jshint-mode did not work for me (I use Linux Mint 14 'Nadia') -- I was getting errors with "flymake's configuration" when it runs curl to talk to the Node.js instance running the jshint script. This was perplexing, and I'm not familiar with ELisp to go around messing with the .el files.
I solved this by instead going straight to the Emacs flymake project fork on github which now has support for jshint built-in (it needs to be installed as npm -g install jshint which in turn requires you to install npm and node.js if you haven't already). This made things work.
One more caveat: on my Linux box, node was an executable already existing in /usr/sbin and I had to make a symbolic link named node in /usr/local/bin to override the former. This was necessary as the Node.js binary for Linux Mint (possibly Ubuntu as well, I haven't checked) is named nodejs instead and will cause many scripts written assuming a binary name of node to fail. You can test this by typing node: if it is the pre-existing binary it generally returns to the prompt silently, but if it is Node.js it prompts you with a > (you can Ctrl-D to quit out of there)