I'm looking for a way to include some filtering in the other-buffer method in emacs.
Currently calling other-buffer pulls up the last most recent buffer, but the problem with this is that buffers that get modified by external processes keep coming up as other-buffer. I would like to implement some sort of filtering in other-buffer.
Currently I use evil with C-^ bound to other-buffer, and I have some tail.el buffers active, and when I try to switch bufffers the tail buffers keep popping up.
Is there some alternative to other-buffer or could someone scratch up some code to implement this, Thanks.
What has worked for me is winner-mode - it's like an undo, but for window configurations.
Here's my setup:
(winner-mode)
(global-set-key (kbd "<f7>") 'winner-undo)
(global-set-key (kbd "C-<f7>") 'winner-redo)
Also I'd recommend other-window on some very cheap shortcut, since it's
a command that's used a lot.
I've put it on C-p, since I didn't appreciate the inconsistency
that one of the direction keys is so far away from others.
I've got previous-line on C-h instead, so now
my direction keys are n h f b - they're almost together!
And I didn't really miss the defaults on C-h, since f1
has the same functionality.
Ok so I got some workable solution but its not perfect it using bits from this answer:
emacs lisp, how to get buffer major mode?
(defun buffer-mode (buffer-or-string)
"Returns the major mode associated with a buffer."
(with-current-buffer buffer-or-string (format "%s" major-mode)))
(defun other-buffer-ex ()
(interactive)
(switch-to-buffer
(if (string-equal (buffer-mode (other-buffer)) "comint-mode")
(next-buffer) (other-buffer))))
Related
I'm using dedicated.el which is very similar to dedicate-windows-manually.el to manually mark certain windows as "dedicated" to their buffer and also inelegible for splitting by various commands that open new buffers (grep, compilation, etc.).
But I really only want the second part.
In other words, I want find-file, kill-buffer, switch-buffer and so on to work as if the current window was not dedicated. But I want other commands (grep, compile) to honor the dedicated status and not split that window.
I made a small attempt at this, but it doesn't work properly and seems like a misguided way to go about it, likely missing many cases.
(One of the problems is that the "dedicated" minor mode is associated with a buffer while set-window-dedicated-p applies to a window; this could be overcome, but I still feel there must be a better way to accomplish what I want...)
(defun with-undedicated (f)
(interactive)
(let ((was-dedicated (bound-and-true-p dedicated-mode)))
(progn
(if was-dedicated (dedicated-mode))
(command-execute f)
(if was-dedicated (dedicated-mode)))))
(defun undedicated-find-file ()
(interactive)
(with-undedicated 'ido-find-file))
(defun undedicated-kill-buffer ()
(interactive)
(with-undedicated 'ido-kill-buffer))
(defun undedicated-switch-buffer ()
(interactive)
(with-undedicated 'ido-switch-buffer))
(global-set-key (kbd "C-x C-f") 'undedicated-find-file)
(global-set-key (kbd "C-x k") 'undedicated-kill-buffer)
(global-set-key (kbd "C-x b") 'undedicated-switch-buffer)
edit
The following was performed to test Drew's answer:
(defun make-weak-dedicated ()
(interactive)
(set-window-dedicated-p (selected-window) "weak"))
(defun dedicated-status ()
(interactive)
(minibuffer-message "window-dedicated-p: %s" (window-dedicated-p (selected-window))))
Making the window "weak"ly dedicated does indeed do what I want: grep and other popup buffers do not replace the buffer in the weakly dedicated window. However, in that weakly dedicated window, find-file seems to reset window-dedicated-p to nil as tested by my dedicated-status function, so I still don't have a technique to prevent popup buffers from using or splitting a window and allowing find-file etc. to work as normal within that window.
clarification
Sorry for not being clear. Here's what I want to happen:
I mark a window as [weakly] dedicated (or whatever equivalent may exist)
I invoke grep, compilation, and so on, and they do not split that window nor replace the buffer in that window (instead splitting some other window that is not marked dedicated)
Within the weakly dedicated window, I invoke find-file, which replaces the buffer in the window but leaves the window weakly dedicated to the now changed buffer
It's that last bit that isn't working how I had hoped: after find-file, the window is no longer weakly dedicated (window-dedicated-p is nil). Since the property in question is associated with the window, I find it surprising that changing the buffer affected that window property, but so it is.
See the Elisp manual, node Dedicated Windows. If you use function set-window-dedicated-p to give a window a non-nil and non-t value then function set-window-buffer will respect it as a weakly dedicated window. That may be what you are looking for.
I'm trying to learn Emacs and eLisp by writing some simple macros. Here is one of them:
(global-set-key (kbd "C-c d") 'local-delete-line)
(defun local-delete-line ()
"deletes 1 line"
(interactive)
(beginning-of-line)
(set-mark-command)
(next-line)
(delete-region))
Unfortunately, after triggering C-c d (or any other hotkey that I set up by global-set-key), Emacs responds with this:
Any ideas what can cause this?
To troubleshoot, I've removed my whole .emacs file, created an empty one, and I've put only the definition of local-delete-line function, together with global-set-key command. Emacs still produces garbage when invoking the function.
Start by reading the doc of set-mark-command (C-h f set-mark-command). See what it says about not setting the mark in code you write. See how many arguments it requires.
Read the doc of delete-region: it requires two arguments.
Do M-: (setq debug-on-error t), and then try your recipe. The backtrace buffer will tell you what you have done wrong.
State what it is that you are trying to do. So far, it seems like you just want to delete or kill a line. If so, what's wrong with C-k?
The problem occurs when customizing options in Emacs. Every time I click on a link a new buffer is created. How to force Emacs to use single buffer?
Try this:
(defadvice custom-buffer-create (before my-advice-custom-buffer-create)
"Exit the current Customize buffer before creating a new one, unless there are modified widgets."
(if (eq major-mode 'Custom-mode)
(let ((custom-buffer-done-kill t)
(custom-buffer-modified nil))
(mapc (lambda (widget)
(and (not custom-buffer-modified)
(eq (widget-get widget :custom-state) 'modified)
(setq custom-buffer-modified t)))
custom-options)
(if (not custom-buffer-modified)
(Custom-buffer-done)))))
(ad-activate 'custom-buffer-create)
As an alternative to my original answer (which I am not inclined to use myself), I thought I might suggest other ways in which you might deal with getting rid of lots of Customize buffers once you have finished customising things.
First, do note that simply pressing q will "Exit current Custom buffer according to `custom-buffer-done-kill'" (i.e. either bury it or kill it).
Second is to use M-x kill-matching-buffers RET \*Customize RET (and then confirm each one), but that's a bit tedious.
What I'd actually do is use ibuffer.
If you don't use it already, I recommend binding C-x C-b to ibuffer, which is a greatly enhanced alternative to the default list-buffers. I love it primarily for its filtering and grouping abilities, but it can do a great deal besides that.
(global-set-key (kbd "C-x C-b") 'ibuffer)
I also use the advice which can currently be found here at the Emacs Wiki so that ibuffer always opens with the buffer I came from selected.
That done, and from a Customize buffer, C-x C-b * M RET D y will kill all the Customize buffers. That is:
C-x C-b Open ibuffer (with point on the current Customize buffer entry)
* M Mark buffers by major mode...
RET ...select the mode (which defaulted to the major mode of the selected buffer, or otherwise type Custom-mode RET)
D y kill all marked buffers
Try it out; you'll probably like it. Searching for ibuffer will turn up other handy uses.
For instance, you could use / n ^\* RET / g tmp RET to separate out all buffers starting with * into a "tmp" group, so that they don't clutter up the group of buffers you are more likely to be interested in.
As with any major mode, use C-h m to read the built-in documentation.
I converted from Visual Studio to Emacs for most of my development (mainly due to switching programming languages). However, there is one cool feature of Visual Studio that I truly miss: Ctrl-Tab between "buffers".
The ctrl-tab that in Visual Studio is not the same as C-x b in Emacs. So, it's not just a keyboard mapping issue. Here are the features of my ideal Ctrl-Tab:
Hold down ctrl hit tab, you see the next buffer before you let go of ctrl.
There is no need to hit enter.
If this is not the buffer you want, hit tab again until you see the buffer you want.
The moment that ctrl is released, the buffer ring is updated. The next buffer in the ring is the buffer where you first pressed ctrl.
I've seen some Emacs plugins that try to simulate this behavior, but #4 is the most difficult. It seems like Emacs is unable to detect when the ctrl key is released. Instead, the code waits for the user to be in the buffer for a certain time or waits for a buffer to change..and then the buffer is added to the ring. It's different enough to really frustrate me and just never use my beloved ctrl-tab again. For now I just deal with C-x b. ido-mode makes C-x b more tolerable, but I still dream of a day when I can ctrl-tab in emacs.
Has anyone out there found a way to configure Ctrl-Tab in Emacs to work like Visual Studio?
I was searching for exactly the behavior that you describe and came across
the iflipb package: http://www.emacswiki.org/emacs/iflipb and bound it to C-tab, C-S-tab.
Unfortunately it doesn't restart the cycling either after releasing the ctrl key, so in that regard is the same as the my-switch-buffer in the answer above. Any new insights into this issue are highly appreciated.
If you are using GNU Emacs 22.1 or more recent releases, \C-x<Right> fires M-x next-buffer and \C-x<Left> fires M-x previous-buffer. This page on EmacsWiki has a link to C-TAB Windows style buffer cycling. The page also talks about how to bring this behavior on older releases of Emacsen.
This question from yesterday looks very similar to what you want to achieve, except that the question talks about Notepad++ instead of Visual Studio.
I think this is close to what you want. As you mentioned, Emacs doesn't receive events for the control key, so you can't quite get the functionality you want. However, this will not record the buffer switch until you do something other than press C-tab (i.e. scroll, type something, click the mouse, use a command M-x ...):
(global-set-key (kbd "<C-tab>") 'my-switch-buffer)
(defun my-switch-buffer ()
"Switch buffers, but don't record the change until the last one."
(interactive)
(let ((blist (copy-sequence (buffer-list)))
current
(key-for-this (this-command-keys))
(key-for-this-string (format-kbd-macro (this-command-keys)))
done)
(while (not done)
(setq current (car blist))
(setq blist (append (cdr blist) (list current)))
(when (and (not (get-buffer-window current))
(not (minibufferp current)))
(switch-to-buffer current t)
(message "Type %s to continue cycling" key-for-this-string)
(when (setq done (not (equal key-for-this (make-vector 1 (read-event)))))
(switch-to-buffer current)
(clear-this-command-keys t)
(setq unread-command-events (list last-input-event)))))))
I like the cycling and toggling behavior of iflipb too, it's very much like Windows Alt-Tab behavior. However, as previously pointed out, Emacs doesn't make it easy to notice when you release the control key. This makes toggling between the top two buffers imperfect: if you press C-Tab (and release) and then C-Tab (and release), you haven't toggled between the top two. Instead, iflipb just marches further down the buffer list. But if you perform any other Emacs command between the two C-Tab events, then iflipb recognizes that it is starting over in the buffer march, so it does the toggle.
On Windows, AutoHotKey can come to the rescue and send Emacs a keystroke when you release the control key. Here's my script:
#if WinActive("ahk_class Emacs")
^Tab::
Send {Blind}^{Tab}
SetTimer, WaitForCtrlUp, 10
return
WaitForCtrlUp:
if(!GetKeyState("LControl", "P") and !GetKeyState("RControl","P"))
{
if WinActive("ahk_class Emacs")
Send ^c:
SetTimer, WaitForCtrlUp, Off
}
return
Whenever C-Tab is pressed in emacs, the script starts polling the state of the control key. When the key is released, it sends Emacs the C-c : key sequence. I have that key bound to a "null" command, which is enough to get iflipb to notice what's going on.
Here's the relevant .emacs excerpt:
; see http://www.emacswiki.org/emacs/iflipb
(require 'iflipb)
(global-set-key (kbd "<C-tab>") 'iflipb-next-buffer)
(global-set-key
(if (featurep 'xemacs) (kbd "<C-iso-left-tab>") (kbd "<C-S-tab>"))
'iflipb-previous-buffer)
(defun null-command ()
"Do nothing (other than standard command processing such as remembering this was the last command executed)"
(interactive))
(global-set-key "\C-c:" 'null-command)
So, it's kind of hacky, but it does work. Thanks to the posters at http://www.autohotkey.com/board/topic/72433-controltab/, who were trying to solve a similar problem.
Add the following to your .emacs file:
(global-set-key (kbd "<C-tab>") 'next-buffer)
I use windows batch file to open files in an already-running instance of Emacs using emacsclientw.exe. However, any file opened that way is opened in server mode, which means that I have to use C-x # to kill it, instead of the usual C-x k. How do I change this behavior?
My solution was to rebind it (well M-w actually) to:
(lambda ()
(interactive)
(if server-buffer-clients
(server-edit)
(kill-this-buffer)))
[edit: having now read the code for server-edit, it might be better to use server-done (depending on what you want). server-edit will switch you to a server-edited buffer (if any still exist) but server-done will simply switch you to the next buffer. You could also use the output of server-done to see if the buffer was actually killed (not the case if the file was open before invoking emacsclient) and then kill it if not. Or use server-kill-buffer as suggested elsewhere.]
Here is what i put in my .emacs to do this :
(add-hook 'server-switch-hook
(lambda ()
(local-set-key (kbd "C-x k") '(lambda ()
(interactive)
(if server-buffer-clients
(server-edit)
(ido-kill-buffer))))))
Like this C-x k work the usual way when i'm not finding a file from emacsclient (which for me is ido-kill-buffer), and if i'm using emacsclient, C-x k does server-edit if the client is waiting, or run ido-kill-buffer otherwise (if i used emacsclient -n).
use:
D:\> emacsclientw -n foo.txt
the -n says "no wait". This is in GNU Emacs 22.2.1 (i386-mingw-nt5.1.2600) of 2008-03-26 on RELEASE (and many prior versions, IIRC).
You know, I hate to suggest workarounds instead of a real solution... but after reading the server code, I am confused as to how emacs even determines that a buffer is a server buffer.
With that in mind, why not open up files like:
emacsclient --eval '(find-file "/path/to/file")'
This way emacs doesn't know that your buffer was opened via emacsclient, which sounds like what you really want.
Edit:
I'm not really happy with this, but it seems to work:
(global-set-key (kbd "C-x k") (lambda () (interactive) (server-kill-buffer (current-buffer))))
Okay, THIS did work for me:
(global-set-key (kbd "C-x k") '(lambda ()
(interactive)
(if server-buffer-clients
(server-done)
(kill-this-buffer))))
(this is the code from IvanAndrus's answer with the explicit changes from edits and comments, and using jrockway's keybinding.)
And, yes -- I am rebinding a standard keybinding. BUT it's a functional replacement NOT something completely different (eg, replacing kill-ring-save with kill-buffer stuff).
BTW, EmacsWiki has a couple of pages on this topic-- KillKey and KillingBuffer -- neither of which shed better light for me than the above (although the first-function on KillKey also used "server-edit"...).
I am not sure if that will work on windows, but on linux, emacs -daemon is just great.
With it, you don't have to run a different program, and your bindings are the same. I guess there are other advantages, but since I could never learn those emacsclient bindings, I never really used it, and can't say.
I don't think -daemon had been released yet, I am using 23.0.60.1 from CVS.