From: Eric S Fraga <ucecesf@ucl.ac.uk>
To: Dan Davison <davison@stats.ox.ac.uk>
Cc: emacs org-mode mailing list <emacs-orgmode@gnu.org>
Subject: Re: Using Org for browsing and managing buffers
Date: Mon, 19 Apr 2010 09:27:12 +0100 [thread overview]
Message-ID: <87hbn7etjz.wl%ucecesf@ucl.ac.uk> (raw)
In-Reply-To: <87bpdghznk.fsf@stats.ox.ac.uk>
On Sun, 18 Apr 2010 23:47:11 -0400, Dan Davison <davison@stats.ox.ac.uk> wrote:
>
> Hi Eric,
>
> Eric S Fraga <ucecesf@ucl.ac.uk> 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. :-)
next prev parent reply other threads:[~2010-04-19 9:05 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-09 1:17 Using Org for browsing and managing buffers Dan Davison
2010-04-09 3:43 ` Austin Frank
2010-04-09 14:49 ` Dan Davison
2010-04-14 20:23 ` Eric S Fraga
2010-04-15 4:20 ` Dan Davison
2010-04-15 12:18 ` Eric S Fraga
2010-04-19 3:47 ` Dan Davison
2010-04-19 8:27 ` Eric S Fraga [this message]
2010-04-19 13:18 ` Dan Davison
2010-04-15 10:11 ` Livin Stephen Sharma
2010-04-15 21:21 ` Dan Davison
2010-04-16 7:11 ` Livin Stephen Sharma
2010-04-16 14:22 ` Dan Davison
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87hbn7etjz.wl%ucecesf@ucl.ac.uk \
--to=ucecesf@ucl.ac.uk \
--cc=davison@stats.ox.ac.uk \
--cc=e.fraga@ucl.ac.uk \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).