From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: buffer order [was: isearch multiple buffers] Date: Wed, 24 Oct 2007 09:31:54 -0700 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1193243547 15043 80.91.229.12 (24 Oct 2007 16:32:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 24 Oct 2007 16:32:27 +0000 (UTC) Cc: emacs-devel@gnu.org To: "Juri Linkov" , Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Oct 24 18:32:19 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1Ikj9W-0006l0-3h for ged-emacs-devel@m.gmane.org; Wed, 24 Oct 2007 18:32:18 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ikj9N-00056i-Ms for ged-emacs-devel@m.gmane.org; Wed, 24 Oct 2007 12:32:09 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ikj9K-00055T-Kj for emacs-devel@gnu.org; Wed, 24 Oct 2007 12:32:06 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ikj9I-00052f-QN for emacs-devel@gnu.org; Wed, 24 Oct 2007 12:32:05 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ikj9I-00052Q-HE for emacs-devel@gnu.org; Wed, 24 Oct 2007 12:32:04 -0400 Original-Received: from rgminet01.oracle.com ([148.87.113.118]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Ikj9D-00039M-Jp; Wed, 24 Oct 2007 12:31:59 -0400 Original-Received: from agmgw1.us.oracle.com (agmgw1.us.oracle.com [152.68.180.212]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id l9OGVtux001894; Wed, 24 Oct 2007 10:31:56 -0600 Original-Received: from acsmt351.oracle.com (acsmt351.oracle.com [141.146.40.151]) by agmgw1.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id l9OEfXJU007791; Wed, 24 Oct 2007 10:31:55 -0600 Original-Received: from dhcp-4op11-4op12-west-130-35-178-158.us.oracle.com by acsmt350.oracle.com with ESMTP id 3316800901193243514; Wed, 24 Oct 2007 09:31:54 -0700 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-detected-kernel: by monty-python.gnu.org: Linux 2.4-2.6 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:81654 Archived-At: > From: Drew Adams Sent: Tuesday, October 23, 2007 5:33 PM > > how about at least letting a user search, say, all of the > buffers marked (with `>') in the Buffer List (C-x C-b), > in the order they currently appear in that list? That is, have > the default value of `isearch-buffers-next-buffer-function' > be a function that provides this behavior. ... > Buffer List already offers one way to select buffers and order > them. And if this were available, it might also serve as an > incentive to have one or more buffer-menu commands that mark > buffers according to a regexp - similar to > what `dired-mark-files-regexp' does. Some follow-up on this idea. I don't have time to work on this, but in case someone else is interested - You can now sort the Buffer List by any column, but you cannot define a custom buffer order (there is currently no use for that). If you could, then any function that operated on multiple buffers or upon the "next" or "previous" buffer could take advantage of that order. Isearch is one example. For instance, if there were marked buffers in Buffer List, then `next-buffer' would use the buffer order there, instead of the internal buffer order: `next-buffer' would mean the next marked buffer after the current buffer (which might or might not be marked). If no buffers were marked, the behavior would be as it is now. For this feature, users would need a way to define a custom order among the marked buffers. There are various UI possibilities for this (drag-and-drop etc.). Here's one that's simple for the user. 1. Add a buffer-number (e.g. line number) column at the left (it could even be part of the poorly named "CRM" column): Buffer Size Mode File 1. * *Messages* 232 Fundamental 2 % foobar 45391 Dired by name /toto/foobar 3> tata.el 31416 Emacs Lisp /toto/foobar/tata.el 4 *scratch* 320 Lisp Interaction 5 % *Help* 10021 Help 6> titi.el 8754 Emacs Lisp /toto/foobar/titi.el 2. Change the current bindings of keys `1' and `2' to something else, so numbers can be used instead for reordering. 3.a. Bind keys so that typing a number followed by RET would set the number of the buffer with the cursor to that input number. For example, typing `5 RET' would move the buffer with the cursor to line 5. 3.b. An alternative UI would be to let you edit the current buffer number (e.g. change 5 to 2) for any number of lines, and then hit `g' to reorder them all. That's the approach, for instance, of NetFlix when you reorder your film queue. That can make it easier to move a group of buffers together (less disorienting due to redisplay). 4. The order of the marked buffers in Buffer List would act as the current buffer order; unmarked buffers would be ignored for operations that use buffer order. In the example above, buffers tata.el and titi.el are marked, so `next-buffer' and isearch would act on them in the order they appear (tata.el, then titi.el). I find such a UI easier than, say, dragging lines, especially when there are lots of lines. It would also be good to add some of the regexp and marking/unmarking features that Dired has to Buffer List, the equivalent of `dired-toggle-marks' and `dired-mark-files-regexp', for instance. It would also be good to have commands to mark all buffers of a certain type (e.g. by mode, time, size, file buffers). You could then, for instance, mark all Emacs-Lisp buffers, then unmark a few of them that you don't want to search, and so on. WDOT?