I installed emacs 24.1 and dictionary.el, which is a dictd client plugin for emacs. I am able to look up dictionary within command "dict xxx", it works just fine.
However, dictionary.el doesn't work correctly, whenever I use "M-x dictionary-search" to find something, minibuffer displays "dictionary-mode: Symbol's function definition is void: make-local-hook".
Here is what I have in dot-emacs:
(setq dictionary-server "localhost")
Any ideas?
If you're referring to http://me.in-berlin.de/~myrkr/dictionary/
Then the issue would be here:
(make-local-hook 'kill-buffer-hook)
(add-hook 'kill-buffer-hook 'dictionary-close t t)
Because the add-hook call supplies the local argument, you can resolve this issue by deleting (or commenting out) the first line with the call to make-local-hook. That line was only left in the code to provide backward-compatibility with very old versions of Emacs, and is otherwise redundant.
Make sure you send them a bug report.
Edit: tripleee has pointed out that this problem has already been fixed in the current version of the library, which now lives at the following URL:
https://github.com/myrkr/dictionary-el
"localhost" is defined in /etc/dictd/dict.conf. It should be OK to remove or comment out the setq. By default, dictionary-el points to dict.org.
Related
As the title states, I'm relatively new to Emacs. I tried out several starter kits but went with Prelude and changed a lot of things around.
Anyway, I've been getting a good handle on everything...until this morning I was working and I typed double-quotes. Normally Emacs would insert a second double quotes right after ("") due to the auto-completion, but I must have accidentally changed something with a keystroke and now when I type ", I get \"\".
Thoughts?
Thank you.
This seems to be an issue with smartparens which prelude installs by default (see the file prelude-programming.el. This behavior is described in detail on smartparens wiki. To ensure that smartparens is causing problems you can can do C-h k" this would print about the command acutally run when " is pressed, if the command is sp--self-insert-command then the following should work
Paste this (setq sp-autoescape-string-quote nil) to your *scratch* buffer, go to the closing parenthesis and do C-xC-e, this will disable the behavior for current emacs session.
To disable the behavior for all future emacs session, assuming that you are using prelude, you will need to add the following to your personal config (basically some file inside /path/to/prelude/personal/).
(setq sp-autoescape-string-quote nil)
This will disable the auto-escaping of the string quotes, completely. If you like this behavior and do not want to disable it completely you can do what #steckerhalter suggests C-q" will insert just one parenthesis.
If the above does not solve the issue then try providing following info in your question which may help us debug the issue,
1) The list minor modes active (this can be obtained by doing C-hm).
2) Output of C-hk"
Hope that helps
this sounds a lot like smartparens (https://github.com/Fuco1/smartparens) which is included in Prelude. usually when you are inside "" then it will escape the quotes:
"hahah \"\" bah"
if you want to get a normal " inside quotes you have to use C-q " or disable smartparens with M-x smartparens-mode
If, as you say in a comment, " is bound to self-insert-command, then when you type " what happens is that a (single, unescaped) " character is inserted.
However, I suspect you have some mode turned on that does something additional whenever a " char is inserted. You mention automatic insertion of a second ", for example. That kind of behavior comes from a mode such as is provided by library smart-parens or electric-pair.
And you mention Prelude.
To find out what part of your init file (~/.emacs) is causing the behavior you see, bisect your init file recursively (first comment-out half, to see which half is responsible, then 3/4, to see which quarter is responsible,...). Then, if you still have a question about the responsible code, ask here, providing that info.
When you describe your problem here, it is important to be specific: what Emacs version, what mode(s), what libraries have you loaded,... Whatever might be pertinent. But first narrow down the problem by bisecting your init file to find the culprit.
I'm in love with emacs. I don't believe there is anything one can't do with enough effort!
I have just fine working scripts/extensions installed that could be relevant to get my point:
org-mode (with a CAPTURE-TEMPLATE named "Journal")
color-theme (emacswiki)
theme-changer (github)
color-theme-buffer-local (github)
emacs-version: "GNU Emacs 23.3.1 (i686-pc-linux-gnu, GTK+ Version 2.24.10) of 2012-03-25 on roseapple, modified by Debian"
Whats already working fine
When I'm starting a journal-entry trough my defined shortcut, what happens is the following:
emacs opens a new buffer("CAPTURE-journal.org") in a new window
I edit it
with another keystroke the entry gets refiled to my defined journal.org file
the buffer and the window are then closed automatically
I continue working on the file I worked before
What I want it to do additionally:
the "CAPTURE-journal.org"-buffer in the new window should have a unique color-theme, lets say color-theme-retro-orange
My .emacs with the code snippet I believe should be relevant.
I have no idea how to tackle this task. Where does one begin editing? Are even all tools needed for this listed above?
Seen from scratch: you need a list with color-themes
(setq my-themes (list "color-theme-retro-orange" "second-theme" "third...))
than you need a pointer, storing position used last.
See Emacs Lisp Intro chapter of kill-ring-save
When finished, bind that function at a suitable place, where-from your buffer is opened, resp. load it with the stuff mentioned by OP.
Or create a minor-mode, which will all new buffers provide with this.
Can anyone help me get scrolling margins enabled automatically when I start emacs with tpu-edt emulation?
Currently, my _emacs file (WinXP) contains the line:
(setq term-setup-hook 'tpu-edt-on)
I find TPU works great, and I can manually supply the command
M-x tpu-set-scroll-margin
It then prompts me for the top and bottom parameters, and works fine when I supply them.
I tried adding the example line from the tpu-extras.el file into the _emacs file:
(tpu-set-scroll-margins "10%" "15%")
but I get the message:
Symbol's function definition is void: tpu-set-scroll-margin
Help! Scrolling margins are the best feature of all time, and I want them always on!
Aside from the typo question raised by #sanityinc (still open --- you cite the name without s twice and with s once), it's likely that you need to invoke that code when you are in the proper mode. For example, if the mode in question is named tpu-edt-mode, then you do do something like this:
(add-hook 'tpu-edt-mode (lambda () (tpu-set-scroll-margins "10%" "15%")))
i get the following error when trying to open a second instance of emacs:
File error: "Cannot open load file" , "cua"
I guess I don't HAVE to open another instance of emacs (that is the beauty after all), I was just trying to keep some things separated (specifically work - like code and debug - and play - like news).
Would there be any reason I could not open two instances of emacs if I use cua.el?
solved the problem, so i figured i should post in case anyone else is seeing the same thing.
it turns out, it has NOTHING to do with a second instance of emacs. i cant even open a SINGLE instance (i just had been running one instance since before i saw the problem i guess... only noticed this time because of a shutdown).
i changed the following and the problem disappeared. in my .emacs file:
(require 'cua)
(CUA-mode t)
TO
(load-file "cua.el") ;; or if you compiled it (load-file "cua.elc")
(CUA-mode t)
this did the trick for me... although i am not sure why.
thanks to all who commented.
PS - i am using emacs 21.3.1, so i do have an older version. if any readers have the option, justinhj's comment above (about upgrading) is probably the easiest answer. CUA is built into version 22 and above i believe.
I'm having a problem with an Emacs lisp package that I pulled down from the ubuntu distribution. The package is JDEE, and it complains of Args out of range: "63", 0, 4 in the mini buffer and the *Messages* buffer whenever I open a file. This bug appears to have been reported last September but no action has been taken. I'm not an emacs newbie, having written some Elisp code myself, but I've never attempted to debug anything like this. I would like to stop the file load in a debugger when this error happens to at least get an idea of where the problem is coming from. I've read section 18.1.1 of the Elisp manual on "Entering the debugger on error" but trying to load the file after playing with various combinations of values for debug-on-error, debug-ignored-errors, and debug-on-signal appears to have no effect. Has anybody got any suggestions for my next step?
If debug-on-error isn't working, I'd start with the source itself. Find the keybinding/event that is causing the problem, and locate the function.
C-h k <keystrokes>
M-x find-function <function-name-from-above>
Now, once you are at the source
M-x edebug-defun
And the next time you hit the key, you should be able to step through the program. At that point, you can see which portion causes an error - and drill down that way.
You can also try setting the variable 'stack-trace-on-error to see if you can find the culprit (though 'debug-on-error usually works for me, not sure why it doesn't for you).
As a last resort (if edebug-defun doesn't work), you can redefine the routine with a call to (debug) in it, sort of does the same.
I suppose JDEE is somehow inhibiting debug-on-error. Perhaps grep through its files for the error message "Args out of range". While debugging, make sure to load the uncompiled .el files, not the byte-compiled .elc files (you will notice it in the debugger if you are running byte-compiled code) by entering commands like (load "foo.el") instead of (load "foo").
I got the same error when using find-grep after accidentally redefining (current-time-string) in one of my own scripts.
Using the M-x edebug-defun tip posted above I managed to find the issue when I stepped through the code giving the error seeing the call to (current-time-string).
Not sure how helpful this is in your case.