Mercurial > emacs
annotate lisp/windmove.el @ 43160:630c8b6deafd
(mark_stack): Don't assume sizeof (Lisp_Object) is 4.
author | Andreas Schwab <schwab@suse.de> |
---|---|
date | Thu, 07 Feb 2002 11:05:08 +0000 |
parents | 62d7faafb853 |
children | 8de5fa67b6cb |
rev | line source |
---|---|
38436
b174db545cfd
Some fixes to follow coding conventions.
Pavel Janík <Pavel@Janik.cz>
parents:
30892
diff
changeset
|
1 ;;; windmove.el --- directional window-selection routines |
27545 | 2 ;; |
3 ;; Copyright (C) 1998, 1999, 2000 Free Software Foundation, Inc. | |
4 ;; | |
5 ;; Author: Hovav Shacham (hovav@cs.stanford.edu) | |
6 ;; Created: 17 October 1998 | |
30892
495502641770
(windmove) <defgroup>: Add :version.
Dave Love <fx@gnu.org>
parents:
27545
diff
changeset
|
7 ;; Keywords: window, movement, convenience |
27545 | 8 ;; |
9 ;; This file is part of GNU Emacs. | |
10 ;; | |
11 ;; GNU Emacs is free software; you can redistribute it and/or modify | |
12 ;; it under the terms of the GNU General Public License as published by | |
13 ;; the Free Software Foundation; either version 2, or (at your option) | |
14 ;; any later version. | |
15 ;; | |
16 ;; GNU Emacs is distributed in the hope that it will be useful, | |
17 ;; but WITHOUT ANY WARRANTY; without even the implied warranty of | |
18 ;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the | |
19 ;; GNU General Public License for more details. | |
20 ;; | |
21 ;; You should have received a copy of the GNU General Public License | |
22 ;; along with GNU Emacs; see the file COPYING. If not, write to the | |
23 ;; Free Software Foundation, Inc., 59 Temple Place - Suite 330, | |
24 ;; Boston, MA 02111-1307, USA. | |
25 ;; | |
26 ;; -------------------------------------------------------------------- | |
27 | |
28 ;;; Commentary: | |
29 ;; | |
30 ;; This package defines a set of routines, windmove-{left,up,right, | |
31 ;; down}, for selection of windows in a frame geometrically. For | |
32 ;; example, `windmove-right' selects the window immediately to the | |
33 ;; right of the currently-selected one. This functionality is similar | |
34 ;; to the window-selection controls of the BRIEF editor of yore. | |
35 ;; | |
36 ;; One subtle point is what happens when the window to the right has | |
37 ;; been split vertically; for example, consider a call to | |
38 ;; `windmove-right' in this setup: | |
39 ;; | |
40 ;; ------------- | |
41 ;; | | A | | |
42 ;; | | | | |
43 ;; | |----- | |
44 ;; | * | | (* is point in the currently | |
45 ;; | | B | selected window) | |
46 ;; | | | | |
47 ;; ------------- | |
48 ;; | |
49 ;; There are (at least) three reasonable things to do: | |
50 ;; (1) Always move to the window to the right of the top edge of the | |
51 ;; selected window; in this case, this policy selects A. | |
52 ;; (2) Always move to the window to the right of the bottom edge of | |
53 ;; the selected window; in this case, this policy selects B. | |
30892
495502641770
(windmove) <defgroup>: Add :version.
Dave Love <fx@gnu.org>
parents:
27545
diff
changeset
|
54 ;; (3) Move to the window to the right of point in the selected |
27545 | 55 ;; window. This may select either A or B, depending on the |
56 ;; position of point; in the illustrated example, it would select | |
57 ;; B. | |
58 ;; | |
59 ;; Similar issues arise for all the movement functions. Windmove | |
60 ;; resolves this problem by allowing the user to specify behavior | |
61 ;; through a prefix argument. The cases are thus: | |
62 ;; * if no argument is given to the movement functions, or the | |
63 ;; argument given is zero, movement is relative to point; | |
64 ;; * if a positive argument is given, movement is relative to the top | |
65 ;; or left edge of the selected window, depending on whether the | |
66 ;; movement is to be horizontal or vertical; | |
67 ;; * if a negative argument is given, movement is relative to the | |
68 ;; bottom or right edge of the selected window, depending on whether | |
69 ;; the movement is to be horizontal or vertical. | |
70 ;; | |
71 ;; | |
72 ;; Another feature enables wrap-around mode when the variable | |
73 ;; `windmove-wrap-around' is set to a non-nil value. In this mode, | |
74 ;; movement that falls off the edge of the frame will wrap around to | |
75 ;; find the window on the opposite side of the frame. Windmove does | |
76 ;; the Right Thing about the minibuffer; for example, consider: | |
77 ;; | |
78 ;; ------------- | |
79 ;; | * | | |
80 ;; |-----------| | |
81 ;; | A | | |
82 ;; |-----------| (* is point in the currently | |
83 ;; | B | C | selected window) | |
84 ;; | | | | |
85 ;; ------------- | |
86 ;; | |
87 ;; With wraparound enabled, windmove-down will move to A, while | |
88 ;; windmove-up will move to the minibuffer if it is active, or to | |
89 ;; either B or C depending on the prefix argument. | |
90 ;; | |
91 ;; | |
92 ;; A set of default keybindings is supplied: shift-{left,up,right,down} | |
93 ;; invoke the corresponding Windmove function. See the installation | |
94 ;; section if you wish to use these keybindings. | |
95 | |
96 | |
97 ;; Installation: | |
98 ;; | |
99 ;; Put the following line in your `.emacs' file: | |
100 ;; | |
101 ;; (windmove-default-keybindings) ; default keybindings | |
102 ;; | |
103 ;; | |
104 ;; If you wish to enable wrap-around, also add a line like: | |
105 ;; | |
106 ;; (setq windmove-wrap-around t) | |
107 ;; | |
108 ;; | |
109 ;; Note: If you have an Emacs that manifests a bug that sometimes | |
110 ;; causes the occasional creation of a "lost column" between windows, | |
111 ;; so that two adjacent windows do not actually touch, you may want to | |
112 ;; increase the value of `windmove-window-distance-delta' to 2 or 3: | |
113 ;; | |
114 ;; (setq windmove-window-distance-delta 2) | |
115 ;; | |
116 | |
117 ;; Acknowledgements: | |
118 ;; | |
119 ;; Special thanks to Julian Assange (proff@iq.org), whose | |
120 ;; change-windows-intuitively.el predates Windmove, and provided the | |
121 ;; inspiration for it. Kin Cho (kin@symmetrycomm.com) was the first | |
122 ;; to suggest wrap-around behavior. Thanks also to Gerd Moellmann | |
123 ;; (gerd@gnu.org) for his comments and suggestions. | |
124 | |
125 ;;; Code: | |
126 | |
127 | |
128 ;; User configurable variables: | |
129 | |
130 ;; For customize ... | |
131 (defgroup windmove nil | |
132 "Directional selection of windows in a frame." | |
133 :prefix "windmove-" | |
30892
495502641770
(windmove) <defgroup>: Add :version.
Dave Love <fx@gnu.org>
parents:
27545
diff
changeset
|
134 :version "21.1" |
27545 | 135 :group 'windows |
136 :group 'convenience) | |
137 | |
138 | |
139 (defcustom windmove-wrap-around nil | |
140 "Whether movement off the edge of the frame wraps around. | |
141 If this variable is set to t, moving left from the leftmost window in | |
142 a frame will find the rightmost one, and similarly for the other | |
143 directions. The minibuffer is skipped over in up/down movements if it | |
144 is inactive." | |
145 :type 'boolean | |
146 :group 'windmove) | |
147 | |
148 ;; If your Emacs sometimes places an empty column between two adjacent | |
149 ;; windows, you may wish to set this delta to 2. | |
150 (defcustom windmove-window-distance-delta 1 | |
151 "How far away from the current window to look for an adjacent window. | |
152 Measured in characters either horizontally or vertically; setting this | |
153 to a value larger than 1 may be useful in getting around window- | |
154 placement bugs in old versions of Emacs." | |
155 :type 'number | |
156 :group 'windmove) | |
157 | |
158 | |
159 | |
160 ;; Implementation overview: | |
161 ;; | |
162 ;; The conceptual framework behind this code is all fairly simple. We | |
163 ;; are on one window; we wish to move to another. The correct window | |
164 ;; to move to is determined by the position of point in the current | |
165 ;; window as well as the overall window setup. | |
166 ;; | |
167 ;; Early on, I made the decision to base my implementation around the | |
168 ;; built-in function `window-at'. This function takes a frame-based | |
169 ;; coordinate, and returns the window that contains it. Using this | |
170 ;; function, the job of the various top-level windmove functions can | |
171 ;; be decomposed: first, find the current frame-based location of | |
172 ;; point; second, manipulate it in some way to give a new location, | |
173 ;; that hopefully falls in the window immediately at left (or right, | |
174 ;; etc.); third, use `window-at' and `select-window' to select the | |
175 ;; window at that new location. | |
176 ;; | |
177 ;; This is probably not the only possible architecture, and it turns | |
178 ;; out to have some inherent cruftiness. (Well, okay, the third step | |
179 ;; is pretty clean....) We will consider each step in turn. | |
180 ;; | |
181 ;; A quick digression about coordinate frames: most of the functions | |
182 ;; in the windmove package deal with screen coordinates in one way or | |
183 ;; another. These coordinates are always relative to some reference | |
184 ;; points. Window-based coordinates have their reference point in the | |
185 ;; upper-left-hand corner of whatever window is being talked about; | |
186 ;; frame-based coordinates have their reference point in the | |
187 ;; upper-left-hand corner of the entire frame (of which the current | |
188 ;; window is a component). | |
189 ;; | |
190 ;; All coordinates are zero-based, which simply means that the | |
191 ;; reference point (whatever it is) is assigned the value (x=0, y=0). | |
192 ;; X-coordinates grow down the screen, and Y-coordinates grow towards | |
193 ;; the right of the screen. | |
194 ;; | |
195 ;; Okay, back to work. The first step is to gather information about | |
196 ;; the frame-based coordinates of point, or rather, the reference | |
197 ;; location. The reference location can be point, or the upper-left, | |
198 ;; or the lower-right corner of the window; the particular one used is | |
199 ;; controlled by the prefix argument to `windmove-left' and all the | |
200 ;; rest. | |
201 ;; | |
202 ;; This work is done by `windmove-reference-loc'. It can figure out | |
203 ;; the locations of the corners by calling `window-edges', but to | |
204 ;; calculate the frame-based location of point, it calls the workhorse | |
205 ;; function `windmove-coordinates-of-position', which itself calls the | |
206 ;; incredibly hairy builtin `compute-motion'. There is a good deal of | |
207 ;; black magic in getting all the arguments to this function just right. | |
208 ;; | |
209 ;; The second step is more messy. Conceptually, it is fairly simple: | |
210 ;; if we know the reference location, and the coordinates of the | |
211 ;; current window, we can "throw" our reference point just over the | |
212 ;; appropriate edge of the window, and see what other window is | |
213 ;; there. More explicitly, consider this example from the user | |
214 ;; documentation above. | |
215 ;; | |
216 ;; ------------- | |
217 ;; | | A | | |
218 ;; | | | | |
219 ;; | |----- | |
220 ;; | * | | (* is point in the currently | |
221 ;; | | B | selected window) | |
222 ;; | | | | |
223 ;; ------------- | |
224 ;; | |
225 ;; The asterisk marks the reference point; we wish to move right. | |
226 ;; Since we are moving horizontally, the Y coordinate of the new | |
227 ;; location will be the same. The X coordinate can be such that it is | |
228 ;; just past the edge of the present window. Obviously, the new point | |
229 ;; will be inside window B. This in itself is fairly simple: using | |
230 ;; the result of `windmove-reference-loc' and `window-edges', all the | |
231 ;; necessary math can be performed. (Having said that, there is a | |
232 ;; good deal of room for off-by-one errors, and Emacs 19.34, at least, | |
233 ;; sometimes manifests a bug where two windows don't actually touch, | |
234 ;; so a larger skip is required.) The actual math here is done by | |
235 ;; `windmove-other-window-loc'. | |
236 ;; | |
237 ;; But we can't just pass the result of `windmove-other-window-loc' to | |
238 ;; `window-at' directly. Why not? Suppose a move would take us off | |
239 ;; the edge of the screen, say to the left. We want to give a | |
240 ;; descriptive error message to the user. Or, suppose that a move | |
241 ;; would place us in the minibuffer. What if the minibuffer is | |
242 ;; inactive? | |
243 ;; | |
244 ;; Actually, the whole subject of the minibuffer edge of the frame is | |
245 ;; rather messy. It turns out that with a sufficiently large delta, | |
246 ;; we can fly off the bottom edge of the frame and miss the minibuffer | |
247 ;; altogther. This, I think, is never right: if there's a minibuffer | |
248 ;; and you're not in it, and you move down, the minibuffer should be | |
249 ;; in your way. | |
250 ;; | |
251 ;; (By the way, I'm not totally sure that the code does the right | |
252 ;; thing in really weird cases, like a frame with no minibuffer.) | |
253 ;; | |
254 ;; So, what we need is some ways to do constraining and such. The | |
255 ;; early versions of windmove took a fairly simplistic approach to all | |
256 ;; this. When I added the wrap-around option, those internals had to | |
257 ;; be rewritten. After a *lot* of futzing around, I came up with a | |
258 ;; two-step process that I think is general enough to cover the | |
259 ;; relevant cases. (I'm not totally happy with having to pass the | |
260 ;; window variable as deep as I do, but we can't have everything.) | |
261 ;; | |
262 ;; In the first phase, we make sure that the new location is sane. | |
263 ;; "Sane" means that we can only fall of the edge of the frame in the | |
264 ;; direction we're moving in, and that we don't miss the minibuffer if | |
30892
495502641770
(windmove) <defgroup>: Add :version.
Dave Love <fx@gnu.org>
parents:
27545
diff
changeset
|
265 ;; we're moving down and not already in the minibuffer. The function |
27545 | 266 ;; `windmove-constrain-loc-for-movement' takes care of all this. |
267 ;; | |
268 ;; Then, we handle the wraparound, if it's enabled. The function | |
269 ;; `windmove-wrap-loc-for-movement' takes coordinate values (both X | |
270 ;; and Y) that fall off the edge of the frame, and replaces them with | |
271 ;; values on the other side of the frame. It also has special | |
272 ;; minibuffer-handling code again, because we want to wrap through the | |
273 ;; minibuffer if it's not enabled. | |
274 ;; | |
275 ;; So, that's it. Seems to work. All of this work is done by the fun | |
276 ;; function `windmove-find-other-window'. | |
277 ;; | |
278 ;; So, now we have a window to move to (or nil if something's gone | |
279 ;; wrong). The function `windmove-do-window-select' is the main | |
280 ;; driver function: it actually does the `select-window'. It is | |
281 ;; called by four little convenience wrappers, `windmove-left', | |
282 ;; `windmove-up', `windmove-right', and `windmove-down', which make | |
283 ;; for convenient keybinding. | |
284 | |
285 | |
286 ;; Quick & dirty utility function to add two (x . y) coords. | |
287 (defun windmove-coord-add (coord1 coord2) | |
288 "Add the two coordinates. | |
289 Both COORD1 and COORD2 are coordinate cons pairs, (HPOS . VPOS). The | |
290 result is another coordinate cons pair." | |
291 (cons (+ (car coord1) (car coord2)) | |
292 (+ (cdr coord1) (cdr coord2)))) | |
293 | |
294 | |
295 (defun windmove-constrain-to-range (n min-n max-n) | |
296 "Ensure that N is between MIN-N and MAX-N inclusive by constraining. | |
297 If N is less than MIN-N, return MIN-N; if greater than MAX-N, return | |
298 MAX-N." | |
299 (max min-n (min n max-n))) | |
300 | |
301 (defun windmove-constrain-around-range (n min-n max-n) | |
302 "Ensure that N is between MIN-N and MAX-N inclusive by wrapping. | |
303 If N is less than MIN-N, return MAX-N; if greater than MAX-N, return | |
304 MIN-N." | |
305 (cond | |
306 ((< n min-n) max-n) | |
307 ((> n max-n) min-n) | |
308 (t n))) | |
309 | |
310 (defun windmove-frame-edges (window) | |
311 "Return (X-MIN Y-MIN X-MAX Y-MAX) for the frame containing WINDOW. | |
312 If WINDOW is nil, return the edges for the selected frame. | |
39588 | 313 \(X-MIN, Y-MIN) is the zero-based coordinate of the top-left corner |
27545 | 314 of the frame; (X-MAX, Y-MAX) is the zero-based coordinate of the |
315 bottom-right corner of the frame. | |
316 For example, if a frame has 76 rows and 181 columns, the return value | |
317 from `windmove-frame-edges' will be the list (0 0 180 75)." | |
318 (let ((frame (if window | |
319 (window-frame window) | |
320 (selected-frame)))) | |
321 (let ((x-min 0) | |
322 (y-min 0) | |
323 (x-max (1- (frame-width frame))) ; 1- for last row & col here | |
324 (y-max (1- (frame-height frame)))) | |
325 (list x-min y-min x-max y-max)))) | |
326 | |
327 ;; it turns out that constraining is always a good thing, even when | |
328 ;; wrapping is going to happen. this is because: | |
329 ;; first, since we disallow exotic diagonal-around-a-corner type | |
330 ;; movements, so we can always fix the unimportant direction (the one | |
331 ;; we're not moving in). | |
332 ;; second, if we're moving down and we're not in the minibuffer, then | |
333 ;; constraining the y coordinate to max-y is okay, because if that | |
334 ;; falls in the minibuffer and the minibuffer isn't active, that y | |
335 ;; coordinate will still be off the bottom of the frame as the | |
336 ;; wrapping function sees it and so will get wrapped around anyway. | |
337 (defun windmove-constrain-loc-for-movement (coord window dir) | |
338 "Constrain COORD so that it is reasonable for the given movement. | |
339 This involves two things: first, make sure that the \"off\" coordinate | |
340 -- the one not being moved on, e.g., y for horizontal movement -- is | |
341 within frame boundaries; second, if the movement is down and we're not | |
342 moving from the minibuffer, make sure that the y coordinate does not | |
343 exceed the frame max-y, so that we don't overshoot the minibuffer | |
344 accidentally. WINDOW is the window that movement is relative to; DIR | |
345 is the direction of the movement, one of `left', `up', `right', | |
346 or `down'. | |
347 Returns the constrained coordinate." | |
348 (let ((frame-edges (windmove-frame-edges window)) | |
349 (in-minibuffer (window-minibuffer-p window))) | |
350 (let ((min-x (nth 0 frame-edges)) | |
351 (min-y (nth 1 frame-edges)) | |
352 (max-x (nth 2 frame-edges)) | |
353 (max-y (nth 3 frame-edges))) | |
354 (let ((new-x | |
355 (if (memq dir '(up down)) ; vertical movement | |
356 (windmove-constrain-to-range (car coord) min-x max-x) | |
357 (car coord))) | |
358 (new-y | |
359 (if (or (memq dir '(left right)) ; horizontal movement | |
360 (and (eq dir 'down) | |
361 (not in-minibuffer))) ; don't miss minibuffer | |
362 ;; (technically, we shouldn't constrain on min-y in the | |
363 ;; second case, but this shouldn't do any harm on a | |
364 ;; down movement.) | |
365 (windmove-constrain-to-range (cdr coord) min-y max-y) | |
366 (cdr coord)))) | |
367 (cons new-x new-y))))) | |
368 | |
369 ;; having constrained in the limited sense of windmove-constrain-loc- | |
370 ;; for-movement, the wrapping code is actually much simpler than it | |
371 ;; otherwise would be. the only complication is that we need to check | |
372 ;; if the minibuffer is active, and, if not, pretend that it's not | |
373 ;; even part of the frame. | |
374 (defun windmove-wrap-loc-for-movement (coord window dir) | |
375 "Takes the constrained COORD and wraps it around for the movement. | |
376 This makes an out-of-range x or y coordinate and wraps it around the | |
377 frame, giving a coordinate (hopefully) in the window on the other edge | |
378 of the frame. WINDOW is the window that movement is relative to (nil | |
379 means the currently selected window); DIR is the direction of the | |
380 movement, one of `left', `up', `right',or `down'. | |
381 Returns the wrapped coordinate." | |
382 (let* ((frame-edges (windmove-frame-edges window)) | |
383 (frame-minibuffer (minibuffer-window (if window | |
384 (window-frame window) | |
385 (selected-frame)))) | |
386 (minibuffer-active (minibuffer-window-active-p | |
387 frame-minibuffer))) | |
388 (let ((min-x (nth 0 frame-edges)) | |
389 (min-y (nth 1 frame-edges)) | |
390 (max-x (nth 2 frame-edges)) | |
391 (max-y (if (not minibuffer-active) | |
392 (- (nth 3 frame-edges) | |
393 (window-height frame-minibuffer)) | |
394 (nth 3 frame-edges)))) | |
395 (cons | |
396 (windmove-constrain-around-range (car coord) min-x max-x) | |
397 (windmove-constrain-around-range (cdr coord) min-y max-y))))) | |
398 | |
399 | |
400 | |
401 ;; `windmove-coordinates-of-position' is stolen and modified from the | |
402 ;; Emacs Lisp Reference Manual, section 27.2.5. It seems to work | |
403 ;; okay, although I am bothered by the fact that tab-offset (the cdr | |
404 ;; of the next-to- last argument) is set to 0. On the other hand, I | |
405 ;; can't find a single usage of `compute-motion' anywhere that doesn't | |
406 ;; set this component to zero, and I'm too lazy to grovel through the | |
407 ;; C source to figure out what's happening in the background. there | |
408 ;; also seems to be a good deal of fun in calculating the correct | |
409 ;; width of lines for telling `compute-motion' about; in particular, | |
410 ;; it seems we need to subtract 1 (for the continuation column) from | |
411 ;; the number that `window-width' gives, or continuation lines aren't | |
412 ;; counted correctly. I haven't seen anyone doing this before, | |
413 ;; though. | |
414 (defun windmove-coordinates-of-position (pos &optional window) | |
415 "Return the coordinates of position POS in window WINDOW. | |
416 Return the window-based coodinates in a cons pair: (HPOS . VPOS), | |
417 where HPOS and VPOS are the zero-based x and y components of the | |
418 screen location of POS. If WINDOW is nil, return the coordinates in | |
419 the currently selected window. | |
420 As an example, if point is in the top left corner of a window, then | |
421 the return value from `windmove-coordinates-of-position' is (0 . 0) | |
422 regardless of the where point is in the buffer and where the window | |
423 is placed in the frame." | |
424 (let* ((wind (if (null window) (selected-window) window)) | |
425 (usable-width (1- (window-width wind))) ; 1- for cont. column | |
426 (usable-height (1- (window-height wind))) ; 1- for mode line | |
427 (big-hairy-result (compute-motion | |
428 (window-start) | |
429 '(0 . 0) | |
430 pos | |
431 (cons usable-width usable-height) | |
432 usable-width | |
433 (cons (window-hscroll) | |
434 0) ; why zero? | |
435 wind))) | |
436 (cons (nth 1 big-hairy-result) ; hpos, not vpos as documented | |
437 (nth 2 big-hairy-result)))) ; vpos, not hpos as documented | |
438 | |
439 ;; This calculates the reference location in the current window: the | |
440 ;; frame-based (x . y) of either point, the top-left, or the | |
441 ;; bottom-right of the window, depending on ARG. | |
442 (defun windmove-reference-loc (&optional arg window) | |
443 "Return the reference location for directional window selection. | |
444 Return a coordinate (HPOS . VPOS) that is frame-based. If ARG is nil | |
445 or not supplied, the reference point is the buffer's point in the | |
446 currently-selected window, or WINDOW if supplied; otherwise, it is the | |
447 top-left or bottom-right corner of the selected window, or WINDOW if | |
448 supplied, if ARG is greater or smaller than zero, respectively." | |
449 (let ((effective-arg (if (null arg) 0 (prefix-numeric-value arg))) | |
450 (edges (window-edges window))) | |
451 (let ((top-left (cons (nth 0 edges) | |
452 (nth 1 edges))) | |
453 ;; if 1-'s are not there, windows actually extend too far. | |
454 ;; actually, -2 is necessary for bottom: (nth 3 edges) is | |
455 ;; the height of the window; -1 because we want 0-based max, | |
456 ;; -1 to get rid of mode line | |
457 (bottom-right (cons (- (nth 2 edges) 1) | |
458 (- (nth 3 edges) 2)))) | |
459 (cond | |
460 ((> effective-arg 0) | |
461 top-left) | |
462 ((< effective-arg 0) | |
463 bottom-right) | |
464 ((= effective-arg 0) | |
465 (windmove-coord-add | |
466 top-left | |
467 (windmove-coordinates-of-position (window-point window) | |
468 window))))))) | |
469 | |
470 ;; This uses the reference location in the current window (calculated | |
471 ;; by `windmove-reference-loc' above) to find a reference location | |
472 ;; that will hopefully be in the window we want to move to. | |
473 (defun windmove-other-window-loc (dir &optional arg window) | |
474 "Return a location in the window to be moved to. | |
475 Return value is a frame-based (HPOS . VPOS) value that should be moved | |
476 to. DIR is one of `left', `up', `right', or `down'; an optional ARG | |
477 is handled as by `windmove-reference-loc'; WINDOW is the window that | |
478 movement is relative to." | |
479 (let ((edges (window-edges window)) ; edges: (x0, y0, x1, y1) | |
480 (refpoint (windmove-reference-loc arg window))) ; (x . y) | |
481 (cond | |
482 ((eq dir 'left) | |
483 (cons (- (nth 0 edges) | |
484 windmove-window-distance-delta) | |
485 (cdr refpoint))) ; (x0-d, y) | |
486 ((eq dir 'up) | |
487 (cons (car refpoint) | |
488 (- (nth 1 edges) | |
489 windmove-window-distance-delta))) ; (x, y0-d) | |
490 ((eq dir 'right) | |
491 (cons (+ (nth 2 edges) | |
492 windmove-window-distance-delta) | |
493 (cdr refpoint))) ; (x1+d, y) | |
494 ((eq dir 'down) | |
495 (cons (car refpoint) | |
496 (+ (nth 3 edges) | |
497 windmove-window-distance-delta))) ; (x, y1+d) | |
498 (t (error "Invalid direction of movement: %s" dir))))) | |
499 | |
500 (defun windmove-find-other-window (dir &optional arg window) | |
501 "Return the window object in direction DIR. | |
502 DIR, ARG, and WINDOW are handled as by `windmove-other-window-loc'." | |
503 (let* ((actual-current-window (or window (selected-window))) | |
504 (raw-other-window-loc | |
505 (windmove-other-window-loc dir arg actual-current-window)) | |
506 (constrained-other-window-loc | |
507 (windmove-constrain-loc-for-movement raw-other-window-loc | |
508 actual-current-window | |
509 dir)) | |
510 (other-window-loc | |
511 (if windmove-wrap-around | |
512 (windmove-wrap-loc-for-movement constrained-other-window-loc | |
513 actual-current-window | |
514 dir) | |
515 constrained-other-window-loc))) | |
516 (window-at (car other-window-loc) | |
517 (cdr other-window-loc)))) | |
518 | |
519 | |
520 ;; Selects the window that's hopefully at the location returned by | |
521 ;; `windmove-other-window-loc', or screams if there's no window there. | |
522 (defun windmove-do-window-select (dir &optional arg window) | |
30892
495502641770
(windmove) <defgroup>: Add :version.
Dave Love <fx@gnu.org>
parents:
27545
diff
changeset
|
523 "Move to the window at direction DIR. |
27545 | 524 DIR, ARG, and WINDOW are handled as by `windmove-other-window-loc'. |
525 If no window is at direction DIR, an error is signaled." | |
526 (let ((other-window (windmove-find-other-window dir arg window))) | |
527 (cond ((null other-window) | |
528 (error "No window at %s" dir)) | |
529 ((and (window-minibuffer-p other-window) | |
530 (not (minibuffer-window-active-p other-window))) | |
531 (error "Can't move to inactive minibuffer")) | |
532 (t | |
533 (select-window other-window))))) | |
534 | |
535 | |
536 ;;; end-user functions | |
537 ;; these are all simple interactive wrappers to `windmove-do- | |
538 ;; window-select', meant to be bound to keys. | |
539 | |
540 ;;;###autoload | |
541 (defun windmove-left (&optional arg) | |
542 "Select the window to the left of the current one. | |
543 With no prefix argument, or with prefix argument equal to zero, | |
544 \"left\" is relative to the position of point in the window; otherwise | |
545 it is relative to the top edge (for positive ARG) or the bottom edge | |
39588 | 546 \(for negative ARG) of the current window. |
27545 | 547 If no window is at the desired location, an error is signaled." |
548 (interactive "P") | |
549 (windmove-do-window-select 'left arg)) | |
550 | |
551 ;;;###autoload | |
552 (defun windmove-up (&optional arg) | |
553 "Select the window above the current one. | |
554 With no prefix argument, or with prefix argument equal to zero, \"up\" | |
555 is relative to the position of point in the window; otherwise it is | |
556 relative to the left edge (for positive ARG) or the right edge (for | |
557 negative ARG) of the current window. | |
558 If no window is at the desired location, an error is signaled." | |
559 (interactive "P") | |
560 (windmove-do-window-select 'up arg)) | |
561 | |
562 ;;;###autoload | |
563 (defun windmove-right (&optional arg) | |
564 "Select the window to the right of the current one. | |
565 With no prefix argument, or with prefix argument equal to zero, | |
566 \"right\" is relative to the position of point in the window; | |
567 otherwise it is relative to the top edge (for positive ARG) or the | |
568 bottom edge (for negative ARG) of the current window. | |
569 If no window is at the desired location, an error is signaled." | |
570 (interactive "P") | |
571 (windmove-do-window-select 'right arg)) | |
572 | |
573 ;;;###autoload | |
574 (defun windmove-down (&optional arg) | |
575 "Select the window below the current one. | |
576 With no prefix argument, or with prefix argument equal to zero, | |
577 \"down\" is relative to the position of point in the window; otherwise | |
578 it is relative to the left edge (for positive ARG) or the right edge | |
39588 | 579 \(for negative ARG) of the current window. |
27545 | 580 If no window is at the desired location, an error is signaled." |
581 (interactive "P") | |
582 (windmove-do-window-select 'down arg)) | |
583 | |
584 | |
585 ;;; set up keybindings | |
586 ;; Idea for this function is from iswitchb.el, by Stephen Eglen | |
587 ;; (stephen@cns.ed.ac.uk). | |
588 ;; I don't think these bindings will work on non-X terminals; you | |
589 ;; probably want to use different bindings in that case. | |
590 | |
591 ;;;###autoload | |
592 (defun windmove-default-keybindings () | |
593 "Set up default keybindings for `windmove'." | |
594 (interactive) | |
595 (global-set-key [(shift left)] 'windmove-left) | |
596 (global-set-key [(shift up)] 'windmove-up) | |
597 (global-set-key [(shift right)] 'windmove-right) | |
598 (global-set-key [(shift down)] 'windmove-down)) | |
599 | |
600 | |
601 (provide 'windmove) | |
602 | |
603 ;;; windmove.el ends here |