I am trying to test if a certain position of an Emacs window is visible thus is neither overlapped by another window nor somehow obscured by decoration facilities. To this end I set the mouse position to a certain point and then compare the set values to (mouse-position). However, I get somewhat different values.
How does the actual (mouse-position) differ from the set value?
(Provided that mouse is not moved by the user, indeed).
To test it quickly C-x C-e
(list (set-mouse-position (selected-frame) 4 4) (mouse-position))
As for pos-visible-in-window-p, this does not perform an actual test. To see this
(progn (sleep-for 5) (pos-visible-in-window-p 1))
with C-u C-x C-e and lower, hide the window. Alas, it still is true.
It would seem that pos-visible-in-window-p should do what you want.
Note that your expression moves the actual mouse pointer, i.e., it is visible to the user.
Related
How can I modify org-capture's behavior and make it place the newly opened buffer, after selecting a template, in a new vertically split window on Emacs? More precisely, how to make capture's template window be placed below (split-window-below) current focused or leftmost window?
This is a complicated subject (which I don't understand completely - caveat emptor!). The problem is that there is a long conceptual distance between org-capture and the function that actually does the window splitting, a function called split-window-sensibly. So there are many places where you could conceivably interject a change in the behavior, but the trouble is that whatever you do that way might break a lot of other things that have nothing to do with capture.
The doc string for split-window-sensibly (do C-h f split-window-sensibly RET to read it) does mention two variables however:
By default display-buffer routines call this function to split
the largest or least recently used window. To change the default
customize the option split-window-preferred-function.
You can enforce this function to not split WINDOW horizontally,
by setting (or binding) the variable split-width-threshold to
nil. If, in addition, you set split-height-threshold to zero,
chances increase that this function does split WINDOW vertically.
In order to not split WINDOW vertically, set (or bind) the
variable split-height-threshold to nil. Additionally, you can
set `split-width-threshold' to zero to make a horizontal split
more likely to occur.
So I would recommend that you define your own org-capture function that sets these variables using a let-bind before calling the "real" `org-capture:
(defun my-org-capture ()
(interactive)
(let ((split-width-threshold nil)
(split-height-threshold 0))
(org-capture)))
and use it instead of the "real" one. E.g. you can bind it to what the Org mode manual recommends by doing
(global-set-key (kbd "C-c c") 'my-org-capture)
(or modify whatever key binding you use).
The advantage of this is that it only modifies how you call org-capture, so there is virtually no chance of breaking anything else. And you can easily undo the change if necessary.
I'd like for the C-x o command (next window) to include windows in other frames as well as windows in the current frame.
Does anyone know how to pull this off? Is there another command that I should be using? Is there some snippet of elisp magic that can do this with ease?
C-x o is other-window. To go to an other frame use C-x 5 o which is other-frame.
Not sure if this is what you mean, but if you want to just cycle through buffers in the buffer list, regardless of frame:
Ctrl x→
Ctrl x←
These are bound to (next-buffer) and (previous-buffer), respectively.
This can be a first approximation.
http://www.gnu.org/software/emacs/manual/html_node/elisp/Cyclic-Window-Ordering.html
http://www.gnu.org/software/emacs/manual/html_node/elisp/Frames.html
other-window has a parameter to control how it deals with frames.
(global-set-key (kbd "C-x o") (lambda ()
(interactive)
(other-window 1 t)
(let ((nframe (window-frame (selected-window))))
(select-frame-set-input-focus nframe)
(make-frame-visible nframe))))
You must press C-x 5 o C-h to see all functions about working with frames.
Some of these function is other-frame.
I use the version 2.0 of ace-jump-mode. It takes about two minutes to understand how it works and since version 2.0 it allows to "jump" to another frame. You can jump to any character from any buffer/frame/window that you can actually see on a screen in three or four keypresses. It's very hard to beat.
It's a gigantic time saver anyway so I'd recommend checking it out because it's really convenient.
http://www.emacswiki.org/emacs/AceJump
And the "Emacs Rocks! Episode 10: Jumping around" two minutes screencast showing it in action:
http://www.youtube.com/watch?v=UZkpmegySnc
From C-h f next-window:
(next-window &optional WINDOW MINIBUF ALL-FRAMES) ...
ALL-FRAMES nil or omitted means consider all windows on WINDOW's
frame, plus the minibuffer window if specified by the MINIBUF
argument. If the minibuffer counts, consider all windows on all
frames that share that minibuffer too. The following non-nil values
of ALL-FRAMES have special meanings:
t means consider all windows on all existing frames.
`visible' means consider all windows on all visible frames.
0 (the number zero) means consider all windows on all visible and iconified frames.
A frame means consider all windows on that frame only.
Anything else means consider all windows on WINDOW's frame and no
others.
Somewhat ironically, other-window supports this as well, as it uses next-window. Unfortunately, I don't know of a way to pass non-numeric arguments interactively, but a simple function should do the trick:
(defun my-other-window (count)
(interactive "p")
(other-window count t))
You say "Is there a way to cycle through windows regardless of what frame they're in? That's really what I'm looking for?"
Yes, there is, with Icicles.
What you request is what command icicle-select-window does when you use a prefix arg. If you want that behavior always, you can define your own command that does it without a prefix arg:
(defun my-select-window ()
"Select window by name. Windows of all visible frames are candidates."
(interactive)
(let ((current-prefix-arg 1)) (icicle-select-window)))
You are prompted for the window name. But if you just want to cycle, without narrowing the candidates by typing part of the name, then just use C-down to get the window you want.
(A window name is the name of its displayed buffer, but suffixed as
needed by [NUMBER], to make the name unique. For example, if you have
two windows showing buffer *Help*, one of the windows will be called
*Help*[2] for use with this command.)
When I press ctrl+left-mouse-button in Emacs, I get the mouse buffer menu. This is my favourite way of switching buffers, but the list of buffers doesn't have to be too long before it re-organises the list into sub menus (fundamental, LISP, others etc...). I really hate this because I find it much harder to find the buffer I'm looking for.
My question is: How can I set the number of items in the mouse buffer menu that emacs will show before it breaks the menu into submenus? (I want to increase it, obviously!)
The following two variables give you some control over this:
mouse-buffer-menu-maxlen
mouse-buffer-menu-mode-mult
My interpretation is that the latter is the maximum number of buffers in a given major mode before that mode gets its own sub-menu, and the former is the maximum number of buffers allowed in any sub/menu before it is split into multiple menus.
setq as appropriate, or
M-x customize-group RET mouse RET
full code with details to add to .emacs file is below
also note that mouse-buffer-menu-mode-mult takes precedence
to evaluate the below and see effect immediately, highlight and type M-x eval-region or put cursor inside each () and type M-C-x
;; "ctrl - left click" buffer menu: increase number of items shown
;; set max length of this list. default 20. see next.
(setq mouse-buffer-menu-maxlen 30)
;; set # buffer in a mode before grouping begins. takes precedence over previous
;; set to 1 to always group by mode. default 4
(setq mouse-buffer-menu-mode-mult 8)
EDIT: Perhaps (in original post) I used the term "transient" incorrectly (I'm not familiar enough with the jargon yet). What I really mean is that the highlighted region will disappear immediately when the user presses a navigation keys eg. arrow-keys... (2nd EDIT: I've removed the word "transient")
The particular issue of selecting a region so the user gets "cursor-key movement will make highlighting disappear" has been the bane of my existance recently. I get differnt results depending on how I run the following script.
Why does it give different results, and more specifically, is there a way to make it produce "cursor-keys make highlighting disappear" regardless of which mode is running, or whether it is being evaluated while testing? .. CUA mode has this behaviour, but I really need that non CUA mode does it too (and eval, if possible)...
Here are the results, followed by the code. (GNU Emacs 23.1.1)
CUA mode enabled
Evaluate via C-x C-e — both (call-trans-hi) and (trans-hi)
NO-GO: Both set mark and move point to EOL, but nothing is highlighted.
Execute M-x call-trans-hi
ok: Works fine; the region is highlighted and then disappears the first time a key is pressed.
Via key binding C-f1
ok: Works fine; the region is highlighted and then disappears the first time a key is pressed.
no CUA mode (pretty much std emacs)
Evaluate via C-x C-e
NO-GO: Same as 1. when CUA is enabled.
Execute M-x call-trans-hi
NO-GO: The line is highlighted, but it is sticky! and requires C-g (keyboard-quit) to clear it.
Via key binding C-f1
NO-GO: The line is highlighted, but it is sticky! and requires C-g (keyboard-quit) to clear it.
;test (trans-hi) EOL
(defun trans-hi ()
"transient highlight"
(beginning-of-line)
(push-mark (point))
(end-of-line)
(activate-mark))
;test (call-trans-hi) EOL
(defun call-trans-hi ()
"call transient highlight"
(interactive)
(trans-hi))
(global-set-key [C-f1] 'call-trans-hi)
When you look at the source of activate-mark, you can see that it's just setting some variables. I suppose that's why you don't see the mark in both 1., because the actual highlighting happens in some stuff that's done when executing functions interactively instead of just calling them.
In the other cases of no CUA-mode, that just how transient highlighting works outside of CUA-mode. If you want the CUA-mode behaviour, use CUA-mode resp. that part of it.
EDIT:
Does this change (the addition of the setq line) to trans-hi make the highlighting work the way you want?
(defun trans-hi ()
"transient highlight"
(beginning-of-line)
(push-mark (point))
(end-of-line)
(setq transient-mark-mode (cons 'only transient-mark-mode))
(activate-mark))
If you want to see the region highlighted when you mark it, you need
to activate the minor mode transient-mark-mode.
When a region is highlighted and a character insterted the default is
to disable the highlighting and insert the character at the cursor.
If you wish you can delete the selected region by activating the minor
mode delete-selection-mode.
This may be too involved.
Considering:
In emacs in r-mode or lisp mode (etc) information can be sent directly (copied, pasted, evaluated) from one buffer to the the R or Lisp interpreter.
I typically configure an emacs session to have 3 windows - a large horizontal window on top and two windows beneath it. (How) could I configure, which keys/ commands might I use to send the kill-ring to the last cursor position of the top window / buffer?
The buffer / window will not always necessarily have the same contents/file. (How) could I name it upon initialization?
Similar to C-X, C-B or C-X, B how might I specify which of the three window positions to go to (based on position)?
See window-at. For example,
(defun yank-into-top-window (&optional arg)
(interactive "*P")
(with-selected-window (window-at 0 0)
(yank arg)))
I think you're going to have to write lisp code to do this effectively. Basically, you'd want a minor mode that sets up the two subwindows -- which isn't hard, it happens in compile mode from M-x compile -- and then make special keybindings for the keys you want to use.