I'm developing a mode for Emacs, and everytime I switch to its buffer, viper gets turned on. I've modified viper-mode to trace where viper-mode is being called, and surprisingly set-viper-state-in-major-mode is called by running the viper-post-command-hooks, set to nil. Any idea of what is going on?
Thanks!
EDIT: For the benefit of all beings, here is what I found out: as instructed by Trey, I started emacs with -Q and manually loaded both viper and my package. As I could reproduce the bug, the problem was on one of these packages. After line-by-line filtering, I discovered that the innoquous-looking (kill-all-local-variables) was causing the problem.
There's something in initialization that's causing it.
First try starting without your .emacs emacs -q. If the problem persists, then the trigger is in the site-start.el. So, talk to whomever installed Emacs and get them to remove the customizations there. You can also always use the -Q startup option to avoid loading the site-start.el.
If the problem isn't in site-start.el, and you don't think it's in your .emacs, it might be in a custom default.el file, which you can prevent from being loaded by adding:
(setq inhibit-default-init t)
to your .emacs.
If you still have a problem, then I'm 99% sure it's in your .emacs.
To be 100% sure, try emacs -Q, which runs Emacs with no customizations. If the problem persists, download and install your own Emacs b/c you surely can't trust the installation you're using.
So, now if you're convinced it's in your .emacs, start cutting out parts of your .emacs, or introduce an error in your .emacs with (error "frog"), and progressively rule out which portions of your .emacs are causing the problem.
g'luck
The function kill-all-local-variables will run all functions added to change-major-mode-hook, this is a common way for global minor modes to initialize themselves. For example, global font lock and global cwarn mode use this.
I haven't used viper myself, but chances are that it use this mechanism. Of course, you still would have had to enable it in your init file, somehow, so if you simply would stop doing this, it would solve your problem as well.
Try commenting out any references to viper mode in your .emacs. I don't get sent into viper mode, unless I start playing around with viper mode before I eval your new mode.
Maybe there's more being done with this statement than you think:
(use-local-map ecoli-map)
Try to change some of your binds in your map. eg. j to C-j and k to C-k.
Maybe emacs is getting confused?
Try removing your ~/.viper config file, and also check your .custom.el for settings that might kick viper into action in your major mode (or globally).
Related
Each time I scroll top down / top up a buffer the Backtrace buffer pops-up and takes half the size of my window, this is quit annoying.
Especially as I don't use at all this buffer, so does anyone know how to prevent Bracktrace to pop-up?
I would be grateful. :)
lawlist is correct; this is certainly a consequence of the debug-on-error variable being set.
If you're not setting it yourself, then it must be a third-party library. You could use M-x rgrep RET debug-on-error RET (or maybe debug-on-error t) on your site-lisp and custom lisp directories, to help track down which library is responsible.
If you happen to use nxhtml, then it's likely to be that at fault (I'm don't think it's been updated anytime recently, and the last version I saw still had this issue in the code). Look in nxhtml-base.el and comment out the offending line (or look in autostart.el if you don't have the nxhtml-base.el file).
I used emacs23 this past few years, but multiples updates packages (especially Python-for-Emacs) have bound me this morning to upgrade to 24.
I have no problems now.
Thanks you for your time and your answers.
In my .emacs file I have (delete-selection-mode t) to enable the delete-selection-mode globally. Currently I'm working on a TeX file with AUXTeX, so it might be related to AUCTeX, but I don't know.
At first, after visiting a file foo.tex everything works fine, and typing over a marked text replaces the marked text with the one I type. However, after some time, during which I compile the document, add TeX macros, etc. the functionality of the delete-selection-mode doesn't work any more.
I don't know which action of mine is the one which causes the problem - it would be hard to trace it.
Note that although the functionality of the delete-selection-mode fails, when I try to enable it (M-x delete-selection-mode) I get a message that the mode was disabled! That is it was not disabled before - it just didn't work... I I then enable it (M-x delete-selection-mode again), then it is enabled and working again. Till the next fail...
Under the hood, the mode use pre-command-hook, which allows commands to run things right before every command. Emacs is known to clear this variable in the event of an error (just to make sure that Emacs don't hang). This mean that the function used by delete-selection-mode, or any other mode that use this hook, triggered an error.
How to fix it? Find what caused the error, wrap the function in a ignore-errors block, or run a timer re-adding the function every ten seconds or so.
I'm running Emacs 24 on Ubuntu 10.04, coding c++ in the default c++ environment. Periodically after a while coding, my indentation engine seems to break -- pressing "tab" to indent places places any line at the beginning of the line. Selecting the entire buffer result in the entire buffer being un-indented. This problem effects all buffers, current or later opened. So far the only way I have found to repair it is the (highly inconvenient) step of restarting emacs. Is there another way to reboot my indentation engine? Attempting to load different indentation styles does not fix the problem.
Have you read this thread?
http://lists.gnu.org/archive/html/help-gnu-emacs/2012-09/msg00216.html
It sounds like you can fix your problem by updating cc-mode.
I see the same with 24.3 but I found that closing and re-opening the affected buffer also solves the issue.
This is a recurring issue on my system (Emacs 24.3 x86_64 Red Hat Linux) and could possibly be a bug introduced in Emacs 24 judging from the link posted by event_jr.
I encounter the issue fairly often and usually resolve it by reloading whatever buffer I'm working in:
M-x revert-buffer RET yes RET
This way you don't have to close neither buffer nor Emacs.
I found unbalanced preprocessor directives (#ifdef etc) can throw it into this sort of behaviour
viper.el is hardcoded to disable viper in compilation-mode. How can I fix this without modifying the original file?
If you really want to do this, you should be able to customize the variable viper-emacs-state-mode-list and remove compilation-mode.
Have you tried running "M-x viper-mode"? That's what I do when I end up in a buffer in which it has been disabled, or at least not enabled.
I'm pretty old school sometimes and I like working with Emacs in my terminal. (I work with IDEs all the time. But sometimes, when in the privacy of my own home, I just like a text editor a terminal and a beer)
However, the default Emacs that comes with OS X does not seem to highlight the comments in font-lock-mode. I've seen this behavior in both Python and C mode.
I've already searched some forums and I found one post where the person was having the same problem as me:
http://forums.macosxhints.com/showthread.php?p=512361
Is is there any way to fix this problem?
I had this exact same problem. The solution is to change the color used for the comment face as follows:
(set-face-foreground 'font-lock-comment-face "red")
Or, if you only want to do this for certain modes:
;;; Only do this for the common C mode (C, C++, Objective-C)
(add-hook 'c-mode-common-hook #'(lambda () (set-face-foreground 'font-lock-comment-face "red")))
For more information on faces, see http://www.gnu.org/software/emacs/manual/html_node/emacs/Faces.html.
I'm not sure exactly how to fix it, but I'm fairly certain there's something you can put in the .emacs file. In fact, I think I've done that before. I'll look for my file and let you know what I can find.
I'll try and get you my .emacs file when I get home from work tonight.
[edit] I've looked and looked, and can't find a .emacs file on either system that I use, and on my OS X install (Leopard default), it looks like it does it correctly by default. I did some research here, and it looks like the default installations no longer use .emacs files, because there's folks like me that mess around with them and break things, and they got tired of having to help us fix it. But, there is a set of menus that will let you tweak things. Start by typing "M-x customize RET", where M is the meta character (on my OSX install, this is the esc key. Don't hold it down, just type it like a regular character. That'll get you into a menu of stuff you can change. I didn't poke around too much, so I'm not sure where in the menu you'll find what you're looking for. Sorry I couldn't be more help.
In my experience this is usually related to a unpaired quote (single-, double-, or otherwise) somewhere in an existing comment.
Hunt those occurences down and eradicate them in your source code (or if you are more ambitious, see if you can update the fontlock code in your major modes' emacs source code)
When I have encountered this in editting Perl in emacs, I often switch major modes to cperl-mode as it typically handles parsing the perl better than the default perl-mode.