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
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.
I'm using a fairly standard install:
Ubuntu 12.04 LTS (installed less than a week ago)
GNU Emacs 24.1
And when I open a PDF file in Emacs, it's terribly slow. There's a 2-3 second delay when simply scrolling with the mouse, 1-2 second delay when using n, p, C-p, C-n, etc.
This is with a 20-page doc. With a 50-page doc like this one, Emacs becomes unusable (constant freezing), so the problem gets worse with document size.
How would I go about fixing this?
When I ran emacs -Q, the problem went a way. I isolated it to this line in my .emacs.d/init.el file:
(global-linum-mode 1)
If I comment that out and restart Emacs, I can scroll on PDFs and I get no UI delay whatsoever. If I turn it back on with M-x global-linum-mode, the long lag between mouse scroll and UI update comes back.
To disable linum-mode when you are in DocView mode, you can use the following setup file:
setup-linum.el
You can customize by editing line number 5
I recently switched to using GNU Emacs 24 from 23, and I notice that whenever I enter gud the *input/output* buffer is open. I have close it manually with C-x 0 everytime I debug. Can anyone point me to the correct variable which needs to be configured in order to stop displaying this buffer by default?
There is a 'gud-gdb' in new emacs releases that implement the old behavior of gdb/emacs interaction (no dedicated-windows and no I/O buffer). If you don't want to call M-x gud-gdb when you use it you can define an alias for M-x gdb
I have this problem as well. After a quick look at the source code, the problem appears to be that GUD dedicates most of its windows (that is, it calls set-window-dedicated-p on them). A dedicated window is one that cannot be switched away from. I guess more and more young guns are using GUD in many windows mode and want GUD to manage their window layout, and those of us that like to do that manually are in the minority. There doesn't seem to be anything obvious in gdb-mi.el that disables this behavior (for example, gdb-set-window-buffer seems to always do a set-window-dedicated-p to t for all windows it manages).
For now, this solution is more or less the one I'm using -- I manually deactivate the window dedication. This seems suboptimal, though. There ought to be some way to get GUD to let you manually manage the window layout. This question is related.
You can disable window dedication altogether like this: (in Emacs 24.4+)
(defun set-window-undedicated-p (window flag)
"Never set window dedicated."
flag)
(advice-add 'set-window-dedicated-p :override #'set-window-undedicated-p)
Note that this doesn't affect already dedicated windows.
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).
(load "~/.elisp/nxhtml/autostart.el")
(setq mumamo-chunk-coloring 'no-chunks-colored)
I currently have the above in my .emacs and the chunk coloring is still showing up. I have also tried disabling it through customize-option and then setting the state to "no chunk coloring" in mumamo-chunk-coloring. I'm using the latest emacs23 from cvs and have the most recent nxhtml release.
What is the correct way to disable the coloring of different major modes?
Bug. I forgot to add this possibility back when implementing chunks in chunks.
I have just corrected this in 1.88 (which is yet in beta).
Note that in the new version you will use a number for mumamo-chunk-coloring. Set this to 1 to avoid coloring main mode chunks etc.
BTW: Just happened to see this. If you want bugs to be corrected it is normally much better to report them in nXhtml bug database on Launchpad.