From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.help Subject: RE: Looking for a buffer-cycling library Date: Sat, 15 Nov 2014 15:41:23 -0800 (PST) Message-ID: <00789825-5c1b-4563-bea4-d0717f860163@default> References: <87bno8tsps.fsf@wmi.amu.edu.pl> <8ed4206d-52b3-4b6c-9da4-9397ed95fa68@default> <87a93stbtu.fsf@wmi.amu.edu.pl> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1416094926 21913 80.91.229.3 (15 Nov 2014 23:42:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 15 Nov 2014 23:42:06 +0000 (UTC) To: Marcin Borkowski , help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sun Nov 16 00:41:57 2014 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Xpmya-00031J-7k for geh-help-gnu-emacs@m.gmane.org; Sun, 16 Nov 2014 00:41:56 +0100 Original-Received: from localhost ([::1]:42348 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XpmyZ-0003t0-S1 for geh-help-gnu-emacs@m.gmane.org; Sat, 15 Nov 2014 18:41:55 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52907) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XpmyF-0003sd-Mv for help-gnu-emacs@gnu.org; Sat, 15 Nov 2014 18:41:44 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xpmy6-0004OH-SJ for help-gnu-emacs@gnu.org; Sat, 15 Nov 2014 18:41:35 -0500 Original-Received: from userp1040.oracle.com ([156.151.31.81]:35209) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xpmy6-0004O6-Ku for help-gnu-emacs@gnu.org; Sat, 15 Nov 2014 18:41:26 -0500 Original-Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id sAFNfNDO010269 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 15 Nov 2014 23:41:24 GMT Original-Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sAFNfM2P026021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 15 Nov 2014 23:41:23 GMT Original-Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sAFNfM8Y016427; Sat, 15 Nov 2014 23:41:22 GMT In-Reply-To: <87a93stbtu.fsf@wmi.amu.edu.pl> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8.2 (807160) [OL 12.0.6691.5000 (x86)] X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 156.151.31.81 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:100944 Archived-At: 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. >=20 > Wow. Just wow. >=20 > In fact, I was thinking about feeding Icicles a regex like > ^[^*]. Now I can see there's no need to. >=20 > I'll put "throwing Ido out and embracing Icicles" higher on my > priority list. >=20 > > Here is the (long) doc for command `icicle-buffer' (`C-x b' in > > Icicle mode, by default): [...] >=20 > 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.)=20 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.