recently I've switched to Doom Emacs from a vanilla one, and mu4e stopped working for me.
First, when I open mu4e it gives me an error:
Symbol’s value as variable is void: mu4e--server-props
And then I cannot see my email folders:
command-execute: Wrong type argument: commandp, mu4e-search-bookmark
Same for search:
command-execute: Wrong type argument: commandp, mu4e-search
I'm running Nixos 22.05 and Mu 1.6.10.
No idea how to deal with the issue, googling did not provide much result...
Any help appreciated
I was trying to find similar problems on Stack Overflow, Gitghub issues, or wherever, but seems nobody experiencing the same problem...setup
Related
I have recently installed fedora 21 in my new system followed by emacs 24 text editor. When I try to do spell check, I am getting the following message at the bottom:
ispell-phaf: No matching entry for nil.
I understand that it has something to do with dictionaries linked with the ispell spell checking tool but unable to figure out exactly what the problem is. Please help me out friends....
Like #lawlist mentioned, the error is coming from the function ispell-parse-hunspell-affix-file. What ispell is trying to do is it's pulling in your set dictionary from ispell-dictionary or ispell-local-dictionary and then passing that value into the above function. That function then pulls the alist that is defined in ispell-local-dictionary-alist, which it then passes to hunspell.
So what you need to do in particular is to add an entry to ispell-local-dictionary-alist, something like this (example taken from here:
(setq ispell-local-dictionary-alist '(
("american"
"[[:alpha:]]"
"[^[:alpha:]]"
"[']"
t
("-d" "en_US" "-p" "D:\\hunspell\\share\\hunspell\\personal.en")
nil
iso-8859-1))
Where you need to make sure that where it says "american", you have the dictionary name that matches exactly with the value that you inputted into ispell-dictionary or ispell-local-dictionary, and make sure that you pass the arguments that you want into hunspell through this line: ("-d" "en_US" "-p" "D:\hunspell\share\hunspell\personal.en"). You can see what commands hunspell will take here. Hopefully that should at least get you a more meaningful error message so you know what else is going wrong.
I had a similar issue when migrating to a new OS as well. The migration also upgraded my emacs from 24.3 to 24.4 (and now I'm on 24.5).
I resolved this by installing the following:
rw-language-and-country-codes
rw-ispell
rw-hunspell
And then restarting emacs. I was stuck for a long time because I forgot to restart emacs - so don't forget! The wiki might also be helpful: http://www.emacswiki.org/emacs/InteractiveSpell
This worked for me finally (details in the following blog)...
http://blog.binchen.org/posts/what-s-the-best-spell-check-set-up-in-emacs.html
I chose the 'suggestion for non-programmers' in the above blog...
Thank you all for your support... #lawlist #Allan Zhang #Lucas #Rob Spanton
Even though the error has to do with a Hunspell function, this pops up when aspell can't be found by Emacs. Hunspell isn't used by default even when it's present on the system (as far as I can tell). Make sure it and some dictionaries are installed:
sudo yum install aspell aspell-en
or other dictionaries for other languages.
You might be interested in the Fedora package search:
https://apps.fedoraproject.org/packages/aspell
I had a similar issue after install Fedora 22. I resolved this by installing the hunspell-en-GB package from the Fedora repositories.
A few times each day, I receive an ispell error (like the following) that is corrected by restarting Emacs. Any ideas on how to further troubleshoot this type of error would be greatly appreciated.
Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil)
ispell-command-loop(("Brae" "Br ea" "Br-ea" "Bra" "Bread" "Break" "Bream"
"Brew" "Bret" "Bred" "Area" "Urea") nil "Brea" 2229 2233)
ispell-process-line("^Brea, CA ~ 92821\n" nil)
ispell-region(1 6771)
ispell-buffer()
ispell()
call-interactively(ispell nil nil)
command-execute(ispell)
The document being spell-checked is in tex-mode (built-in -- i.e., not using AUCTeX). The error (today) comes form a simple address at flush-left:
242 S. Orange Avenue\\
Brea, CA ~ 92821
Try loading ispell.el and then:
Try to provoke the error. After loading the source file (not the byte-compiled file), you will perhaps get a more detailed backtrace, which will tell you better what causes the error. (You apparently already have debug-on-error non-nil.)
If that doesn't tell you enough, then do M-x debug-on-entry ispell-command-loop, and walk through the execution in the debugger. That should show you just what goes wrong - where that function expects a number and hasnil instead.
Based on your better understanding, you will likely know what to do, to either avoid or fix the problem.
If you cannot reproduce the error easily then #2 will probably not be of much help. In that case, you can try examining the code of ispell-command-loop to see if you can figure out where the problem is.
You can also copy that code and insert calls to message at various places, to try to determine where things go wrong when they do go wrong. IOW, provide yourself with some more info than that sparse backtrace.
Maybe someone else has a better idea - mine is pretty much brute force here.
I have an org-mode file that I'm trying to export to a Beamer LaTeX PDF through XeTeX. It was working fine last night on this machine, and just as well on another machine on which I edited it afterward. Both are running org-mode 8, Emacs 24, same export process (3 runs of XeLaTeX)
When I synced back to this machine and tried to export again, I got the error Wrong block type at a headline named "". I checked all my headlines and gave them all names, but still got the same result.
Thanks to the wonders of indexed searchable FLOSS code, I immediately found the snippet online:
(env-format
(cond ((member environment '("column" "columns")) nil)
((assoc environment
(append org-beamer-environments-extra
org-beamer-environments-default)))
(t (user-error "Wrong block type at a headline named \"%s\""
raw-title))))
I'm not really solid on elisp at all, though, and I don't know most of what's going on here. From this snippet, what would I do to start debugging? (I realize I can start the emacs debugger, but it's not a PKE meter, I can't just wave it around.)
IMHE the best way to figure out what's wrong when you've found the relevant snippet of code is to use Edebug.
You should read the documentation to learn more about it, but basically here is my procedure:
identify the part of the code that crashes
instrument the code with Edebug (C-uC-M-x)
re-execute the code and go step by step to figure out what's going on (n)
If the problem is in another function, jump to it GOTO 2.
Iterate until you've understood the code and find a way to fix it.
Posting this answer just so that the specific solution to the particular problem the error was flagging is understood.
Apparently the version of Beamer I have on the other machine has a "normal" Beamer environment that specifies an otherwise blank, unformatted block. This is not present in this machine's install, or at least org/XeLaTeX don't know about it.
My steps were:
Search for all unnamed headings
Name each of them uniquely
Reproduce the error with the identifying string
Check the block type property against the available type list given in org-beamer-mode
Remove the offending type and replace it with another one
This is great and all, but I don't think it's the "best answer" because it involves no actual understanding of what the emacs interpreter was trying to tell me. If I didn't have a good idea of what was going on generally with the TeX, there's no way it would have worked. Dunno if this technique would impress anybody at an interview ;)
I've been seeing this a lot lately and am not sure if it is an SBCL issue, an Emacs problem, a SLIME problem, or my own understanding of what it means to "compile" a lisp file.
I will have a function, say this:
(defun some-function (x) (call-this-funcshun))
I will compile and run this, and I'll get an error that my function call-this-funcshun is not defined. Then I realize that is because there is a typo. So change it:
(defun some-function (x) (call-this-function))
In Emacs, I recompile the entire file with Control-C Control-K (Emacs saves automatically before the compile as well). Emacs then reports Compilation finished. I move to the REPL. I try it again, type (some-function whatever) and I get the same error. I search through the small lisp file and see that call-this-funcshun is clearly nowhere in it. Yet I have an error that this function is not defined.
Is there some sort of caching that Emacs or SBCL is doing that causes this to hang around? It's driving me nuts. Worth noting that if I quit SLIME and then launch it again, the issue is resolved. Also worth noting that this does not affect all my code edits, just occasionally.
Maybe the file is not loaded for some reason.
I would set *load-verbose* to T and watch that LOAD actually gets called.
Setting *load-print* to T would then also cause the printing of information about definitions loaded.
I've seen two conditions that can lead to behavior that looks like what you saw:
When the symbol in the file is not the same as the symbol at the REPL. The symbol's name is only a shorthand for identifying the symbol, and the same shorthand can identify different symbols based on which package you use it in. There are some ways to be surprised about which symbol you are referring to, so it can be worth checking with SYMBOL-PACKAGE even when you are pretty sure that they are the same.
When the buffer isn't saved. I'm not sure how C-c C-k deals with this now (because I edited it to auto-save for me), but in general compiling and loading tools tend to work from the file not the buffer.
I just recently started experiment with SLIME, and found a problem that makes me unsure whether it is something I am doing wrong or if the current snapshot of SLIME is broken.
The problem: trying to change the package (using , !p) always throws an error, regardless of which backend is used.
The error from SBCL looks like this:
The value #("FOO" 0 3 (SWANK-IO-PACKAGE::FACE NIL)) is not of type (OR (VECTOR CHARACTER) (VECTOR NIL) BASE-STRING SYMBOL CHARACTER PACKAGE).
[Condition of type TYPE-ERROR]
CLISP and CCL throw the same error, though worded slightly differently.
I am running on Windows, but the same thing happens when I try it on Linux. I suspect that either there is something I am neglecting to do in my .emacs file, or there is a glitch in the current version of SLIME. I just started using SLIME yesterday, so I have no past experiences to compare it to.
Any ideas?
It's working for me. What version of slime is it? You could try grabbing the latest from source and see if that helps.