Emacs tends to open two horizontally separated windows, one on top of the other (I think windows is the proper emacs term). Since I am working with a wide screen I find it easier and better to work with two vertically separated windows, arranged side by side within the emacs frame.
I know how to open a new vertically separated window using C-x 3 but how do you rearrange windows that emacs opens itself (for example when M-x compile is invoked opening a compilation/debugging window) from horizontal to vertical?
I had the same problem, this is what I currently use. Just drop it into your Emacs init file:
;; The default behaviour of `display-buffer' is to always create a new
;; window. As I normally use a large display sporting a number of
;; side-by-side windows, this is a bit obnoxious.
;;
;; The code below will make Emacs reuse existing windows, with the
;; exception that if have a single window open in a large display, it
;; will be split horisontally.
(setq pop-up-windows nil)
(defun my-display-buffer-function (buf not-this-window)
(if (and (not pop-up-frames)
(one-window-p)
(or not-this-window
(not (eq (window-buffer (selected-window)) buf)))
(> (frame-width) 162))
(split-window-horizontally))
;; Note: Some modules sets `pop-up-windows' to t before calling
;; `display-buffer' -- Why, oh, why!
(let ((display-buffer-function nil)
(pop-up-windows nil))
(display-buffer buf not-this-window)))
(setq display-buffer-function 'my-display-buffer-function)
Take a look at the split-height-threshold and the split-height-threshold variables, both customizable.
For further information on what values they take, C-h f split-window-sensibly RET. This Emacs Lisp touches the topic superficially.
This affects how display-buffer works, which probably compile and many other commands use.
Here's my solution:
(defun split-window-prefer-side-by-side (&optional window)
(let ((split-height-threshold (and (< (window-width window)
split-width-threshold)
split-height-threshold)))
(split-window-sensibly window)))
(setq split-window-preferred-function 'split-window-prefer-side-by-side)
This still consults split-*-threshold variable values, just prefers side-by-side windows when both splitting directions are acceptable.
Related
Edit: What the poster calls a "window", Emacs calls a "frame". I fixed the title.
Concisely, the question is: in a window, how do I switch quickly to a buffer previously visited in that window, even if it's already opened in another window?
A more detailed description follows.
Normally, in order to switch window to previous buffer one just types C-x b RET. That is, the default argument to switch-to-buffer (or ido-switch-buffer) is the previous buffer.
This is not, however, the case when that (previous) buffer is already shown in another window. That's exactly what bugs me.
Let's consider an example. Suppose I have three buffers (A, B and C) and two windows showing buffers A and B (C is not visible at this point).
Then I open buffer A in the second window, too. So, now I have buffer A shown in both windows. Then I switch (C-x b RET) to B again. After that, C-x b RET will bring me not to A, but to C because A is already shown in the other window.
How do I make C-x b RET behave more consistently?
Update
After this problem had been solved, I realized I needed more: namely, for point position to be remembered per-window, not per buffer. Luckily, there're ready-made solutions:
winpoint
per-window-point
They're quite similar; for a discussion of differences see here.
I've found a fix for switch-to-buffer. It eventually calls
(other-buffer (current-buffer))
while in order to fix your problem, the call needs to look like this:
(other-buffer (current-buffer) t)
i.e. the visible-ok argument needs to be t.
Here's an advice to have it always at t. Hopefully it won't break other stuff that uses other-buffer:
(defadvice other-buffer (around fix-switch-to-buffer
(&optional buffer visible-ok frame) activate)
(setq visible-ok t)
ad-do-it)
Note that ido-switch-to-buffer uses a different machinery, so a different method is needed to fix it.
update: fix for ido-switch-to-buffer
I needed to re-define ido-make-buffer-list:
(defun ido-make-buffer-list (default)
(let* ((ido-current-buffers (list (buffer-name (current-buffer))))
(ido-temp-list (ido-make-buffer-list-1 (selected-frame) ido-current-buffers)))
(if ido-temp-list
(nconc ido-temp-list ido-current-buffers)
(setq ido-temp-list ido-current-buffers))
(if default
(setq ido-temp-list
(cons default (delete default ido-temp-list))))
(if (bound-and-true-p ido-enable-virtual-buffers)
(ido-add-virtual-buffers-to-list))
(run-hooks 'ido-make-buffer-list-hook)
ido-temp-list))
The diff is just one line, but it's too messy to advice it.
update: use new advice system for other-buffer
The old stuff should still work for quite a while, but here's the new approach:
(defun other-buffer-advice (orig-fun &optional buffer visible-ok frame)
(funcall orig-fun buffer t frame))
(advice-add 'other-buffer :around #'other-buffer-advice)
;; (advice-remove 'other-buffer :around #'other-buffer-advice)
Instead of advising the built-in function other-buffer, you can pre-select visible buffers using a package.
1 Using Ivy
If you're using Ivy, you can use abo-abo's approach to override the lower-use function ivy-switch-buffer.
(defun user/ivy-switch-buffer ()
"Switch to another buffer with visible-ok preselection."
(interactive)
(ivy-read "Switch to buffer: " #'internal-complete-buffer
:keymap ivy-switch-buffer-map
:preselect (buffer-name (other-buffer (current-buffer) t))
:action #'ivy--switch-buffer-action
:matcher #'ivy--switch-buffer-matcher
:caller 'ivy-switch-buffer))
(advice-add 'ivy-switch-buffer :override #'user/ivy-switch-buffer)
2 Using Ido mode
2.1 Switching to a buffer shown in another frame
If by "window" you really mean "frame" (i.e., you'd like to ido-switch-buffer to a buffer that is currently shown in another frame), then ido-mode gives you the behavior you're looking for when you change ido-default-buffer-method from its default value of raise-frame to selected-window:
(setq ido-default-buffer-method 'selected-window)
Emacs constructs an independent buffer list for each frame, so the only thing you have to do is to configure Ido to avoid jumping to another frame when you switch buffers.
2.2 Switching to a buffer that is shown in another window inside the same frame
To get this behavior across windows within the same frame, you should hook a function that reorders the buffer list onto ido-make-buffer-list-hook.
From ido.el:
;; Changing the list of files
;; --------------------------
;; By default, the list of current files is most recent first,
;; oldest last, with the exception that the files visible in the
;; current frame are put at the end of the list. A hook exists to
;; allow other functions to order the list. For example, if you add:
;;
;; (add-hook 'ido-make-buffer-list-hook 'ido-summary-buffers-to-end)
;;
;; then all files matching "Summary" are moved to the end of the
;; list. (I find this handy for keeping the INBOX Summary and so on
;; out of the way.) It also moves files matching "output\*$" to the
;; end of the list (these are created by AUCTeX when compiling.)
;; Other functions could be made available which alter the list of
;; matching files (either deleting or rearranging elements.)
I'm having a hard time making this emacs -nw work effectively under the terminal mode (emacs -nw).
Some setup information:
The working server is connected via SSH, and emacs is running on the server. Usually I'm connecting using SSH and "emacs -nw" to work on my files.
The emacs config is picked up from: https://hugoheden.wordpress.com/2009/03/08/copypaste-with-emacs-in-terminal/
;; make mouse selection to be emacs region marking
(require 'mouse)
(xterm-mouse-mode t)
(defun track-mouse (e))
(setq mouse-sel-mode t)
;; enable clipboard in emacs
(setq x-select-enable-clipboard t)
;; enable copy/paste between emacs and other apps (terminal version of emacs)
(unless window-system
(when (getenv "DISPLAY")
;; Callback for when user cuts
(defun xsel-cut-function (text &optional push)
;; Insert text to temp-buffer, and "send" content to xsel stdin
(with-temp-buffer
(insert text)
;; I prefer using the "clipboard" selection (the one the
;; typically is used by c-c/c-v) before the primary selection
;; (that uses mouse-select/middle-button-click)
(call-process-region (point-min) (point-max) "xsel" nil 0 nil "--clipboard" "--input")))
;; Call back for when user pastes
(defun xsel-paste-function()
;; Find out what is current selection by xsel. If it is different
;; from the top of the kill-ring (car kill-ring), then return
;; it. Else, nil is returned, so whatever is in the top of the
;; kill-ring will be used.
(let ((xsel-output (shell-command-to-string "xsel --clipboard --output")))
(unless (string= (car kill-ring) xsel-output)
xsel-output )))
;; Attach callbacks to hooks
(setq interprogram-cut-function 'xsel-cut-function)
(setq interprogram-paste-function 'xsel-paste-function)
;; Idea from
;; http://shreevatsa.wordpress.com/2006/10/22/emacs-copypaste-and-x/
;; http://www.mail-archive.com/help-gnu-emacs#gnu.org/msg03577.html
))
The reason to have:
(require 'mouse)
(xterm-mouse-mode t)
(defun track-mouse (e))
(setq mouse-sel-mode t)
is to enable mouse selection over text such that the text region is highlighted just as "C-x SPC" marking the region. Then I can use "M-x w" to copy and "C-x y" to paste text within emacs and between emacs and other apps.
All look perfect except that any operations related to X are REALLY SLOW! My connection to the remote server is smooth -- the latency is usually under 100ms. But to kill one line of text using "C-x k", it takes ~5 seconds! To paste it, it takes another 5 seconds!
When copy/paste is frequent sometimes, this becomes really annoying. I think this is related to the X sever messaging, but not sure if there is good way to fix this.
Any ideas?
Thanks!
This is not an ideal solution per se, but i figured out a way that I feel better than the previous one.
The idea is to get rid of X which causes heavy latency issues, i.e. keep only the following:
;; enable clipboard in emacs
(setq x-select-enable-clipboard t)
The results are:
copy/paste within Emacs is straightforward and fast.
copy from other apps to Emacs: Ctrl+Shift+v
copy from Emacs to other apps: mouse selection is now on X Selection, so right-click and copy shall copy the text into the Selection. Note that 'M-w" now won't copy anything into Selection or system clipboard.
This is again a compromise rather than a solution, but considering the fact that i copy/paste more often than inter-app operations, this is acceptable at the moment.
Still looking forward to a good solution!
You can accomplish this by using a terminal escape code!
There is a unique category of terminal escape codes called "Operating System Controls" (OSC) and one of these sequences (\033]52) is meant for interacting with the system clipboard. The great thing is that your terminal doesn't care where the code came from so it will work in remote sessions as well.
Most terminal emulators support it (iTerm2, OS X Terminal, and I think all Linux terminals besides GNOME). You can test if your terminal supports this sequence by simply running:
$ printf "\033]52;c;$(printf "Hello, world" | base64)\a"
Then paste from your system clipboard. If it pastes "Hello, world" then your terminal supports it!
I have this function in my init.el so when I call yank-to-clipboard Emacs will yank the value from my kill ring into the system clipboard:
(defun yank-to-clipboard ()
"Use ANSI OSC 52 escape sequence to attempt clipboard copy"
(interactive)
(send-string-to-terminal
(format "\033]52;c;%s\a"
(base64-encode-string
(encode-coding-string
(substring-no-properties
(nth 0 kill-ring)) 'utf-8) t))))
As I type this, I stumbled upon an almost-identical script supported by Chromium community: https://chromium.googlesource.com/apps/libapps/+/master/hterm/etc/osc52.el
For those running Emacs inside Tmux:
Tmux consumes the sequence, so you'll need to pipe the sequence to the Tmux active tty for this to work. I have a solution in my blog post here: https://justinchips.medium.com/have-vim-emacs-tmux-use-system-clipboard-4c9d901eef40
To extend on #justinokamoto's answer for use in tmux, it works great and is truly amazing. I haven't debugged it with e.g. tramp or other fancy emacs settings but to get it to work
Follow https://sunaku.github.io/tmux-yank-osc52.html great instructions, modifying your tmux.conf and ~/bin/yank
Make sure terminal access to your clipboard is enabled on your terminal
Then to pull into emacs you can use a function like:
(Caveat emptor, I am very new to elisp. This writes to a temporary file in /tmp/yank)
(defun custom-terminal-yank (&rest args)
(message "-> CLIP")
;; FOR EVIL MODE: UNCOMMENT SO FIRST YANKS TO KILL RING
;; need to yank first, with all those args
;; ;; https://emacs.stackexchange.com/questions/19215/how-to-write-a-transparent-pass-through-function-wrapper
;; (interactive (advice-eval-interactive-spec
;; (cadr (interactive-form #'evil-yank))))
;; (apply #'evil-yank args)
;; https://stackoverflow.com/questions/27764059/emacs-terminal-mode-how-to-copy-and-paste-efficiently
;; https://sunaku.github.io/tmux-yank-osc52.html
(f-write-text (nth 0 kill-ring) 'utf-8 "/tmp/yank")
(send-string-to-terminal (shell-command-to-string "~/bin/yank /tmp/yank"))
)
If anyone else uses evil mode as well (just to make things complicated) you can uncomment those lines and use something like
(define-key evil-visual-state-map "Y" 'jonah-terminal-yank)
So that normal "y" is for normal yanking in visual mode, but "Y" is for cross-clipboard yanking
I´d like to have the following workflow using emacs 23.4 as a python (2.7) IDE on Debian:
Emacs initiates with 2 windows side-by-side when opening a file like $ emacs file.py
There´s already a shell in the left window and the buffer file.py in the right window.
A shortcut executes the code (and another shortcut for parts of it) and the result can be seen in the left window (ipython shell). The focus remains at the right window and the buffers don´t change when the command is executed.
A shortcut easily switches the focus from left to right and the other way around.
I could, so far, accomplish everything except the second item (I have to make the buffer visible manually), which seems simple. I´ve been reading the emacs lips reference manual, so that I can customize emacs myself, but I´m still a beginner in emacs. I also found some similar questions, but not fully helpful. Here are some relevant parts of my .emacs.
;; Initial frame size and position (1280x1024)
(setq default-frame-alist
'((top . 45) (left . 45)
(width . 142) (height . 54)))
(if (window-system)
(split-window-horizontally (floor (* 0.49 (window-width))))
)
; python-mode
(setq py-install-directory "~/.emacs.d/python-mode.el-6.1.3")
(add-to-list 'load-path py-install-directory)
(require 'python-mode)
; use IPython
(setq-default py-shell-name "ipython")
(setq-default py-which-bufname "IPython")
; use the wx backend, for both mayavi and matplotlib
(setq py-python-command-args
'("--gui=wx" "--pylab=wx" "--colors=linux"))
(setq py-force-py-shell-name-p t)
; switch to the interpreter after executing code
(setq py-shell-switch-buffers-on-execute-p t)
;(setq py-switch-buffers-on-execute-p t)
; don't split windows
(setq py-split-windows-on-execute-p nil)
; try to automagically figure out indentation
(setq py-smart-indentation t)
(defun goto-python-shell ()
"Go to the python command window (start it if needed)"
(interactive)
(setq current-python-script-buffer (current-buffer))
(py-shell)
(end-of-buffer)
)
(goto-python-shell)
I believe the solution is simple and lies on the functions/variables: switch-to-buffer, initial-buffer-choice, other-window, py-shell-switch-buffers-on-execute-p, py-switch-buffers-on-execute-p.
However, I still couldn't find a solution that makes it all work.
EDIT:
I was able to have my desired behavior, substituting the last part for:
(switch-to-buffer (py-shell))
(end-of-buffer)
(other-window 3)
(switch-to-buffer (current-buffer))
, since I found out with get-buffer-window that the left window appears as 3 and right window as 6.
When py-split-windows-on-execute-p, py-switch-buffers-on-execute-p are set, it should work as expected - no need to hand-write splitting.
Remains the horizontal/vertical question.
For this python-mode.el provides a customization of py-split-windows-on-execute-function in current trunk:
https://code.launchpad.net/python-mode
I have been wondering for a very long time now: how to get a dedicated misc buffer in Emacs?
Auto-completion, function descriptions and perhaps documentation all can go there without ending up somewhere unexpected, but instead at a predefined location (a quarter of the screen perhaps?).
(I'm assuming you mean a dedicated window instead of a dedicated buffer.) If you keep a window open without doing any other window-splitting commands, help/repl buffers will automatically use it. You can change the size of the window as described in this question.
If you want to do be able to do normal window manipulation but have help windows be a certain size, I suggest you investigate temp-buffer-show-hook, a hook that is run when temporary buffers (such as help buffers) are shown. I haven't tried it, but it would probably be possible to set it to a function that arranges your window configuration in a particular way.
Here is what I do in One On One, to define a dedicated *Help* frame:
;; *Help* frame
(if 1on1-*Help*-frame-flag
(add-to-list
'special-display-buffer-names
(list "*Help*" '1on1-display-*Help*-frame
(list (cons 'background-color 1on1-help-frame-background)
(cons 'mouse-color 1on1-help-frame-mouse+cursor-color)
(cons 'cursor-color 1on1-help-frame-mouse+cursor-color)
'(height . 40))))
(setq special-display-buffer-names
(1on1-remove-if (lambda (elt) (equal "*Help*" (car elt)))
special-display-buffer-names)))
(defun 1on1-display-*Help*-frame (buf &optional args)
"Display *Help* buffer in its own frame.
`special-display-function' is used to do the actual displaying.
BUF and ARGS are the arguments to `special-display-function'."
(let ((old-ptr-shape (and (boundp 'x-pointer-shape) x-pointer-shape))
return-window)
(when (boundp 'x-pointer-xterm) (setq x-pointer-shape x-pointer-xterm))
(setq return-window (select-window (funcall special-display-function buf args)))
(raise-frame)
(setq x-pointer-shape old-ptr-shape)
return-window))
You don't need all of those details (pointer shapes etc.), but that gives you the idea. The main thing is to put *Help* on special-display-buffer-names. That's really all you need to do.
The 1on1-* variables used for the frame parameters here are pretty obvious. The *-remove-if function is a standard remove-if. The complete code is here: oneonone.el.
I am coding in python using Emacs. I have modified ".emacs" to suit my needs. However, I do not know how to change the default vertical split behavior of windows when executing current buffer.
I know that:
(setq split-height-threshold nil)
(setq split-width-threshold 0)
works in general. But it does not work when I execute buffer for the first time using C-c C-c
Despite having the above code in my ~/.emacs, the following happens on C-c C-c :
I hope my question is clear, let me know if you have any idea about this.
I use the following. It fixes your problem (I hope) as well as preventing Emacs from splitting windows in the first place.
;;; ------------------------------------------------------------------
;;; display-buffer
;; The default behaviour of `display-buffer' is to always create a new
;; window. As I normally use a large display sporting a number of
;; side-by-side windows, this is a bit obnoxious.
;;
;; The code below will make Emacs reuse existing windows, with the
;; exception that if have a single window open in a large display, it
;; will be split horisontally.
(setq pop-up-windows nil)
(defun my-display-buffer-function (buf not-this-window)
(if (and (not pop-up-frames)
(one-window-p)
(or not-this-window
(not (eq (window-buffer (selected-window)) buf)))
(> (frame-width) 162))
(split-window-horizontally))
;; Note: Some modules sets `pop-up-windows' to t before calling
;; `display-buffer' -- Why, oh, why!
(let ((display-buffer-function nil)
(pop-up-windows nil))
(display-buffer buf not-this-window)))
(setq display-buffer-function 'my-display-buffer-function)