emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
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. :-)

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