I didn't know what the reason was why after-change-functions were not working; I would evaluate:
(defun test-hook (change-beg change-end prev-len)
(message "changed!"))
(add-hook 'after-change-functions 'test-hook)
And then a change did nothing.
I was about to ask, but then I figured it out. Still thought of leaving the answer here on stackoverflow.
It turns out that there is a variable, called inhibit-modification-hooks, which needs to be set to nil, in case it isn't:
(setq inhibit-modification-hooks nil)
Read the manual.
Related
When emacs notices a crash, on next open of the file it "suggests" M-x recover file. But that only flashes up briefly, so I missed it this morning :( I went on editing, and lost last evening's work.
Is there a way to make that suggestion a prompt that must be responded to before it continues?
The warning message comes from the function after-find-file. I don't find an option to control this, but you can define a function to do something similar:
(defvar already-in-prompt-for-auto-save nil)
(defun prompt-for-auto-save-recovery ()
(if (and (not buffer-read-only)
(not already-in-prompt-for-auto-save)
(file-newer-than-file-p (or buffer-auto-save-file-name
(make-auto-save-file-name))
buffer-file-name)
(y-or-n-p (format "%s has auto save data: do you want to recover it? "
(file-name-nondirectory buffer-file-name))))
(let ((already-in-prompt-for-auto-save t))
(recover-this-file))))
and then install it as a hook.
(add-hook 'find-file-hook 'prompt-for-auto-save-recovery)
This is lightly tested code--I extracted what looked like the relevant parts of after-find-file--but maybe it will get you started in the right direction.
I'm not sure the best way to phrase this question, but hopefully my examples will make clear what's going on.
I have some code where I want to insert the contents of a bibtex file in a temporary buffer and move through the entries one at a time, grabbing the entry using bibtex-parse-entry for later use. However, whenever I run the code on a bibtex file that I haven't visited during this emacs session, bibtex-parse-entry returns a (wrong-type-argument stringp nil) error.
Once I visit the file, even if I then close the buffer, the code runs without any issues. And if I remove the bibtex-parse-entry call, bibtex-kill-entry has the same issue.
Here's the elisp code I'm using:
(with-temp-buffer
(insert-file-contents "~/test.bib")
(goto-char (point-min))
(bibtex-mode)
(while (not (eobp))
(let* ((entry (bibtex-parse-entry t)))
(message "i'm here"))
(bibtex-kill-entry)
(bibtex-beginning-of-entry)
)
)
and a dummy .bib file:
#Article{test,
author = {joe shmo},
title = {lorem ipsum},
journal = {something},
year = {1990},
}
With these you should be able to reproduce my error.
I have no idea what's going on, so I'd greatly appreciate any help!
I am not really an expert at this. I just debugged the situation a bit (try M-x toggle-debug-on-error in cases like this) and found a call to looking-at with a nil value. The stack-trace tells us that the problem is in the bibtex function bibtex-valid-entry. There, I found the variable bibtex-entry-maybe-empty-head which --according to its docstring-- is set by bibtex-set-dialect.
Thus, adding a call to bibtex-set-dialect to your function after calling bibtex-mode seems to fix the issue. As I do not really know, what you want to achieve in the end, I am not sure it actually fixes your problem. At least the function does raise an error anymore.
Hope, that makes sense and helps.
(with-temp-buffer
(insert-file-contents "~/test.bib")
(goto-char (point-min))
(bibtex-mode)
(bibtex-set-dialect) ;; <-- add this
(while (not (eobp))
(let* ((entry (bibtex-parse-entry t)))
(message "i'm here"))
(bibtex-kill-entry)
(bibtex-beginning-of-entry)))
I'm using starter-kit-lisp with Emacs 24.3.1, and it turns paredit-mode on in many buffers, including the minibuffer. This is extremely frustrating when I'm doing a regexp search, as paredit has no clue about regexps and won't let me enter certain characters in certain places. :)
I'd like to disable paredit-mode for all minibuffers.
As per Disable company-mode in minibuffer, there is a minibuffer-setup-hook, but using (remove-hook 'minibuffer-setup-hook 'paredit-mode) doesn't seem to work. However, the paredit-mode function itself takes an optional argument, so one can disable paredit-mode in minibuffers by adding the following to init.el:
(add-hook 'minibuffer-setup-hook (lambda () (paredit-mode 0)))
Thanks to Magnar Sveen for the hint!
This is a bit of a hack, of course. It would be better to stop paredit from ever being enabled. Following [immerrr]'s(https://stackoverflow.com/users/944617/immerrr) suggestions in the comments:
C-h v minibuffer-setup-hook <RET>
minibuffer-setup-hook is a variable defined in `C source code'.
Its value is
((lambda nil
(paredit-mode 0))
ido-minibuffer-setup rfn-eshadow-setup-minibuffer minibuffer-history-isearch-setup minibuffer-history-initialize)
I suspect that ido-minibuffer-setup may well be the culprit. I'll keep digging on this, and update the answer once I find something useful.
I am trying to add auto complete for *.lisp files. My slime setting is:
(add-to-list 'load-path "~/.emacs.d/plugins/slime/")
(setq slime-lisp-implementations
'((sbcl ("/opt/sbcl/bin/sbcl" "--core" "/opt/sbcl/lib/sbcl/sbcl.core")
:coding-system utf-8-unix
:env ("SBCL_HOME=/opt/sbcl/lib/sbcl"))
(ccl ("/opt/ccl/lx86cl64")
:coding-system utf-8-unix)))
(require 'slime-autoloads)
(slime-setup '(slime-fancy))
And ac-slime setting is:
(require 'ac-slime)
(add-hook 'slime-mode-hook 'set-up-slime-ac)
(add-hook 'slime-repl-mode-hook 'set-up-slime-ac)
(eval-after-load "auto-complete"
'(add-to-list 'ac-modes 'slime-repl-mode))
Each time I type a word in *.lisp file, auto complete popups some candidates but after a second minibuffer outputs
error in process filter: Reply to canceled synchronous eval request
tag=slime-result-6-19579
sexp=(swank:simple-completions "de" (quote "COMMON-LISP-USER"))
and the popup stuck for a while. After that I can continue my selection.
My question is how to remove this error and stuck? Any help is appreciated.
(this is too long for a comment)
I don't know yet how all this work but I had the same issue and I can always reproduce it... And I found a workaround.
I don't know what "Reply to canceled synchronous eval request" means nor if there are really two synchronous eval requests.
And in case there are two such requests, I don't know what is causing them...
However by changing the timer before which the auto-completion menu and pop-up show up, I've been able to work around the issue.
If I eval this (say from my .emacs file):
(setq ac-auto-show-menu 0.1)
then I can reliably reproduce the error you have (and it blocks a while for me too).
If I modify the value a bit:
(setq ac-auto-show-menu 0.3)
Then there's no issue anymore.
It's a crappy workaround and I still think there's a serious (although maybe easy to fix) underlying bug hiding somewhere.
Before now I've just been cutting and pasting code into my .emacs file, but then I decided to add some maven functionality to emacs. Now, I don't see how I was able to mess this up, but last night I kept getting the error I put in the title when I run M-x jarl-mvn-exec. I slept on it, and came back the next day but I'm still not getting anywhere.
(defun jarl-get-pom ()
(concat (locate-dominating-file
(buffer-file-name
(current-buffer))
"pom.xml")
"pom.xml"))
(defun jarl-visit-pom ()
(interactive)
(find-file (jarl-get-pom)))
(defun jarl-mvn-exec ()
(interactive)
(switch-to-buffer (get-buffer-create "maven"))
(start-process-shell-command "mvn-exec" "maven" "mvn" "-f" (jarl-get-pom) "compile")
(start-process-shell-command "mvn-exec" "maven" "mvn" "-f" (jarl-get-pom) "exec:exec"))
You'll need to provide more information to be sure. Try setting
(setq debug-on-error t)
which will give you a stack trace showing what function is complaining about the string being nil.
My guess is that buffer-file-name is returning nil, and that's where the problem lies (not all buffers have file names). Check out the debugging section of An Introduction To Programming in Emacs Lisp, or the debugging section of the Emacs Lisp manual.
The secret to finding a problem in your init file is not a secret: binary search.
Use comment-region to comment out half your init file, then 3/4, 7/8,... It is very quick to identify the problem. comment-region also uncomments: C-h f comment-region RET.