From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric S Fraga Subject: Re: Using Org for browsing and managing buffers Date: Mon, 19 Apr 2010 09:27:12 +0100 Message-ID: <87hbn7etjz.wl%ucecesf@ucl.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> <87bpdghznk.fsf@stats.ox.ac.uk> Reply-To: e.fraga@ucl.ac.uk Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O3mv6-0002lC-Jc for emacs-orgmode@gnu.org; Mon, 19 Apr 2010 05:05:32 -0400 Received: from [140.186.70.92] (port=46514 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O3mv4-0002k6-OC for emacs-orgmode@gnu.org; Mon, 19 Apr 2010 05:05:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O3muy-0007ON-Hr for emacs-orgmode@gnu.org; Mon, 19 Apr 2010 05:05:28 -0400 Received: from vscane-b.ucl.ac.uk ([144.82.108.141]:49638) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O3muy-0007O5-8U for emacs-orgmode@gnu.org; Mon, 19 Apr 2010 05:05:24 -0400 In-Reply-To: <87bpdghznk.fsf@stats.ox.ac.uk> 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: Dan Davison Cc: emacs org-mode mailing list On Sun, 18 Apr 2010 23:47:11 -0400, Dan Davison wrote: > > 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. Very nice summary! Shows that there is significant inconsistency in behaviour across typical/popular emacs modes. Probably too late to increase that consistency overall but I like the choices you have made for org-buffers. > > - what's the point of orb-buffers-toggle-heading? > > Cleaner (less starry) appearance, seeing as many buffers are named > *Like This*. Ah, true! On this topic, one suggestion (which might be difficult to implement, however): the best thing is about org is the hierarchical nature of headlines. This would seem to map well to the hierarchical nature of modes. For instance, org mode is also a text mode. Would it make sense to have all text mode buffers grouped with sub-modes (for want of a better word) as subheadings? On the other hand, I'm not sure what this would add so probably ignore 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. Doesn't seem to work for me (pulled from git this morning, 8am BST): ,---- | Debugger entered--Lisp error: (wrong-type-argument integer-or-marker-p nil) | delete-region(nil nil) | (lambda (pair) (delete-region (car pair) (cdr pair)))(nil) | mapc((lambda (pair) (delete-region (car pair) (cdr pair))) (nil nil (4614 . 4748) nil (4407 . 4572) nil (4204 . 4360) nil (3953 . 4169) (3695 . 3911) (3441 . 3653) (3193 . 3403) (2947 . 3157) (2693 . 2911) (2441 . 2649) (2197 . 2405) (1953 . 2163) nil (1767 . 1911) nil (1561 . 1712) nil (1300 . 1524) (1131 . 1270) (942 . 1091) (734 . 884) (555 . 696) nil (260 . 499) nil (50 . 201) nil)) | org-buffers-delete-regions((nil nil (4614 . 4748) nil (4407 . 4572) nil (4204 . 4360) nil (3953 . 4169) (3695 . 3911) (3441 . 3653) (3193 . 3403) (2947 . 3157) (2693 . 2911) (2441 . 2649) (2197 . 2405) (1953 . 2163) nil (1767 . 1911) nil (1561 . 1712) nil (1300 . 1524) (1131 . 1270) (942 . 1091) (734 . 884) (555 . 696) nil (260 . 499) nil (50 . 201) nil)) | (save-excursion (goto-char (point-min)) (org-buffers-delete-regions (nreverse ...))) | (let ((inhibit-read-only t)) (save-excursion (goto-char ...) (org-buffers-delete-regions ...))) | org-buffers-delete-properties() | (progn (org-buffers-delete-properties) (show-all) (org-buffers-set-state (quote ...))) | (if (org-buffers-state-get :properties) (progn (org-buffers-delete-properties) (show-all) (org-buffers-set-state ...)) (org-buffers-set-state (quote ...)) (org-buffers-list (quote refresh))) | org-buffers-toggle-properties() | (if (and headings-p (org-buffers-state-get :properties)) (org-buffers-toggle-properties)) | (let ((inhibit-read-only t) (headings-p ...) (flat-p ...)) (if (and headings-p ...) (org-buffers-toggle-properties)) (save-excursion (goto-char ...) (if ... ...) (if flat-p ... ...) (mark-whole-buffer) (indent-region ... ...)) (org-buffers-set-state (\` ...))) | org-buffers-toggle-headings() | call-interactively(org-buffers-toggle-headings nil nil) `---- > > - 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. doesn't seem to happen to me now. I may have imagined it... > > - 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 Okay. I understand the motivation. It comes down to the difference in behaviour between the default buffers listing approach in emacs and the way dired works. As long as I remember that it's more like dired, I'm happy! > > - 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. Okay. > > 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. Okay, again like dired as opposed to list-buffers. Fine. > 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). This sounds very reasonable. > Also you can now flag buffers for reversion (i.e. revert-buffer) using > "r"[6], and a few other changes. I have auto-revert-mode set on most buffers so this is not of great use to me but I can see it being useful to others. > Thanks, your suggestions have been really helpful. You're very welcome! Suggestions are easy; implementation is the tricky bit. :-)