help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Looking for a buffer-cycling library


From: Drew Adams
Subject: RE: Looking for a buffer-cycling library
Date: Sun, 16 Nov 2014 09:08:10 -0800 (PST)

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]