Much of the time when I use the mouse to click on an emacs window, the x selection which I hope to paste into the buffer is blown away. This seems to be caused by the slight shift of the hand as I apply the left click causing an inadvertant "drag copy." I do not believe I will be able to break this particular habit.
One solution I have found to prevent this is to set:
(setq mouse-drag-copy-region nil)
however this has the unfortunate side effect of preventing me from using the mouse drag functionality at all in emacs. Is there a way to control mouse drag behavior so that a click is ignored unless it spands two or more characters within the buffer?
I am coding on Centos 5.x + GNOME 2 with GNU emacs 23.3.1 in case it makes a difference.
This appears to be a GTK/X issue; I can produce similar behavior with other apps.
The easiest solution to this is to modify the function mouse-drag-track, which can be found in mouse.el. To find the function definition, M-x find-function mouse-drag-track RET.
Copy that into your .emacs file and make one small change. Find the and statement that looks like:
(and mouse-drag-copy-region
do-mouse-drag-region-post-process
(let (deactivate-mark)
(copy-region-as-kill region-commencement
region-termination)))
And modify it to have the check to ensure the region is at least 2 characters. I've made this check to be 10 characters for easier testing:
(and mouse-drag-copy-region
(>= (abs (- region-commencement region-termination)) 10) ;; THIS IS NEW
do-mouse-drag-region-post-process
(let (deactivate-mark)
(copy-region-as-kill region-commencement
region-termination)))
I don't see a clean way to do this via advice or hooks or variable settings.
Be sure to have a (require 'mouse) before your definition of mouse-drag-track to ensure you override the built-in definition, as opposed to it overriding yours. You also might want to add a check to your .emacs right above the re-definition to remind you to check for new versions of the library/function you're overwriting:
(unless (eq emacs-major-version 23)
(error "check for new mouse-drag-track"))
This is a bug in emacs that was introduced into the source code history in 2001. I have posted a patch that can be applied to local installations. Hopefully the emacs maintainers will investigate further.
Here is my patch and discussion:
http://lists.gnu.org/archive/html/emacs-devel/2011-08/msg00818.html
Related
Is there a proper predicate for determining whether the window has focus in the mode line? I'm trying to do some things in my mode line that require more flexibility than just using mode-line-inactive.
I've been doing:
(defun window-has-focus-p ()
"When called in eval sexp in mode or header line template,
returns true if this is the active window."
(eq
(frame-selected-window)
(get-buffer-window)))
And it worked very well on two of my computers for months (Windows 7 and Debian). However, I tried using it on another Debian box yesterday and it reported t in every mode line for every window... totally broken.
I haven't been able to find a standard predicate call for this purpose, and I can't figure out why this hacked-up one seems to work on some devices and not others. Additionally, I did evaluate (force-mode-line-update t) with M-: and that did not help.
Emacs version is 24.3
While the mode-line-format is evaluated for a given window, this window is temporarily made the selected-window. In Emacs<=24.3 this was made only halfway: selected-window was changed, but not frame-selected-window. This meant that temporarily (frame-selected-window) was not equal to (selected-window) and breaking this (normally) invariant was a source of various corner case bugs. So we fixed it in 24.4, which means that your code broke.
To make it work in 24.4, you need to save the "selected-window" as seen by the user before the mode-line-format is processed.
You can do that with
(defvar my-real-selected-window nil)
(add-function :before pre-redisplay-function
(lambda (_wins) (setq my-real-selected-window (selected-window))))
So you can then use my-real-selected-window in your mode-line-format to know which window is the one that should be highlighted specially.
I have been using this in my configuration
;;; active modeline detection hack
(add-hook 'post-command-hook
(lambda ()
(when (not (minibuffer-selected-window))
(setq powerline-selected-window (selected-window)))))
Maybe the post-command-hook is not the most elegant solution, but is working correctly for me.
I'm trying to get doremi working in emacs. Specifically, at this stage, to allow me to quickly scroll through a condensed list of color-themes and see each theme as I go through it. For this I would use the 'M-x doremi-color-themes+' command.
What I've done:
Installed color-themes (successfull)
Installed doremi.el, doremi-cmd.el, ring+.el and added
(add-to-list 'loadpath "~/elisp/themes")
(add-to-list 'loadpath "~/elisp/doremi/")
(require 'color-theme)
(color-theme-initialize)
(color-theme-classic)
;; create a list of color themes to scroll through using 'doremi-cmd
(setq my-color-themes (list 'color-theme-classic
'color-theme-retro-green
'color-theme-gray30
'color-theme-subtle-hacker
'color-theme-jonadabian-slate))
(require 'doremi)
(require 'doremi-cmd)
(require 'ring+)
to the .emacs file.
What emacs does:
When I type the comand 'M-x doremi-color-themes+' into the mini-buffer it seems to accept that I've given it a valid command and tells me to use the and arrow keys to move through the list. But when I do that all that happens is the cursor moves up and down in the active window. No changing of color-themes.
Being somewhat new to emacs (and especially customising it) I'm sure I have missed a step or put something in the wrong place. Perhaps there's some sort of (setq 'bla-bla-bla (...)) I need to do?
Sorry for your trouble. Please state your Emacs version (M-x emacs-version), and your version of color-theme.el.
You do not need to require library ring+.el if you use Emacs 23 or later (its code was included in GnuEmacs 23.)
You do not need to use (color-theme-initialize) or (color-theme-classic). The former is done automatically by doremi-color-themes+.
Try starting from emacs -Q (i.e., no init file, ~/.emacs), to be sure there is no interference from stuff in your init file.
Your variable my-color-themes is not referenced anywhere. Instead of defining that variable, just customize user option doremi-color-themes. (Or leave its value nil, which means that all color themes will be cycled through.)
Feel free to contact me by email if you continue to have a problem. Or continue here, if you prefer.
[Just to be sure: you are using color-theme.el, right? There is a lot of confusion out there between Emacs "custom themes" and color themes. Do Re Mi supports both, but they are different critters.]
After a bit for back and forth with #Drew we found a solution to the problem.
It turned out the major problem was that I was using emacs in 'terminal mode' rather than as a GUI application. Bare in mind I'm using a mac.
In the context of Terminal, my arrow keys send escape sequences and so doremi cannot read the event as intended. So it just escapes and applies the message to the active buffer.
There is an answer.
By adding the following lines to my .emacs file (or whatever your init file for emacs is) I was able to redirect doremi to use two other keys. ie. not the up and down arrows.
(setq doremi-down-keys '(?n))
(setq doremi-up-keys '(?p))
Doing this tells doremi to use 'n' as the down key and 'p' as the up key. And all works just fine.
Because I am only new to the world of programming and computing I may often use incorrect terminology. If this is the case please let me know and I will edit accordingly for clarity and consistency.
I have consulted this resource: http://www.emacswiki.org/cgi-bin/wiki/ControlTABbufferCycling, and tried buffer-stack.el, which is useful, but I find the user experience slightly awkward without being able to visualize other buffers further down the stack. It is also outdated (2002), so I wonder if there is an improved version. Most other links on that page are broken or very old as well.
I am seeking a ctrl +tab stack-based buffer cycling, similar to the way alt + tab works with windows. Ideally it would include an indicator for my current location in the buffer list. I don't think my desired feature is too specific, since many IDE's already have this feature.
I would imagine a tool that is similar to how buffer cycling works in Eclipse. Pick below:
I have explored other options, but nothing seems to mimic the functionality that has already been implemented across other IDE's like Eclipse.
I am aware of ido-mode, although it does not suit my needs for rapid stack-based switching.
I am also aware of other non-stack solutions like the one below:
(global-set-key [C-tab] 'next-buffer)
(global-set-key [C-S-iso-lefttab] 'previous-buffer);Linux
(global-set-key [C-S-tab] 'previous-buffer);Windows/Linux
but I prefer a stack-based switch.
Any suggestions? Is this feature available somewhere, or even in development? Especially with an index indicator, as shown in Eclipse above. That would be awesome - I imagine it would be as a pop-up or in the mini-buffer.
Try out this snippet:
(defun ctrltab ()
"List buffers and give it focus"
(interactive)
(if (string= "*Buffer List*" (buffer-name))
;; Go to next line. Go to first line if end is reached.
(progn
(revert-buffer)
(if (>= (line-number-at-pos)
(count-lines (point-min) (point-max)))
(goto-char (point-min))
(forward-line)))
(list-buffers)
(switch-to-buffer "*Buffer List*")
(delete-other-windows)
(forward-line)))
(global-set-key [C-tab] 'ctrltab)
It's often inferior to ido-switch-buffer, but it does its job anyway.
elscreen does a little bit what you seek:
http://wikemacs.org/index.php/Elscreen
You have to create screens (tabs) on demand and you can call M-x elscreen-select-and-goto to select a screen from a list in the minibuffer.
Fortunately it is already coupled with helm: helm-elscreen. That gives a good looking and handy choice list:
fuzzy matching
scrollable list
choose actions (press TAB and choose "Change screen/Delete/Only").
However, you still have to create a screen manually (but I like it because I can organize sort of work areas -it is possible to isolate buffers per screen. A tab per buffer would be way too much + emacs creates many internal buffers so they can get on the way).
helm: https://github.com/emacs-helm/helm/wiki
ps: helm-buffers-list is close to the interface you want for switching buffers, without tabs…
I have been maintaining a personal copy of buffer-stack. It works really well -- to the extent that I haven't thought about it for years until recently when I had to fix a legacy workaround which caused a bug.
I will put my fork up on github when time allows. I'm not averse to adding some sort of index display although it does not matter much in my use-case -- helm is great to choose from a list of buffers.
I am using GNU Emacs 22.3.1 on Windows.
In my Emacs I have enabled delete-selection-mode, and it's very useful to select a region and delete or replace it. But I have a drawback.
When I write or press DEL over the selection, Emacs does not only remove the text, but it kills (a.k.a. send to the clipboard*). This is very annoying for me, because I don't have control of my kill-ring (a.k.a. clipboard) and may cause unexpected effects.
There is a way that delete-selection-mode does not kill the text, just delete it? Perhaps modify the source code?
(*: I have synchronized the kill-ring and the Windows clipboard, so for me (for practical purposes) it's the same)
Edit[Jun 24, 2009]
Thanks, danielpoe. Even with the idea of Trey Jackson the selection is still killing. And I found the reason.
I discovered that the problem was not in delete-selection-mode. The problem is, when I selected the region, I did it with the mouse. And never have imagined that it was the mouse who was copying the text. Using the set-mark command and the arrow keys the text finally aren't killed, only deleted.
I disabled this behavior writing this in my .emacs:
(require 'delsel)
(setq mouse-drag-copy-region nil)
(global-unset-key (kbd "<mouse-2>"))
(global-unset-key (kbd "<mouse-3>"))
Thanks for the advice. If this method of disable this mouse behavior can cause conflicts with other options, please comment.
Have you tried starting emacs with -Q. If I do so and only enable M-x: delete-selection-mode, I can't reproduce what you describe. Nothing is killed only deleted?! Can you check?
It looks as though you just need to modify a small part of the source, namely make this change:
(defun delete-active-region (&optional killp)
(delete-region (point) (mark))
t)
The original code looked at the argument killp and used that to decide whether to add the region to the kill-ring, and you said you don't ever want that. This change forces the region to always be deleted.
Now, you don't need to actually modify the source, just place that function definition after the (require 'delsel) in your .emacs (or after the (delete-selection-mode)).
I'm using emacs with cvs and have cvs mode enabled. I'd like to get line-by-line highlighting of changes from the latest version in CVS. I've seen this done in intellij where there is a green indication for lines added and another indication for lines modified and a third symbol for lines deleted.
Is there a cvs highlighting mode for emacs to show changes from the latest version of cvs? I'm not looking for a cvs diff type functionality that would open in a new buffer, but something that would indicate in my current buffer what lines have been modified.
In the following image there is a blue rectangle on the left side in what Intellij calls the "gutter" to indicate that the code is different than what is in source control.
(source: jetbrains.com)
I'm looking for similar functionality in emacs.
You can now check out diff-hl, which provides highlighting on the left window fringe.
So far I've tested it only on a few modern DVCSes, but if you're still using CVS, and it doesn't work as well, please file an issue.
Here's another answer that doesn't do what you want either, but may be useful.
C-x v g
runs the command vc-annotate.
That'll pop up a new buffer (I know, you didn't want one), but it'll have all the lines marked with who touched them when. And, bonus, they're color coded with a heatmap (red is most recent, blue is least), for easy identification of recent changes.
Of course the built-in version of vc-annotate doesn't scroll the buffer appropriately, so you'll want this advice:
(defadvice vc-annotate (around vc-annotate-and-scroll)
"scroll buffer to view current line in the annotated buffer"
(let ((pos (count-lines (point-min) (point))))
ad-do-it
(let ((orig-window (selected-window))
(window (other-window-for-scrolling)))
(select-window window)
(goto-line pos)
(select-window orig-window))))
(ad-activate 'vc-annotate)
You want vc-diff, which is on C-x v = by default. This gives you raw diff output in a temp buffer. The buffer uses diff-mode, which has a few neat tricks ... for example, you can use C-c C-e to apply the diff as a patch to another file. Use describe-mode (C-h m by default) in the diff buffer to find the other tricks.
Perhaps you'd like Ediff, which appears to do exactly what you want.