* Re: Looking for a buffer-cycling library [not found] <mailman.13706.1416006724.1147.help-gnu-emacs@gnu.org> @ 2014-11-15 11:31 ` Joost Kremers 2014-11-15 14:59 ` Marcin Borkowski [not found] ` <mailman.13736.1416063601.1147.help-gnu-emacs@gnu.org> 0 siblings, 2 replies; 18+ messages in thread From: Joost Kremers @ 2014-11-15 11:31 UTC (permalink / raw) To: help-gnu-emacs Tim Johnson wrote: > 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" I use (a slightly modified version of) swbuff.el for this. It allows you to specify regexes for buffer names that should be excluded. Going through `M-x list-packages` I notice there's a similar package cycbuf, which looks interesting. You might want to check that out as well. -- Joost Kremers joostkremers@fastmail.fm Selbst in die Unterwelt dringt durch Spalten Licht EN:SiS(9) ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Looking for a buffer-cycling library 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 [not found] ` <mailman.13736.1416063601.1147.help-gnu-emacs@gnu.org> 1 sibling, 1 reply; 18+ messages in thread From: Marcin Borkowski @ 2014-11-15 14:59 UTC (permalink / raw) To: help-gnu-emacs On 2014-11-15, at 12:31, Joost Kremers wrote: > Tim Johnson wrote: >> 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? Hth, -- Marcin Borkowski http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski Faculty of Mathematics and Computer Science Adam Mickiewicz University ^ permalink raw reply [flat|nested] 18+ messages in thread
* RE: Looking for a buffer-cycling library 2014-11-15 14:59 ` Marcin Borkowski @ 2014-11-15 17:17 ` Drew Adams 2014-11-15 21:04 ` Marcin Borkowski 0 siblings, 1 reply; 18+ messages in thread From: Drew Adams @ 2014-11-15 17:17 UTC (permalink / raw) To: Marcin Borkowski, help-gnu-emacs > >> 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? Icicles does let you "ignore any buffer not loaded from or written to a file". To do that, just use a positive prefix arg with `icicle-buffer': `M-1 C-x b'. That limits the candidates to names of buffers visiting files & directories. (Or define your own command that binds `current-prefix-arg' to a positive integer and invokes `icicle-buffer'.) You can also exclude or include particular buffer names using these user options (customize them or bind them in your own commands): `icicle-buffer-match-regexp' - Regexp buffer names must match `icicle-buffer-no-match-regexp' - Regexp names must not match `icicle-buffer-predicate' - Predicate names must satisfy `icicle-buffer-extras' - Extra buffer names to display For example, to change the default behavior to show only buffers associated with files (so no need to use a prefix arg, and exclude also directories), set `icicle-buffer-predicate' to this: (lambda (bf) (buffer-file-name bf)) However, the OP also wants to use terminal mode. Icicles can be used in terminal mode, but it no doubt calls for customizing some minibuffer key bindings, as some of the default bindings are for keys that terminals do not support. (I don't use terminal mode anymore, and I don't make much effort to support it for Icicles, but I do know that some people use Icicles with terminal mode.) --- Here is the (long) doc for command `icicle-buffer' (`C-x b' in Icicle mode, by default): ,---- | icicle-buffer is an interactive Lisp function in `icicles-cmd1.el'. | | It is bound to menu-bar buffer Icicles icicle-buffer, C-x b, menu-bar | buffer select-named-buffer. | | (icicle-buffer) | | Switch to a different buffer, whose content contains a regexp match. | By default, Icicle mode remaps all key sequences that are normally | bound to `switch-to-buffer' to `icicle-buffer'. If you do not want | this remapping, then customize option `icicle-top-level-key-bindings'. | | Completion candidates are two-part multi-completions, with the second | part optional. If both parts are present they are separated by | `icicle-list-join-string' ("^G^J", by default). | | The first part is matched as a regexp against a buffer name. | The second part is matched as a regexp against buffer content. | Candidates that do not match are filtered out. | | When matching buffer content, Icicles just looks for a single match. | Visiting the buffer does not move to that match or to any other match. | Matching is used only to filter candidate buffers. | | However, if your input includes a content-matching part and it | matches, that part is automatically added to the Isearch regexp | history, `regexp-search-ring' whenever you hit `S-TAB' to complete. | This means that when you visit the buffer you can immediately search | for matches using `C-M-s' or `C-M-r'. | | Your minibuffer input can match a buffer name or buffer content, or | both. Use `C-M-j' (equivalent here to `C-q C-g C-j') to input the | default separator. | | For example: | | To match `foo' against buffer names, use input `foo'. | To match `bar' against buffer contents, use input `C-M-j bar'. | To match both, use input `foo C-M-j bar'. | | Only the matching buffer names are shown in `*Completions*', and only | the chosen buffer name is returned. The actual content matches are | unimportant anyway: content matching is used only to filter | candidates. | | This is a buffer-switching command. If you instead want to navigate | to text searched for in buffers then use `icicle-search'. | | The buffer-name portion of completion candidates is as follows, | depending on the prefix arg: | | * No prefix arg: all buffers | * Numeric arg > 0: buffers visiting files or directories (Dired) | * Numeric arg < 0: buffers associated with the selected frame | * Numeric arg = 0: buffers with the same mode as the current buffer | * Plain prefix arg (`C-u'): buffers with the same mode as current, | or with a mode that the current mode is derived from | * Double plain (`C-u C-u'): visible buffers (possibly iconified) | * Triple plain (`C-u C-u C-u'): invisible buffers | | Those are the default prefix-argument behaviors, but you can change | them using option `icicle-buffer-prefix-arg-filtering'. | | For Emacs 23 and later, the default values (via `M-n') are the | (buffer-name components of the) first four completion candidates | (respecting the prefix argument). | | You can use these additional keys during completion: | | * `C-x F' Toggle including cached file names as candidates (option | `icicle-buffer-include-cached-files-nflag'). | * `C-x R' Toggle including recent file names as candidates (option | `icicle-buffer-include-recent-files-nflag'). | * `C-x m' Visit a bookmarked buffer (only if you use Bookmark+). | * `C-x M -' Remove buffers in a given mode. Repeatable. | * `C-x M +' Keep only buffers in a given mode. | * `C-x C-m -' Remove candidate buffers whose mode is derived from a | given mode. Repeatable. (`C-m' = `RET'.) | * `C-x C-m +' Keep only buffers in a mode derived from a given mode. | * `C-x v -' Remove buffers that are visible (maybe iconified). | * `C-x v +' Keep only buffers that are visible (maybe iconified). | * `<S-delete>' Kill the buffer named by a completion candidate. | | Those are default key bindings, but you can change them using option | `icicle-buffer-candidate-key-bindings'. | | These options, when non-nil, control candidate matching and filtering: | | `icicle-buffer-extras' - Extra buffer names to display | `icicle-buffer-ignore-space-prefix-flag' - Ignore space-prefix names | `icicle-buffer-include-cached-files-nflag' - Include cached files | `icicle-buffer-include-recent-files-nflag' - Include recent files | `icicle-buffer-match-regexp' - Regexp buffer names must match | `icicle-buffer-no-match-regexp' - Regexp names must not match | `icicle-buffer-predicate' - Predicate names must satisfy | `icicle-buffer-sort' - Sort function for candidates | `icicle-buffer-skip-functions' - Exclude from content searching | `icicle-file-skip-functions' - Same, but cached/recent files | | For example, to change the default behavior to show only buffers that | are associated with files, set `icicle-buffer-predicate' to this: | | (lambda (bufname) (buffer-file-name (get-buffer bufname))) | | Option `icicle-buffer-require-match-flag' can be used to override | option `icicle-require-match-flag'. | | Option `icicle-buffers-ido-like' non-nil gives this command a more | Ido-like behavior. | | See also command `icicle-buffer-no-search', which is `icicle-buffer' | without the multi-completion behavior that searches buffer content. | | See also command `icicle-buffer-config', which lets you choose a | configuration of user options for commands such as `icicle-buffer'. | | Note: The prefix arg is tested, even when this is called | noninteractively. Lisp code can bind `current-prefix-arg' to control | the behavior. | | Read input, then act on it. | | Input-candidate completion and cycling are available. While cycling, | these keys with prefix `C-' are active: | | `C-mouse-2', `C-return' - Act on current completion candidate only | `C-down', `C-wheel-down' - Move to next completion candidate and act | `C-up', `C-wheel-up' - Move to previous completion candidate and act | `C-next' - Move to next apropos-completion candidate and act | `C-prior' - Move to previous apropos-completion candidate and act | `C-end' - Move to next prefix-completion candidate and act | `C-home' - Move to previous prefix-completion candidate and act | `C-!' - Act on *all* candidates, successively (careful!) | | When candidate action and cycling are combined (e.g. `C-next'), user | option `icicle-act-before-cycle-flag' determines which occurs first. | | With prefix `C-M-' instead of `C-', the same keys (`C-M-mouse-2', | `C-M-RET', `C-M-down', and so on) provide help about candidates. | | Use `mouse-2', `RET', or `S-RET' to finally choose a candidate, or | `C-g' to quit. | | This is an Icicles command - see command `icicle-mode'. `---- ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Looking for a buffer-cycling library 2014-11-15 17:17 ` Drew Adams @ 2014-11-15 21:04 ` Marcin Borkowski 2014-11-15 23:41 ` Drew Adams 0 siblings, 1 reply; 18+ messages in thread From: Marcin Borkowski @ 2014-11-15 21:04 UTC (permalink / raw) To: help-gnu-emacs On 2014-11-15, at 18:17, Drew Adams wrote: >> >> 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? > > Icicles does let you "ignore any buffer not loaded from or > written to a file". > > To do that, just use a positive prefix arg with `icicle-buffer': > `M-1 C-x b'. That limits the candidates to names of buffers > visiting files & directories. Wow. Just wow. In fact, I was thinking about feeding Icicles a regex like ^[^*]. Now I can see there's no need to. I'll put "throwing Ido out and embracing Icicles" higher on my priority list. > Here is the (long) doc for command `icicle-buffer' (`C-x b' in > Icicle mode, by default): > [...] Incredible. Regards, -- Marcin Borkowski http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski Faculty of Mathematics and Computer Science Adam Mickiewicz University ^ permalink raw reply [flat|nested] 18+ messages in thread
* RE: Looking for a buffer-cycling library 2014-11-15 21:04 ` Marcin Borkowski @ 2014-11-15 23:41 ` Drew Adams 0 siblings, 0 replies; 18+ messages in thread From: Drew Adams @ 2014-11-15 23:41 UTC (permalink / raw) To: Marcin Borkowski, help-gnu-emacs TL;DRers: Skip it, unless you care. > >> >> 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? > > > > Icicles does let you "ignore any buffer not loaded from or > > written to a file". > > > > To do that, just use a positive prefix arg with `icicle-buffer': > > `M-1 C-x b'. That limits the candidates to names of buffers > > visiting files & directories. > > Wow. Just wow. > > In fact, I was thinking about feeding Icicles a regex like > ^[^*]. Now I can see there's no need to. > > I'll put "throwing Ido out and embracing Icicles" higher on my > priority list. > > > Here is the (long) doc for command `icicle-buffer' (`C-x b' in > > Icicle mode, by default): [...] > > Incredible. Well, the doc is not the product. ;-) The proof of the pudding is in the eating. So before we get carried away, let me just say this - Icicles is no panacea. I wouldn't be without it, personally, but there are those who like it and those who do not. Some things are still clunky in Icicles, and there are of course bugs. --- Maybe the most important thing to point out here is that you need not swallow it whole. Here are three ways to not have it take over your Emacs ;-): 1. Icicles will not bind top-level commands (for instance, it will not remap `C-x b' to `icicle-buffer' when in Icicle mode) if you customize option `icicle-top-level-key-bindings' to set it to `nil'. By default, in Icicle mode Icicles does remap lots of top-level vanilla commands to Icicles (multi-)commands. But you need not let it - it is trivial to say "Hands off my keys!". (It need not be an all-or-nothing choice, of course.) 2. It *is* possible to relegate Icicles completion to particular commands, or to exclude it from particular commands. That's not the Icicles way. ;-) But it is possible. More on this below. 3. There are a gazillion user options, to let you tune Icicles to get the behavior you want. In addition, because one completion behavior does *not* fit all contexts, you can easily change behavior on the fly. The latter feature is quite important, as what makes sense for discovery and exploring help is not necessarily the best behavior for locating a file containing something somewhere on your giant file system. You are in charge. You have a better idea than Emacs what your context is, what you can expect in terms of matching behavior, number of candidates, etc. Not DWIM but Do What You Want. Sometimes you want Icicles to take time to tell you stuff about a completion candidate, and sometimes you don't. Sometimes you want it to take time to automatically refresh the set of current candidates to match your updated input, and sometimes you prefer to tell it when to refresh (on demand). And so on. Tip: `M-?' during minibuffer input tells you what you can change on the fly, how, and what your current settings are. This is true for any minibuffer input, not just during completion. --- Before coming back to #2, which is about using Icicles only here and there, for particular commands, let me say that it is a * f e a t u r e * that Icicles completion is available everywhere. That's the idea behind the design. In Icicle mode, which is a global minor mode, Icicles *redefines* standard completion functions `completing-read', `read-file-name', `read-from-minibuffer',... You either appreciate this or you don't. ;-) In this respect, Icicles differs from other completion packages (Ido, Helm, ..., Foobar). By default, when you turn on Icicle mode you do bite off a big chunk of something different from vanilla Emacs. You can choose to forego mapping Icicles top-level commands to standard keys. But the standard completion functions used everywhere in Emacs commands are usurped by Icicles when you are in Icicle mode. What's the difference between co-opting keys for Icicles top-level commands (which is optional) and co-opting lower-level functions used by the top-level commands bound to those keys (which is not optional)? The difference is that even though the standard completion functions are co-opted, if you stick to the minibuffer keys that vanilla Emacs uses (`TAB', `RET', etc.) then there is little difference from vanilla Emacs behavior. Even in Icicle mode. IOW, if you choose to keep the standard binding of `C-x b' to `switch-to-buffer' then its completion behavior in Icicle mode is pretty much what you get with vanilla Emacs. It is when you use additional minibuffer keys (e.g., `S-TAB') that you get Icicles completion behavior. OK, there are a few exceptions to the vanilla-behavior claim: `SPC', `?', and `^J' (newline) self-insert during Icicles completion (why not?), and `down' and `up' arrows cycle completion candidates. But the most important vanilla keys are respected. (And all of the keys are customizable.) In sum, if you *want* Icicles completion everywhere then you're in luck, out of the box, as soon as you turn on `icicle-mode'. You don't need to write (or find) and bind new commands that call a special completion function such as `foobar-mode-completing-read'. Commands that use the standard completion functions give you Icicles completion for free. No configuration needed to get something like `foobar-mode-everywhere' or `foobar-mode-ubiquitous'. No need to say which kinds of objects you want foobar-mode completion for. --- But what if you don't want that? That's #2. As mentioned, you can turn off Icicle mode: `M-x icy-mode'. That's the answer? Yup. Toggle on/off. No big deal. And if you want to turn Icicle mode on or off for just certain commands or certain parts of your code then you can use these two macros: `icicle-with-icy-mode-OFF', `icicle-with-icy-mode-ON'. So if you want to leave Icicle mode OFF in general, but you want Icicles completion for your own command `my-choose-a-foo', then do something like this: (defun my-choose-a-foo (afoo) (interactive (list (icicle-with-icy-mode-ON (completing-read "Choose a foo: " all-foos)))) (message "Chosen foo: `%s'" afoo)) Similarly, if you want Icicle mode ON in general, but you want it OFF for some particular code, wrap that code with `icicle-with-icy-mode-OFF'. HTH. ^ permalink raw reply [flat|nested] 18+ messages in thread
[parent not found: <mailman.13736.1416063601.1147.help-gnu-emacs@gnu.org>]
* Re: Looking for a buffer-cycling library [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> 1 sibling, 0 replies; 18+ messages in thread From: Joost Kremers @ 2014-11-16 10:15 UTC (permalink / raw) To: help-gnu-emacs Marcin Borkowski wrote: > > On 2014-11-15, at 12:31, Joost Kremers wrote: > >> Tim Johnson wrote: >>> 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. swbuff displays a list of buffers and allows you to cycle through them. 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. I usually don't have too many 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. 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. -- Joost Kremers joostkremers@fastmail.fm Selbst in die Unterwelt dringt durch Spalten Licht EN:SiS(9) ^ permalink raw reply [flat|nested] 18+ messages in thread
[parent not found: <<slrnm6guar.a37.joost.m.kremers@j.kremers4.news.arnhem.chello.nl>]
* RE: Looking for a buffer-cycling library [not found] ` <<slrnm6guar.a37.joost.m.kremers@j.kremers4.news.arnhem.chello.nl> @ 2014-11-16 17:08 ` Drew Adams 2014-11-16 18:01 ` Marcin Borkowski 0 siblings, 1 reply; 18+ messages in thread From: Drew Adams @ 2014-11-16 17:08 UTC (permalink / raw) To: Joost Kremers, help-gnu-emacs > >>> 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Looking for a buffer-cycling library 2014-11-16 17:08 ` Drew Adams @ 2014-11-16 18:01 ` Marcin Borkowski 2014-11-16 20:18 ` Drew Adams 0 siblings, 1 reply; 18+ messages in thread From: Marcin Borkowski @ 2014-11-16 18:01 UTC (permalink / raw) To: help-gnu-emacs On 2014-11-16, at 18:08, Drew Adams wrote: >> >>> 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. Fair enough. You are aware that you can rebind command in Emacs, right? ;-) ;-) ;-) >> I usually don't have too many open files, > > I often have lots of buffers, including lots of open files. I second that. My workflow involves seldom quitting Emacs (my current emacs-uptime is almost 4 days, and it is so short only because my old netbook hang on Wednesday and I had to reboot - quite often it reaches a dozen days or so), and I almost never kill buffers - I usually just bury them (I even have a special keybinding for that, C-u C-z C-b - see http://mbork.pl/2014-04-04_Fast_buffer_switching_and_friends). So cycling alone is not an option for me. > 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. This is similar to Ido, which I'm (still) using. > 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! Good advice! > 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. In Ido, I often use C-SPC, which takes what I've typed so far, restricts the set of candidates to all the matches and lets my type again. This way, I can e.g. type one part of the filename, then C-SPC, then another part, then cycle. AFAIR, in Icicles you can do the same, with the difference that keybindings are (probably) different, and the mechanism is more general. Best, -- Marcin Borkowski http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski Faculty of Mathematics and Computer Science Adam Mickiewicz University ^ permalink raw reply [flat|nested] 18+ messages in thread
* RE: Looking for a buffer-cycling library 2014-11-16 18:01 ` Marcin Borkowski @ 2014-11-16 20:18 ` Drew Adams 0 siblings, 0 replies; 18+ messages in thread From: Drew Adams @ 2014-11-16 20:18 UTC (permalink / raw) To: Marcin Borkowski, help-gnu-emacs > In Ido, I often use C-SPC, which takes what I've typed so far, > restricts the set of candidates to all the matches and lets my > type again. This way, I can e.g. type one part of the filename, > then C-SPC, then another part, then cycle. > > AFAIR, in Icicles you can do the same, with the difference > that keybindings are (probably) different, and the mechanism > is more general. Yes. The Icicles key for this is `S-SPC'. I call this feature "progressive completion". It is typically a lot easier, and quicker, to incrementally apply simple patterns to match than it is to try to come up with a single complex pattern that is equivalent. http://www.emacswiki.org/Icicles_-_Progressive_Completion http://www.emacswiki.org/Icicles_-_Nutshell_View#ProgressiveCompletion A related feature for narrowing choices is what I call "chipping away the non-elephant": matching candidates that you want to exclude instead of include. http://www.emacswiki.org/Icicles_-_Nutshell_View#ChippingAway ^ permalink raw reply [flat|nested] 18+ messages in thread
* Looking for a buffer-cycling library @ 2014-11-14 23:11 Tim Johnson 2014-11-15 1:34 ` Alexis 2014-11-15 16:44 ` Tim Johnson 0 siblings, 2 replies; 18+ messages in thread From: Tim Johnson @ 2014-11-14 23:11 UTC (permalink / raw) To: Emacs 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" Ideally it would work just like 'buffer-next or 'previous-buffer, but I would still be able to access _all_ buffers from 'buffer-menu. It would have to work in terminal mode and my best imagined use would be from a netbook without split windows. Recommendations are welcome. thanks -- Tim tim at tee jay forty nine dot com or akwebsoft dot com http://www.akwebsoft.com, http://www.tj49.com ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Looking for a buffer-cycling library 2014-11-14 23:11 Tim Johnson @ 2014-11-15 1:34 ` Alexis 2014-11-15 3:32 ` Tim Johnson 2014-11-15 16:44 ` Tim Johnson 1 sibling, 1 reply; 18+ messages in thread From: Alexis @ 2014-11-15 1:34 UTC (permalink / raw) To: help-gnu-emacs Tim Johnson writes: > 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" > > Ideally it would work just like 'buffer-next or 'previous-buffer, > but I would still be able to access _all_ buffers from 'buffer-menu. > > It would have to work in terminal mode and my best imagined use > would be from a netbook without split windows. > > Recommendations are welcome. Might something like this be what you're after? --- BEGIN --- (defun get-buffers-with-files () (let ((wanted '())) (dolist (b (buffer-list)) (if (buffer-file-name b) (setq wanted (append wanted (list b))))) wanted)) (add-hook 'buffer-list-update-hook #'(lambda () (setq buffers-with-files (get-buffers-with-files)))) (defun next-buffer-with-file () (interactive) (setq buffers-with-files (append (cdr buffers-with-files) (list (car buffers-with-files)))) (switch-to-buffer (car buffers-with-files))) (defun previous-buffer-with-file () (interactive) (setq buffers-with-files (append (last buffers-with-files) (butlast buffers-with-files))) (switch-to-buffer (car buffers-with-files))) --- END --- Alexis. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Looking for a buffer-cycling library 2014-11-15 1:34 ` Alexis @ 2014-11-15 3:32 ` Tim Johnson 2014-11-15 3:56 ` Alexis 0 siblings, 1 reply; 18+ messages in thread From: Tim Johnson @ 2014-11-15 3:32 UTC (permalink / raw) To: help-gnu-emacs * Alexis <flexibeast@gmail.com> [141114 16:48]: > > Tim Johnson writes: > > > 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" > > > > Ideally it would work just like 'buffer-next or 'previous-buffer, > > but I would still be able to access _all_ buffers from 'buffer-menu. > > > > It would have to work in terminal mode and my best imagined use > > would be from a netbook without split windows. > > > > Recommendations are welcome. > > Might something like this be what you're after? > > --- BEGIN --- > (defun get-buffers-with-files () > (let ((wanted '())) > (dolist (b (buffer-list)) > (if (buffer-file-name b) > (setq wanted (append wanted (list b))))) > wanted)) > > (add-hook 'buffer-list-update-hook #'(lambda () > (setq buffers-with-files (get-buffers-with-files)))) > > (defun next-buffer-with-file () > (interactive) > (setq buffers-with-files (append (cdr buffers-with-files) (list (car buffers-with-files)))) > (switch-to-buffer (car buffers-with-files))) > > (defun previous-buffer-with-file () > (interactive) > (setq buffers-with-files (append (last buffers-with-files) (butlast buffers-with-files))) > (switch-to-buffer (car buffers-with-files))) > --- END --- Looks good Alex, I will have to grok it further tomorrow. As far as a quick hack, I've seen some good stuff at http://stackoverflow.com/questions/14323516/make-emacs-next-buffer-skip-messages-buffer but I thought that a full-blown library might introduce me to some other goodies I haven't thought off. thanks a lot -- Tim tim at tee jay forty nine dot com or akwebsoft dot com http://www.akwebsoft.com, http://www.tj49.com ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Looking for a buffer-cycling library 2014-11-15 3:32 ` Tim Johnson @ 2014-11-15 3:56 ` Alexis 0 siblings, 0 replies; 18+ messages in thread From: Alexis @ 2014-11-15 3:56 UTC (permalink / raw) To: help-gnu-emacs Tim Johnson writes: > I will have to grok it further tomorrow. :-) > As far as a quick hack, I've seen some good stuff at > http://stackoverflow.com/questions/14323516/make-emacs-next-buffer-skip-messages-buffer *nod* > but I thought that a full-blown library might introduce me to some > other goodies I haven't thought off. Fair enough. > thanks a lot You're welcome! :-) Alexis. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Looking for a buffer-cycling library 2014-11-14 23:11 Tim Johnson 2014-11-15 1:34 ` Alexis @ 2014-11-15 16:44 ` Tim Johnson 2014-11-15 17:19 ` Drew Adams 1 sibling, 1 reply; 18+ messages in thread From: Tim Johnson @ 2014-11-15 16:44 UTC (permalink / raw) To: Emacs * Tim Johnson <tim@akwebsoft.com> [141114 14:18]: > 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" > > Ideally it would work just like 'buffer-next or 'previous-buffer, > but I would still be able to access _all_ buffers from 'buffer-menu. > > It would have to work in terminal mode and my best imagined use > would be from a netbook without split windows. > > Recommendations are welcome. Thanks for all the recommendations and code thus far. BTW: icicles has been on my "tolearn" list for some time... -- Tim tim at tee jay forty nine dot com or akwebsoft dot com http://www.akwebsoft.com, http://www.tj49.com ^ permalink raw reply [flat|nested] 18+ messages in thread
* RE: Looking for a buffer-cycling library 2014-11-15 16:44 ` Tim Johnson @ 2014-11-15 17:19 ` Drew Adams 2014-11-15 20:32 ` Tim Johnson 0 siblings, 1 reply; 18+ messages in thread From: Drew Adams @ 2014-11-15 17:19 UTC (permalink / raw) To: Tim Johnson, Emacs > BTW: icicles has been on my "tolearn" list for some time... On mine too. ;-) ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Looking for a buffer-cycling library 2014-11-15 17:19 ` Drew Adams @ 2014-11-15 20:32 ` Tim Johnson 2014-11-15 20:38 ` Drew Adams 0 siblings, 1 reply; 18+ messages in thread From: Tim Johnson @ 2014-11-15 20:32 UTC (permalink / raw) To: Emacs * Drew Adams <drew.adams@oracle.com> [141115 09:13]: > > BTW: icicles has been on my "tolearn" list for some time... > > On mine too. ;-) Drew, you have made a sale. I've been circling around icicles and alacarte for some time now. For my immediate needs, icicles is more than I need, but I have no doubt that I will be using other features in the future and I won't be in terminal mode forever. If (I mean 'when') I have questions, I will pose them under a new subject with 'icicles included so that others interested in the same have a keyword match. thanks -- Tim tim at tee jay forty nine dot com or akwebsoft dot com http://www.akwebsoft.com, http://www.tj49.com ^ permalink raw reply [flat|nested] 18+ messages in thread
* RE: Looking for a buffer-cycling library 2014-11-15 20:32 ` Tim Johnson @ 2014-11-15 20:38 ` Drew Adams 2014-11-15 22:29 ` Tim Johnson 0 siblings, 1 reply; 18+ messages in thread From: Drew Adams @ 2014-11-15 20:38 UTC (permalink / raw) To: Tim Johnson, Emacs > > > BTW: icicles has been on my "tolearn" list for some time... > > > > On mine too. ;-) > > Drew, you have made a sale. Please, no - I'm not selling anything. If it helps you, good. > I've been circling around icicles and alacarte for some time now. > > For my immediate needs, icicles is more than I need, but I have no > doubt that I will be using other features in the future and I > won't be in terminal mode forever. > > If (I mean 'when') I have questions, I will pose them under a new > subject with 'icicles included so that others interested in the > same have a keyword match. OK. And for bug reports: `M-x icicle-send-bug-report'. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Looking for a buffer-cycling library 2014-11-15 20:38 ` Drew Adams @ 2014-11-15 22:29 ` Tim Johnson 0 siblings, 0 replies; 18+ messages in thread From: Tim Johnson @ 2014-11-15 22:29 UTC (permalink / raw) To: Emacs * Drew Adams <drew.adams@oracle.com> [141115 11:41]: > > > > BTW: icicles has been on my "tolearn" list for some time... > > > > > > On mine too. ;-) > > > > Drew, you have made a sale. > > Please, no - I'm not selling anything. If it helps you, good. Oh, I know ... just a metaphor > > I've been circling around icicles and alacarte for some time now. > > > > For my immediate needs, icicles is more than I need, but I have no > > doubt that I will be using other features in the future and I > > won't be in terminal mode forever. > > > > If (I mean 'when') I have questions, I will pose them under a new > > subject with 'icicles included so that others interested in the > > same have a keyword match. > > OK. And for bug reports: `M-x icicle-send-bug-report'. Understood. And thanks. -- Tim tim at tee jay forty nine dot com or akwebsoft dot com http://www.akwebsoft.com, http://www.tj49.com ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2014-11-16 20:18 UTC | newest] Thread overview: 18+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [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 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
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).