Re: Buffer listing in multiple frames/ttys

[lorentey@elte.hu (Károly Lőrentey)]

[-- Attachment #1.1: Type: text/plain, Size: 2031 bytes --]

Juri Linkov <juri@jurta.org> writes:
> Not at all.  The problem is that `bury-buffer' (called from
> `next-buffer') removes the buffer from the frame's buffer-list.  So
> a buried buffer is no longer available from (frame-parameter nil
> 'buffer-list) for `prev-buffer' called in the same frame after
> changing the order of buried buffers in another frame.

Right.  I would say changing `bury-buffer' would be an overshoot,
though.  Perhaps `next-buffer' shouldn't call it?

The following definitions change `prev-buffer' and `next-buffer' to
follow the frame-local buffer ordering instead of the global
`buffer-list'.

	(defun next-buffer ()
	  "Switch to the next buffer in cyclic order."
	  (interactive)
	  (let ((buffer (current-buffer)))
	    (switch-to-buffer (other-buffer buffer))
	    (set-frame-parameter nil 'buffer-list
				 (nconc (delq buffer (frame-parameter nil 'buffer-list))
					(list buffer)))))
	
	(defun prev-buffer ()
	  "Switch to the previous buffer in cyclic order."
	  (interactive)
	  (let ((list (nconc ;; Consider the locally used buffers first.
		       (reverse (frame-parameter nil 'buffer-list))
		       (nreverse (buffer-list))))
		found)
	    (while (and (not found) list)
	      (let ((buffer (car list)))
		(if (and (not (get-buffer-window buffer))
			 (not (string-match "\\` " (buffer-name buffer))))
		    (setq found buffer)))
	      (setq list (cdr list)))
	    (switch-to-buffer found)))

Now, I like these definitions as it makes more sense for me to keep
the buffer cycle frame-local, but they do have one disadvantage: the
`next-buffer'/`prev-buffer' cycle will not usually contain all
buffers---just those that were displayed in the current frame.  To
reach the rest, the user needs to use `switch-to-buffer', or
equivalent.

AFAICS there have not yet been any Emacs releases with
`next-buffer'/`prev-buffer', so if the frame-local behaviour is
preferable (I think it is), then it should be safe to change them now.

-- 
Károly

[-- Attachment #1.2: Type: application/pgp-signature, Size: 188 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel