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.
Related
I'm a noob at setting up LaTeX and I'm completely stuck. I had a broken MikTex + TexStudio setup that the previous owner of my work computer left behind (I also mention that I recently upgraded from Windows 10 to Windows 11). Unable to fix it, I decided to just wipe out everything and start clean. I uninstalled TexStudio and MikTex (also deleted all the files in AppData, etc.) and I installed TexLive (and gave the PC a restart as prescribed) to use it in VS Code (which I already had). All the guides I found say that once I install the LaTex Workshop extension in VS Code, everything should work on it's own (or at least no one mentions that there are problems that could arise).
However, when I try to compile a tex file I get the following error:
11 [0x00002528] INFO latexmk null - this process (19956) started by 'Code' with command line: latexmk -synctex=1 -interaction=nonstopmode -file-line-error -pdf "-outdir=c:/Users/.../texfile_locationfolder" "c:/Users/.../texfile"
It seems that this is a fresh TeX installation.
Please finish the setup before proceeding.
For more information, visit:
https://miktex.org/howto/install-miktex-win
The fact that it mentions MikTex makes me think something messed up and VS Code is trying to use MikTex instead of TexLive. How can I fix this?
PS: I've tried to look at the settings for the VS Code extension, but there are dozens of settings options and, fairly enough, I don't have any idea what most of them do.
I found a fix: I went into the Environment Variables list and found that MikTex was still in there. After deleting everything related to MikTex in the PATH Environment Variables, all was working well. Yeey!
I had the same issue (on Windows). Resolved by deleting a MikTex folder, found by searching for MikTex in File Explorer.
Then, I deleted this folder from the recycling bin and restarted my computer. LaTeX Workshop detected TeXLive and works as expected.
Recently I pass to Emacs org because is really convenient to me to write note there.
So I installed all packages I needed (principally ORG and EVIL) but I didn't understand how to setup everything.
I installed emacs from brew without using cask, I linked it, and I'm sure that I'm using the version that I installed (26.1).
So in my ~/ folder I have a .emacs file in which I set up evil mode, and I have a /.emacs.d/ in which I have a lot of file. The problem is: whatever I wrote in a ~/.emacs.d/init.el seems doesn't effect emacs.
So I said "whatever, I'm going on github and I installed some complete configurations and then I customized them myself". I tried to install these two configurations.
https://github.com/hrs/dotfiles
https://github.com/larstvei/dot-emacs?files=1
But for some reason, after doing exactly what they say on README.org
nothing happens.
In particular the second link, after install and open emacs said I need to have ~/.cask/.cask.el but I don't have it.
Advice?
Can someone help me make sense of list-buffer (aka Ctrlx - Ctrlb) behavior in emacs 25?
The behavior I'm used to seeing is that it opens the buffer list in another Emacs window (virtual Emacs window), splitting out a second window to do so, if necessary. In some versions it hasn't always been very deterministic which other window it used (if I had more than 2 up), but I could at least count on it not using the one the cursor was in.
I recently installed 25.0.50.1 to get around a remote file open bug (worked!), and now it isn't always doing this. Very often it opens the buffer list in the same window my cursor was in. Often it works the way it used to. I can't figure out any rhyme or reason behind which it choses to do.
Can someone enlighten me as to the algorithm it is using now? It makes managing multiple emacs Windows for reference viewing nearly impossible when I can't predict which window gets replaced.
I would guess your primary concern is to have a convenient way to switch buffer, not to understand the emacs' source code, so I would strongly recommend to check helm package out: http://tuhdo.github.io/helm-intro.html
It will take about 10 to 20 minutes to install and follow the tutorial, and it is well worth. I promise.
After installing helm and enabling it, the key sequence for you is Ctrl-x b: Shows open buffers, recently opened files
You will get a power pack of many other tools to work in emacs. I had the same problem with switching buffers, and seemingly 'chaotic' buffer popup. After helm installation, the problem is minimized to invisible because it is so easy to switch to the buffers you want.
Update:
To deal package installation errors and package compatibility:
M-x list-load-path-shadows to see if there is any conflicting packages. And since you may not have many external packages, I suggest backup ~/.emacs.d and have a new empty one. Also, most of the case when install packages, I try to use emacs package manager. Benefits of using package manger:
help check dependencies
avoid to manual download and unpack.
can do batch update of installed packages
Following is a workflow of enabling melpa repo and installing packages
M-x customize-group RET package
# Click or move cursor to and enter: Package Archives
# Insert the melpa repository.
Archive name: melpa
URL or directory name: http://stable.melpa.org/packages/
#Save above settings and then you can use the following to install packages:
M-x list-packages RET
f to filer package names
i to mark for installation
x for execution of installation
u for unmark package at cursor.
# to avoid using load-path repeatedly,
# I have this in my .emacs before any 'require' command:
; Set path recursively to one folder
(let ((default-directory "~/.emacs.d/elpa/"))(normal-top-level-add-subdirs-to-load-path))
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 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.