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: Tue, 06 Dec 2005 13:44:53 +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="===============0123110844==" X-Trace: sea.gmane.org 1133880340 32544 80.91.229.2 (6 Dec 2005 14:45:40 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 6 Dec 2005 14:45:40 +0000 (UTC) Cc: juri@jurta.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 06 15:45:31 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1Eje2v-00013D-Ur for ged-emacs-devel@m.gmane.org; Tue, 06 Dec 2005 15:43:58 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Eje37-0005CS-06 for ged-emacs-devel@m.gmane.org; Tue, 06 Dec 2005 09:44:09 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EjcBE-0000jS-AN for emacs-devel@gnu.org; Tue, 06 Dec 2005 07:44:24 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EjcBC-0000iU-99 for emacs-devel@gnu.org; Tue, 06 Dec 2005 07:44:23 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EjcBA-0000iK-O2 for emacs-devel@gnu.org; Tue, 06 Dec 2005 07:44:20 -0500 Original-Received: from [212.92.23.158] (helo=ninsei.hu) by monty-python.gnu.org with esmtp (Exim 4.34) id 1EjcBo-0004eO-G2; Tue, 06 Dec 2005 07:45:01 -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 910FE1AC8A; Tue, 6 Dec 2005 13:44:04 +0100 (CET) Original-Received: by walrus (Postfix, from userid 1000) id C1EAC75F2; Tue, 6 Dec 2005 13:44:53 +0100 (CET) Original-To: rms@gnu.org In-Reply-To: (Richard M. Stallman's message of "Mon, 05 Dec 2005 20:43:29 -0500") 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:47044 Archived-At: --===============0123110844== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Richard Stallman writes: > bury-buffer is the only way to put a buffer at the end of the buffer > list. next-buffer must call bury-buffer in order to do that. OK. I note that `bury-buffer' removes the buffer from the frame-local buffer lists of all frames, not just the selected one. This is an unwanted side-effect in this case, as we want the effects of `next-buffer' to remain frame-local. I propose to add an optional parameter to `bury-buffer' to support this. > 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. > > As far as I can see, buffers that have never been displayed in this > frame WILL be included. other-buffer will find them, and prev-buffer > will find them via the call to buffer-list. In my quoted message, the definition of next buffer appends the old buffer to the end of the frame-local buffer list. Therefore, the frame-local list will be recycled continously, and subsequent `next-buffer' calls are prevented from reaching any buffers in the global buffer list. I appended to the end of this message enhanced versions of `next-buffer' and `prev-buffer' that eliminate this problem by maintaining a new auxiliary frame-local buffer list, called `previous-buffer-list'. `next-buffer' prepends the old buffer to this list, and `prev-buffer' searches this list first; otherwise the two functions behave as in CVS. > However, I see that these functions do not find buffers that are > currently displayed in some window. I think that these commands > should disregard whether the buffer is visible elsewhere. That means > passing t for the 2nd arg to other-buffer, and removing some code in > prev-buffer. I applied that change to these new versions. I also agree with Juri's suggestion to rename `prev-buffer' to `previous-buffer', for consistency with the rest of Emacs. (defun next-buffer () "Switch to the next buffer in cyclic order." (interactive) (let ((buffer (current-buffer)) (pbl (frame-parameter nil 'previous-buffer-list))) (switch-to-buffer (other-buffer buffer t)) (bury-buffer buffer) (set-frame-parameter nil 'previous-buffer-list (cons buffer (delq buffer pbl))))) (defun prev-buffer () "Switch to the previous buffer in cyclic order." (interactive) (let ((search-list #'(lambda (list) "Search LIST for a valid buffer to display." (let (found buffer) (while (and (not found) (list)) (setq buffer (car list)) (if (and (buffer-live-p buffer) (not (string-match "\\` " (buffer-name buffer)))) (setq found buffer) (setq list (cdr list)))) list)))) (let ((prev (funcall search-list (frame-parameter nil 'previous-buffer-= list)))) (set-frame-parameter nil 'previous-buffer-list (cdr prev)) (switch-to-buffer (or (car prev) (car (funcall search-list (nreverse (buffer-list))))))))) =2D-=20 K=C3=A1roly --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQBDlYfF6eoyqA+yej8RAlRwAJ0TwunDIdF2OuW+NGhCoCmPojAJzACgiOBN T+noLVX+dyRGuzqcYrXp7wM= =Ubgr -----END PGP SIGNATURE----- --=-=-=-- --===============0123110844== 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 --===============0123110844==--