From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dan Davison Subject: Re: Using Org for browsing and managing buffers Date: Sun, 18 Apr 2010 23:47:11 -0400 Message-ID: <87bpdghznk.fsf@stats.ox.ac.uk> References: <87aatda0gv.fsf@stats.ox.ac.uk> <87d3y1pyuz.wl%ucecesf@ucl.ac.uk> <87mxx5cpo0.fsf@stats.ox.ac.uk> <87tyrcnc2c.wl%ucecesf@ucl.ac.uk> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O3hxC-0003eG-PR for emacs-orgmode@gnu.org; Sun, 18 Apr 2010 23:47:22 -0400 Received: from [140.186.70.92] (port=46233 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O3hxA-0003e7-4N for emacs-orgmode@gnu.org; Sun, 18 Apr 2010 23:47:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O3hx7-0001g8-0T for emacs-orgmode@gnu.org; Sun, 18 Apr 2010 23:47:19 -0400 Received: from markov.stats.ox.ac.uk ([163.1.210.1]:34634) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O3hx6-0001fU-OZ for emacs-orgmode@gnu.org; Sun, 18 Apr 2010 23:47:16 -0400 In-Reply-To: <87tyrcnc2c.wl%ucecesf@ucl.ac.uk> (Eric S. Fraga's message of "Thu, 15 Apr 2010 13:18:51 +0100") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Eric S Fraga Cc: emacs org-mode mailing list --=-=-= http://github.com/dandavison/org-buffers http://github.com/dandavison/org-buffers/raw/master/org-buffers.el Hi Eric, Eric S Fraga writes: [...] > - I like the fact I can customise RET or, more to the point, that it > be consistent with the rest of org-mode. I personally would set > org-buffers-follow-link-method to 'current-window but then it would > be nice to have SPC, say, open the buffer in another window, to > behave consistently with org-agenda? I've added the SPACE binding you suggest. And, although it would be out-of-keeping with other org-mode links, it looks like there's a good argument for making RET switch to the buffer in the same window, like dired et al. I've done that. I've put a table at the end comparing these bindings across a few different major modes. > - I would prefer some consistency or symmetry in the creation and > burying of the buffer: given that (by default) org-buffers-list > brings up a new window in the current frame, quitting that buffer > should also delete the window; otherwise, I would like it to not > split the frame. Does that make sense? Yes. This is all to do with pop-to-buffer versus switch-to-buffer, my understanding of which was shaky. I have now changed to using switch-to-buffer by default, and I think this gives behaviour consistent with what you requested. I've also introduced a variable org-buffers-switch-to-buffer-function which can be set to 'pop-to-buffer, in which case the variables pop-up-windows and pop-up-frames, amongst others, become relevant. > - what's the point of orb-buffers-toggle-heading? Cleaner (less starry) appearance, seeing as many buffers are named *Like This*. > I ask because I > don't understand what functionality it adds and the default binding > (h) conflicts with my speed keys (I use vi-like bindings for speed > motion keys). I overlooked that before. I've moved it to H. > - In column view mode (which I also have not figured out why it would > be used...), the heading uses a different font size than the normal > entries so the headings don't line up at all. This may be my fault, > however. I don't see this. I've changed the column view binding to T ("tabular") so that the standard speed commands c and C are available. As for the point, it kind of comes full circle to the list-buffers / ibuffers appearance, thus showing that most things are a subset of org. > - if I bring up the buffers list a second time, having created a new > buffer in the meantime, the new buffer does not appear until I hit > 'g'. I think any invocation of org-buffers-list should do an > automatic update of the list. A C-u prefix to org-buffers-list now forces update. I don't think I agree that it should be default. Speed is my concern -- I'd like it to show the listing immediately when possible. I believe we're both using "atom"-powered netbooks, and mine at least is a little sluggish at generating the listing. I notice dired says "The directory has changed on disk, use g to update" so maybe I could do the same. > > - Lastly, it would be nice to either avoid the single blank line at > the start of the buffer or have point be at the first heading. > Having point at the first (empty) line seems to cause some problems > with speed motion keys sometimes... it also wastes a line! I've made point go to the first heading when the listing is created. However, I am wary about getting rid of that initial line, as I believe Carsten has said that Org/outline.el isn't always happy with first heading on first line. Certainly, I'm not inserting that newline character explicitly -- it appears via my (ab)use of Carsten's functions. > Actually, I think it might be useful to have point be placed at the > heading that corresponds to the buffer currently being visited when > the org-buffers-list command is invoked. A thought. Yes I like that and I've done it. It will only happen with a fresh listing though (first time, or C-u prefix), Otherwise buffer point is maintained. Along similar lines, I've made it so that if you invoke C-x f (find-file) or C-x d (dired), the minibuffer prompt will start from the directory of the buffer on the current line, rather than whatever directory is associated with the listings buffer. I've found this useful (only works for the keybindings currently, not for M-x or from menu). Also you can now flag buffers for reversion (i.e. revert-buffer) using "r"[6], and a few other changes. Thanks, your suggestions have been really helpful. Dan This table is with (setq pop-up-windows t), which is default in emacs23. --=-=-= Content-Type: multipart/alternative; boundary="==-=-=" --==-=-= | | switch | switch | display other-window | | | | same window | other window | without switch | next item | | | | (pop-to-buffer) | | | |--------------+--------------+-----------------+----------------------+-----------| | dired | RET | o | unavailable? | SPACE | | org links | unavailable? | RET | unavailable? [3] | | | org agenda | RET | TAB | SPACE [1] | | | magit log | unavailable? | RET | SPACE | | | gnus summary | unavailable? | unavailable? | RET, SPACE [2] | | | ibuffer | RET | o | C-o | SPACE | | list-buffers | RET | o | C-o | SPACE | |--------------+--------------+-----------------+----------------------+-----------| | org-buffers | RET | [5] | SPACE[4] | | [1] scrolls but does not advance to next automatically [2] scrolls and space advances to next entry on reaching end; RET doesn't advance [3] for org-mode links, SPACE could be bound to display-in-other-window-without-switching-and-scroll (?) [4] scrolls and advances [5] Customize variable org-buffers-switch-to-buffer-function, or bind function org-buffers-switch-to-buffer-other-window. --==-=-= Content-Type: text/html
switchswitchdisplay other-window
same windowother windowwithout switchnext item
(pop-to-buffer)
diredRETounavailable?SPACE
org linksunavailable?RETunavailable? 1
org agendaRETTABSPACE 2
magit logunavailable?RETSPACE
gnus summaryunavailable?unavailable?RET, SPACE 3
ibufferREToC-oSPACE
list-buffersREToC-oSPACE
org-buffersRET4SPACE5

Footnotes:

1 for org-mode links, SPACE could be bound to
display-in-other-window-without-switching-and-scroll (?)

2 scrolls but does not advance to next automatically

3 scrolls and space advances to next entry on reaching end; RET doesn't advance

4 Customize variable org-buffers-switch-to-buffer-function, or bind
function org-buffers-switch-to-buffer-other-window.

5 scrolls and advances

--==-=-=-- --=-=-= [6] Helpful if you switch branches in version control. --=-=-= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode --=-=-=--