From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: lorentey@elte.hu (=?utf-8?Q?K=C3=A1roly_L=C5=91rentey?=) Newsgroups: gmane.emacs.devel Subject: Re: Buffer listing in multiple frames/ttys Date: Mon, 05 Dec 2005 15:44:27 +0100 Message-ID: References: <87wtinrypp.fsf@jurta.org> <87u0dqm5ta.fsf@jurta.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0013733289==" X-Trace: sea.gmane.org 1133799125 15890 80.91.229.2 (5 Dec 2005 16:12:05 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 5 Dec 2005 16:12:05 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Dec 05 17:11:55 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EjItl-0006vZ-JZ for ged-emacs-devel@m.gmane.org; Mon, 05 Dec 2005 17:09:06 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EjItu-0003xP-1L for ged-emacs-devel@m.gmane.org; Mon, 05 Dec 2005 11:09:14 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EjHZZ-0007hZ-9S for emacs-devel@gnu.org; Mon, 05 Dec 2005 09:44:09 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EjHZV-0007gD-Nd for emacs-devel@gnu.org; Mon, 05 Dec 2005 09:44:08 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EjHZU-0007fm-UY for emacs-devel@gnu.org; Mon, 05 Dec 2005 09:44:05 -0500 Original-Received: from [212.92.23.158] (helo=ninsei.hu) by monty-python.gnu.org with esmtp (Exim 4.34) id 1EjHZz-0007LK-1Q for emacs-devel@gnu.org; Mon, 05 Dec 2005 09:44:36 -0500 Original-Received: from walrus (walrus.inf.elte.hu [157.181.166.149]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by chatsubo.ninsei.hu (Postfix) with ESMTP id C01BC1AC53; Mon, 5 Dec 2005 15:43:43 +0100 (CET) Original-Received: by walrus (Postfix, from userid 1000) id 988CB22B84; Mon, 5 Dec 2005 15:44:27 +0100 (CET) Original-To: Juri Linkov User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.52 (gnu/linux) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:47000 Archived-At: --===============0013733289== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Juri Linkov 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))))) =09 (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. =2D-=20 K=C3=A1roly --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQBDlFJL6eoyqA+yej8RAoDQAKCgoIStDYs/X+51jVabZcCw30dK8QCffJxQ U4mg45AVWuuM062lB7roJrI= =nbwT -----END PGP SIGNATURE----- --=-=-=-- --===============0013733289== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel --===============0013733289==--