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: basic using icicels Date: Thu, 4 Sep 2008 09:02:18 -0700 Message-ID: <00e701c90ea7$9bb09ca0$c2b22382@us.oracle.com> References: <86652b00-63b5-4ac6-b0ae-5b4ab34d440f@79g2000hsk.googlegroups.com><5eed0732-7732-481c-a2e8-2aa85e968c03@56g2000hsm.googlegroups.com> <598d6ce6-4ead-4c60-b982-2aec66e02316@n33g2000pri.googlegroups.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1220544542 15684 80.91.229.12 (4 Sep 2008 16:09:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 4 Sep 2008 16:09:02 +0000 (UTC) To: "'tomer'" , Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Thu Sep 04 18:09:56 2008 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1KbHOn-0000bv-Mw for geh-help-gnu-emacs@m.gmane.org; Thu, 04 Sep 2008 18:09:34 +0200 Original-Received: from localhost ([127.0.0.1]:40406 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KbHNo-0003aQ-AE for geh-help-gnu-emacs@m.gmane.org; Thu, 04 Sep 2008 12:08:32 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KbHI5-0000RF-G6 for help-gnu-emacs@gnu.org; Thu, 04 Sep 2008 12:02:37 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KbHI3-0000OL-3B for help-gnu-emacs@gnu.org; Thu, 04 Sep 2008 12:02:36 -0400 Original-Received: from [199.232.76.173] (port=41244 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KbHI2-0000O9-7t for help-gnu-emacs@gnu.org; Thu, 04 Sep 2008 12:02:34 -0400 Original-Received: from rgminet01.oracle.com ([148.87.113.118]:21767) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KbHI1-00059S-AF for help-gnu-emacs@gnu.org; Thu, 04 Sep 2008 12:02:33 -0400 Original-Received: from rgmgw2.us.oracle.com (rgmgw2.us.oracle.com [138.1.186.111]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id m84G2Dgh012245; Thu, 4 Sep 2008 10:02:14 -0600 Original-Received: from acsmt701.oracle.com (acsmt701.oracle.com [141.146.40.71]) by rgmgw2.us.oracle.com (Switch-3.2.4/Switch-3.2.4) with ESMTP id m84G2AEt003636; Thu, 4 Sep 2008 10:02:10 -0600 Original-Received: from dradamslap1 (/130.35.178.194) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 04 Sep 2008 09:02:10 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <598d6ce6-4ead-4c60-b982-2aec66e02316@n33g2000pri.googlegroups.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AckOWUk3hD1+68mOT8CZZ/U0mD+YjQARlnGg X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-detected-kernel: by monty-python.gnu.org: Linux 2.4-2.6 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:57267 Archived-At: Hi Tomer, > Thanks, I have tried it it works only in start of buffer. > when i use it in the middle of of bufffer the icicles tries to > complete the word backwords to the cursor. Sorry, I have no idea what you mean by "complete the word backwards to the cursor". If you feel you've found a bug, please report it: `M-x icicle-send-bug-report'. Please give a precise, step-by-step recipe, starting with emacs -Q. FYI: Read node "Bugs" in the Emacs manual, particularly subnode "Understanding Bug Reporting". This is the intended behavior: 1. If the text before point can be completed as a prefix, it is. Completion candidates are provided in *Completions*. The candidates are those determined by dabbrev. 2. Otherwise, if your minibuffer input is empty, then all words are presented as candidates. (All words in all buffers, if you use `C-u C-u'.) 3. Otherwise (your input is not empty, and there are no matching candidates), a message tells you there are no completions. #1 and #3 are the same as for vanilla Emacs command `dabbrev-completion'. In particular, wrt #1, whenever text before point can be completed, it is. See the dabbrev doc for how it determines whether the text before point can be completed and which words are chosen as candidates. This is where `icicle-dabbrev-completion' differs from vanilla `dabbrev-completion': * In #2 above - vanilla dabbrev just raises an error saying sorry, no completion. * You can use minibuffer completion to choose a candidate in *Completions*. Vanilla dabbrev does not use the minibuffer for completion. * You can use all Icicles completion enhancements to choose a candidate: apropos completion, progressive completion, chipping away stuff you don't want, etc. > Is there an option to 'tell" icicles that if there is space before the > cursor and exeucte completion , then the icicles would give me ALL > words in ALL buffers ? No. See #1 above. Icicles uses the same criteria as vanilla dabbrev for deciding whether the text before point can be completed. And it uses the same initial set of candidates. My guess is that this is what you are running into. You seem to be expecting that a space before point means there can be no matching completions. Dabbrev thinks differently - it often lets you complete text before point even when there is a space. This is by design (feature, not bug), and it is unrelated to Icicles. That is, Icicles (at least so far) does not try to be smarter than dabbrev in this regard. I've assumed that dabbrev's determination of whether a completion is possible is pretty good. Icicles only provides you additional completion features, once dabbrev has determined that completion is possible. Nevertheless, there are some dabbrev user options that might affect this determination (what gets completed, in which contexts). Please take a look: `M-x customize-group RET dabbrev'. > in other words Is possible the use ALL words in ALL buffer not just in > the start of buffer ? Yes, but only when there is no completion for the text at point. And the vanilla dabbrev design is used for that determination. There are many contexts in "the middle of of bufffer" where, if your input is empty, (a) vanilla Emacs raises a no-match error and (b) Icicles provides all completions (from all buffers, if you use C-u C-u) as candidates. Experiment a bit and you will see this. But there are other contexts in the middle of the buffer, including sometimes after a space, where dabbrev (and Icicles) determines that completions are available for the text preceding point, and it presents only those completions as candidates. Suggestion: Play with vanilla `dabbrev-completion' a while, to get to know what it does, how it works, and what its limitations are. Then play with `icicle-dabbrev-completion'. Then, if you think you have a useful concrete suggestion, please send it along. Or if you find a bug, send that along. But please let yourself get to know the existing design a bit first. That will inform any suggestion or bug report you send, helping you to keep it specific. `icicle-dabbrev-completion' was not intended as a completely different way to complete words in a buffer. The idea was just to improve on the completion mechanism. But I'm open to suggestions.