Is there a minor mode in Emacs that will highlight changes made to a buffer? I'm picturing something like highlight tails without a timeout feature. I would use highlight tails for this and change the timeout rate to be something huge, but the mode seems to consume a bit of CPU to do the timing (a feature I wouldn't use).
EmacsWiki is usually your friend for things like this. Sounds like you might want highlight-changes-mode.
In short, +1 for Timo's suggestion of highlight changes mode.
And without even resorting to EmacsWiki:
M-x apropos RET highlight changes RET
It's bundled with recent Emacs versions.
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 am using Emacs Live (https://github.com/overtone/emacs-live) and I have global linum-mode enabled. However when I switch from a buffer to another, and then back to the original buffer, the line numbers are all messed up like so. Thanks.
Before digging further into it, you may want to try out nlinum-mode (available from GNU ELPA), which provides similar functionality, but using an implementation technique that tends to be more reliable.
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 spend a lot of my time in emacs, and for the most part it's wonderful. But one thing really drives me nuts when I'm deep in it, and that's control over which window various new buffers are opened in. When I do find-file, it always opens in the current window, and this is what I like. But tons of other modes like to split my windows for me, change the layout, and do various other things that annoy me. For example running M-x manual-entry seems to have no rhyme or reason about where it opens the manpage, and various org-mode commands do the same thing, closing windows I want to keep open, etc. I don't like having to redo my layout everytime I want to look at my org agenda or open a manpage.
In short, is there anyway to globally control which windows are used for modes that want to open in a window other than the current one? Can I direct them more easily? Or will I have to hack each mode to act the way I want it to?
Try Winner mode:
http://www.emacswiki.org/emacs/WinnerMode
It provides an undo/redo for changes to the window configuration.
This question has always bugged me too. I found this:
http://www.gnu.org/software/emacs/elisp/html_node/Choosing-Window.html
It looks like you can use (setf pop-up-frames t) to make stuff show up in a new frame.
Also, it looks like you can use display-buffer-function to override the display function (how buffers are chosen.) Of course, you'd have to be good at elisp.
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.