[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Orgmode] Using Org for browsing and managing buffers
Eric S Fraga
Re: [Orgmode] Using Org for browsing and managing buffers
Mon, 19 Apr 2010 09:27:12 +0100
Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (Gojō) APEL/10.7 Emacs/23.1 (i486-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO)
On Sun, 18 Apr 2010 23:47:11 -0400, Dan Davison <address@hidden> wrote:
> Hi Eric,
> Eric S Fraga <address@hidden> 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
> > - what's the point of orb-buffers-toggle-heading?
> Cleaner (less starry) appearance, seeing as many buffers are named
> *Like This*.
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
| (let ((inhibit-read-only t)) (save-excursion (goto-char ...)
| (progn (org-buffers-delete-properties) (show-all) (org-buffers-set-state
| (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)))
| (if (and headings-p (org-buffers-state-get :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 (\` ...)))
| 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,
> > - 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
> > 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
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
This sounds very reasonable.
> Also you can now flag buffers for reversion (i.e. revert-buffer) using
> "r", 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. :-)
Re: [Orgmode] Using Org for browsing and managing buffers, Livin Stephen Sharma, 2010/04/15