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: pymacs & interactivel isp functions Date: Sat, 22 Nov 2008 13:45:05 -0800 Message-ID: <002101c94ceb$958d70f0$0200a8c0@us.oracle.com> References: <1227111389.17262.159.camel@localhost> <000801c94a6d$7d216100$c2b22382@us.oracle.com> <1227343194.20766.717.camel@localhost> <000f01c94cb6$d5ac5690$0200a8c0@us.oracle.com> <1227388071.16060.698.camel@localhost> 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 1227390368 30725 80.91.229.12 (22 Nov 2008 21:46:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 22 Nov 2008 21:46:08 +0000 (UTC) Cc: 'help-gnu-emacs' To: "'Matt Price'" Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sat Nov 22 22:47:10 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 1L40Jn-0003op-RS for geh-help-gnu-emacs@m.gmane.org; Sat, 22 Nov 2008 22:47:08 +0100 Original-Received: from localhost ([127.0.0.1]:54317 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L40Ie-0001Hc-KY for geh-help-gnu-emacs@m.gmane.org; Sat, 22 Nov 2008 16:45:56 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L40Hn-0001GY-Cw for help-gnu-emacs@gnu.org; Sat, 22 Nov 2008 16:45:03 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L40Hk-0001FR-Tn for help-gnu-emacs@gnu.org; Sat, 22 Nov 2008 16:45:03 -0500 Original-Received: from [199.232.76.173] (port=35989 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L40Hk-0001FM-FI for help-gnu-emacs@gnu.org; Sat, 22 Nov 2008 16:45:00 -0500 Original-Received: from acsinet11.oracle.com ([141.146.126.233]:51391) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1L40Hk-0006Nx-EE for help-gnu-emacs@gnu.org; Sat, 22 Nov 2008 16:45:00 -0500 Original-Received: from acsinet13.oracle.com (acsinet13.oracle.com [141.146.126.235]) by acsinet11.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id mAMLjaaA005196 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 22 Nov 2008 21:45:37 GMT Original-Received: from acsmt701.oracle.com (acsmt701.oracle.com [141.146.40.71]) by acsinet13.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id mAMLj94f018659; Sat, 22 Nov 2008 21:45:11 GMT Original-Received: from dradamslap1 (/24.23.165.218) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 22 Nov 2008 13:44:52 -0800 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <1227388071.16060.698.camel@localhost> Thread-Index: AclM5nLcd6LP+y9TSm6ItZaw+W7DSgAAIWiw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Source-IP: acsmt701.oracle.com [141.146.40.71] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.49287D56.015E:SCFSTAT928724,ss=1,fgs=0 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 1) 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:60029 Archived-At: > > Dunno. Your function that does all of the completion, > > `edsquery-return-addresslist' isn't shown. > > here it is, but i don't think it's the problem > it just returns a list of strings, which is what i thought > completing-read wanted to receive. No. As Kevin mentioned, and as I explained prior to that, if you use a function as the COLLECTION argument, then `completing-read' expects that function to do _everything_. It does _not_ expect that function to just return a list of possible completion candidates, which it then uses to perform completion. It expects that COLLECTION function to perform the completion itself. `completing-read' doesn't really do much at all in that case - it simply prompts and then passes your function to `try-completion', which in turn uses your function to perform completion. It's up to your function to perform the completion you want, that is, to do _everything_. This is all documented in the doc strings of `completing-read' and `try-completion', and in the Elisp manual's nodes `Minibuffer Completion' and (especially) `Programmed Completion'. You really must read that if you want to learn this. I'm not sure you need programmed completion for what you want to do - I doubt it, in fact. But if you do, then you need to read the manual about that topic. > > The error message is saying that function > > `ad-Orig-minibuffer-complete' expected > > a number or a marker but received the list of strings. > > i think ad-Orig-minibuffer-complete comes from the > minibuffer-complete-cycle package; i've taken out references to it in > my .emacs for now. but my issue persists. Always try to minimize the number of things in the big sack of unknowns you shake to test code. If your code doesn't rely upon stuff like `minibuffer-complete-cycle', then by all means get rid of it (for now). This is all the more true if such extraneous code advises functions. Advising functions makes debugging more difficult (IMO). You think you are trying to understand `minibuffer-complete', but really you are dealing with some modified (advised) version of it. Walk away from that jungle as fast as you can. > > You also apparently advised the standard function `minibuffer-complete', > > and that code isn't shown either. So it's difficult to guess > > what is the problem. > > i think this came from minibuffer-complete-cycle. > > > > i'm not sure, but it looks like it isn't breaking the cdr > > > cell down into its components before evaluating it? > > > suggesting to me that, again, there's something wrong > > > with my syntax. > > > > No comprendo. What isn't breaking what cdr cell down into > > what components? > > um, i'm sure i just don't know what i'm talking about... Well, that makes two of us. ;-) You will know more after you study the manual about this. > > FWIW, I see nothing wrong with the call to completing-read. > > The problem is likely in your completion function > > `edsquery-return-addresslist'. > > or in my understanding of completing-read, see below. > > > > i appreciate the remedial lisp lessons. sorry to just > > > continue not getting it... thanks again, It's understandable, if you didn't read the manual. It would be quite difficult to understand this stuff if you didn't read up on it. That's what the manual is for - it's your friend. And it is usually much better at explaining things that we folks at help-gnu-emacs. People here are glad to help, but you need to do a minimum of homework yourself - to help yourself. > > The error message should help. Look at your advised version of > > `minibuffer-complete', `ad-Orig-minibuffer-complete', and > > see why and where it expects a number or marker. Look at why > > your function `eds...' gives it a list of strings in that place > > instead. Perhaps try unadvising `minibuffer-complete', > > at least for testing. > > hmm, i thought i wanted edsquery to give a list of strings. > i have the following trivial code which is still giving the > same kind of error, and i think probably illustrates my > conceptual error, whatever it is: See above. a function as the COLLECTION argument is a special case. In that case, `completing-read' is not expecting the function to return a set of completion candidates; it is expecting it to perform completion - completely. ;-) > clearly i'm misunderstanding something but it's the kind of > conceptual error i have trouble finding an answer for in the > documentation. Study node `Programmed Completion' in the manual carefully. If you then have questions, post again here. But if you can produce the set of completion candidates you need, then you likely do not need to worry about programmed completion (i.e. a functional COLLECTION arg) - just provide the list of candidates. Programmed completion is for situations where you cannot do that - where, for instance, such a list depends on something contingent that only becomes available during the completion process itself. Bottom line: If you can give `completing-read' the list of candidates to use, do so. > thanks again. you should feel free to drop me, though, drew -- i > appreciate all your efforts. Don't sell yourself short. _IF_ you need programmed completion, then yes, it is a bit confusing, but node `Programmed Completion' is your friend. _IF_ you don't need it, that is, if you can come up with the list of completion candidates you need explicitly, then just do that.