emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Dan Davison <davison@stats.ox.ac.uk>
To: Eric S Fraga <e.fraga@ucl.ac.uk>
Cc: emacs org-mode mailing list <emacs-orgmode@gnu.org>
Subject: Re: Using Org for browsing and managing buffers
Date: Sun, 18 Apr 2010 23:47:11 -0400	[thread overview]
Message-ID: <87bpdghznk.fsf@stats.ox.ac.uk> (raw)
In-Reply-To: <87tyrcnc2c.wl%ucecesf@ucl.ac.uk> (Eric S. Fraga's message of "Thu, 15 Apr 2010 13:18:51 +0100")

[-- Attachment #1: Type: text/plain, Size: 4639 bytes --]

http://github.com/dandavison/org-buffers
http://github.com/dandavison/org-buffers/raw/master/org-buffers.el

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.

> - 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.

[-- Attachment #2.1: Type: text/plain, Size: 1499 bytes --]

|              | 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.

[-- Attachment #2.2: Type: text/html, Size: 2633 bytes --]

[-- Attachment #3: Type: text/plain, Size: 56 bytes --]


[6] Helpful if you switch branches in version control.

[-- Attachment #4: Type: text/plain, Size: 201 bytes --]

_______________________________________________
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

  reply	other threads:[~2010-04-19  3:47 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 [this message]
2010-04-19  8:27         ` Eric S Fraga
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=87bpdghznk.fsf@stats.ox.ac.uk \
    --to=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).