From: Drew Adams <drew.adams@oracle.com>
To: Joost Kremers <joost.m.kremers@gmail.com>, help-gnu-emacs@gnu.org
Subject: RE: Looking for a buffer-cycling library
Date: Sun, 16 Nov 2014 09:08:10 -0800 (PST) [thread overview]
Message-ID: <828513f5-92dc-49f2-91e6-4711146f4356@default> (raw)
In-Reply-To: <<slrnm6guar.a37.joost.m.kremers@j.kremers4.news.arnhem.chello.nl>>
> >>> I'm looking for a buffer cycling mechanism that will ignore
> >>> any buffer not loaded from or written to a file.
> >>>
> >>> Example - any buffer whose name begins with '*' would be
> >>> "jumped over"
> >
> > Just my 2 cents: why not use Icicles?
>
> Because, AFAIU, with Icicles you still need to type `C-x b` to
> switch buffers.
Correct. Or whatever key you bind to `icicle-buffer'.
> swbuff displays a list of buffers and allows you to cycle
> through them.
Yep. I used `swbuff.el' for a while, long, long ago.
(http://www.emacswiki.org/SwBuff)
If there is no control over what the "list of buffers" is, or if it
is long, then cycling is less interesting (IMO). The OP asked for
file buffers only. And yes, `swbuff.el' does provide an option,
`swbuff-exclude-buffer-regexps' that filters the list. Still, the
list can be long, and that filtering is a customization, not
on-the-fly.
FWIW, for cycling when there are few buffers and I don't need
to match names etc., I use `next-buffer-repeat' and
`previous-buffer-repeat', which are just repeatable versions of
the standard `next-buffer' and `previous-buffer' (repeatable in
the sense of being able to repeat the last key hit on a prefix
key: `C-x C-right C-right C-right' or `C-x right right right'.
(Those commands are here:
http://www.emacswiki.org/emacs-en/download/misc-cmds.el)
I filed an Emacs enhancement request to add a user option that
excludes or includes, from `(next|previous)-buffer' cycling,
any buffers whose names match a user-defined regexp. IOW, to
provide an equivalent to `swbuff-exclude-buffer-regexps' for
vanilla Emacs. (That would automatically apply also to
`next-buffer-repeat' and `previous-buffer-repeat'.)
That enhancement request is here:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=19070)
> I've bound the relevant cycling commands to `C-TAB` and
> `S-C-TAB`, so I can just press the control key and hit TAB
> a number of times to get to the buffer I want.
See above.
> I usually don't have too many open files,
I often have lots of buffers, including lots of open files.
> so most of the time I only need to hit TAB a few times. Buffer
> switching is much faster that way than by pressing `C-x b` and
> typing part of the buffer name.
Agreed. If you don't have a lot to cycle through, cycling
can be faster than narrowing by name-matching.
An advantage of Icicles (and similar approaches) in this regard
is that you can either cycle or name-match - or both. Typically,
typing just a few chars narrows the candidate set to a few that
you can then cycle among.
FWIW: I started down the road to cycling things with Do Re Mi.
You can use it to cycle among various things or increment various
things (hence the name). But in the cycling cases I have, Icicles
generally gives better behavior, because it lets you combine
cycling with matching (completion).
One of the things I admonish new Icicles users about is this
(in the section about cycling):
Do not become a cycling drone!
Input some text to narrow the set of candidates, before cycling
among them to choose one. This is a good habit to adopt,
generally, in Icicles. Most of the power of Icicles comes in
your ability to filter a set of candidates. This is especially
true when it comes to regexp filtering (see "Apropos Completions").
Cycling and filtering work hand in hand. If the set of
candidates is small to begin with, then just cycling might be
quick enough - that is the case if you move among a small set
of buffers, for instance. But with Icicles you can profitably
use cycling on even a very large set of candidates - by filtering
the set first.
(http://www.emacswiki.org/Icicles_-_Cycling_Completions)
> I've recently bound `ido-switch-buffer` to `s-g`, making it a bit
> quicker than `C-x b`, but I notice I still prefer to use C-TAB.
next prev parent reply other threads:[~2014-11-16 17:08 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.13706.1416006724.1147.help-gnu-emacs@gnu.org>
2014-11-15 11:31 ` Looking for a buffer-cycling library Joost Kremers
2014-11-15 14:59 ` Marcin Borkowski
2014-11-15 17:17 ` Drew Adams
2014-11-15 21:04 ` Marcin Borkowski
2014-11-15 23:41 ` Drew Adams
[not found] ` <mailman.13736.1416063601.1147.help-gnu-emacs@gnu.org>
2014-11-16 10:15 ` Joost Kremers
[not found] ` <<slrnm6guar.a37.joost.m.kremers@j.kremers4.news.arnhem.chello.nl>
2014-11-16 17:08 ` Drew Adams [this message]
2014-11-16 18:01 ` Marcin Borkowski
2014-11-16 20:18 ` Drew Adams
2014-11-14 23:11 Tim Johnson
2014-11-15 1:34 ` Alexis
2014-11-15 3:32 ` Tim Johnson
2014-11-15 3:56 ` Alexis
2014-11-15 16:44 ` Tim Johnson
2014-11-15 17:19 ` Drew Adams
2014-11-15 20:32 ` Tim Johnson
2014-11-15 20:38 ` Drew Adams
2014-11-15 22:29 ` Tim Johnson
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.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=828513f5-92dc-49f2-91e6-4711146f4356@default \
--to=drew.adams@oracle.com \
--cc=help-gnu-emacs@gnu.org \
--cc=joost.m.kremers@gmail.com \
/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.
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).