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.
Related
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 am using emacs 23 on two computers.
On both, dpkg -s emacs outputs the following version number.
However one has window.el and the other not. This make some function such as split-window behave differently. The help page of this function on the computer that apparently has not window.el installed reads that it comes from C source code instead.
Where does this difference comes from?
I prefer the behaviour of the one that says that split-window comes from window.el: it allows to specify the SIDE when splitting window and provide additional function such as window-resize.
I suppose this is the most recent one but I do not know how to check it nor how to upgrade the other to this state.
Library window.el is as old as the hills. Perhaps you meant that one of your Emacs installlations has window.elc but not window.el?
More likely, you are referring only to function split-window. Yes, it used to be a built-in function (i.e., defined in C), and now it is defined in window.el (which file exists also for the older Emacs versions where that function is a built-in).
FYI, lots of window and buffer-display stuff was changed around the same time as split-window was rewritten in Lisp. Lots of behaviors changed, in minor or major ways.
What is not at all clear is what the problem is that you are reporting. You ask, "Where does this difference comes from? How to fix it?" I've explained a bit about the difference. As for how to fix it -- what is the "it" that needs fixing, and what would the fixed behavior be like?
IOW, your question is, so far, unanswerable. If you specify things more exactly, perhaps we can help more.
I'm not certain what's going on with your debian packages, but if memory serves the readable .el(.gz) files are not supplied in the basic package, but in a separate package. This is because all you strictly need is the byte-compiled .elc files, so they can reduce the base package filesize by omitting them (at the expense of enabling you to read the elisp code).
Is M-x load-library RET window RET successful?
Note that Emacs 24 is the current stable version. You might want to upgrade.
Edit:
M-x emacs-version tells you which version of Emacs you're running, which will always give you a definitive answer.
(And if the versions are identical, then run emacs -Q to eliminate and site- and user-specific config files from the picture, as those are always a likely culprit for differing behaviours.)
I am using org-mode within Emacs.
The problem is after issuing C-c > or C-c .
org-mode insert date like below,
(firstly it appears within the minibuffer, even the editing file is encoded with utf-8)
<2012-12-09 \326\334\310\325>
How to resolve this issue? My OS is Win7 32bit Chinese version.
Basically, I think the fonts emacs is using are not able to display the way the day is spelled in your language. I'd guess you lack some installed fonts, or emacs doesn't know where to find them, but I'm not sure how to fix this.
That being said, inserting such octal escapes into my emacs gives me ÖÜÈÕ, which I don't believe to be how days spell in many languages. The file might be encoded in utf-8, but what about the buffer ? What's the buffer-file-coding-system variable in that buffer (C-h v buffer-file-coding-system) ?
The variables calendar-day-name-array and org-time-stamp-custom-formats might be of interest, and I guess you could override how the timestamps appear right now with org-display-custom-times, that would probably be a workaround. See the manual for more about it.
At last, I have
(set-language-environment "UTF-8")
(prefer-coding-system 'utf-8)
in my config, functions you may want to investigate about.
I met the same problem to yours.
Through a long time searching online, I found (setq system-time-locale "C") work.
I tried to fix this problem in August, 2014.
My solution is adding the following code into your Emacs config file:
(set-locale-environment "zh_CN.utf-8")
Note that the time will be displayed in Chinese. Hope it helps.
I usually have an environment setting for MAKE_MODE (Windows XP, using GNU make, both under Cygwin and native)
set MAKE_MODE=UNIX
I now found differences between my build server (which has no MAKE_MODE defined) and a local build. This may be something completely different, but it got me wondering what other values I could specify for MAKE_MODE.
I think I know that MAKE_MODE=UNIX is suppose to tell GNU make to use /bin/sh - if it finds it - , but I quickly checked the GNU make manual and couldn't find a description. A google search only told me what I already know, but doesn't give a valid alternative.
Is the only alternative to not define the variable? Does it have influence at all when using CMD.exe and a native version of GNU make?
EDIT: So far I have found references for the values 'unix', 'win32', 'null' and undefined, but no explanations, and no specifications. But a look at the source code for GNU make 3.82 shows not a single occurrence of the string "MAKE_MODE", so GNUmake itself apparently doesn't change its behavior when this environment variable is set or not.
EDIT2: I checked the source code for GNU make for MinGW, and again found nothing. Maybe it's CygWin specific?
EDIT3: I found a reference that it might be property of an old version of GNU make, so I checked version 3.75. No luck, the string MAKE_MODE does not appear in the source code at all. The next step really must be the Cygwin version of GNU make. I know from 10 years ago that the Cygwin port in those days was not integrated in the regular source tree.
I found an ancient mailing list entry on the Cygwin site, explaining the basic operational effect of MAKE_MODE. This definitely indicates that the variable has to do with the Cygwin implementation of GNU make.
I'll dig around in the source code, and add to this answer when I find more details.
UPDATE: In a more recent post by maintainer Christopher Faylor I found the following update for GNU make version 3.81:
Note that the --win32 command line option and "MAKE_MODE" environment
variable are no longer supported in Cygwin's make. If you need to use a
Makefile which contains MS-DOS path names, then please use a MinGW
version of make.
I've not really found the values allowed for MAKE_MODE, but it's not any more necessary or supported in most recent versions of GNU make for Cygwin, and it was used for supporting DOS filenames in Cygwin's make.
And if you really want to know the set of allowed values, look in the source for Cygwin's make version before 3.81-1. I guess the only useful value was unix, all others will have meant the same.
Case closed? There's still not many views here...
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.