unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
To: "'Matt Price'" <matt.price@utoronto.ca>
Cc: 'help-gnu-emacs' <help-gnu-emacs@gnu.org>
Subject: RE: pymacs & interactivel isp functions
Date: Sat, 22 Nov 2008 13:45:05 -0800	[thread overview]
Message-ID: <002101c94ceb$958d70f0$0200a8c0@us.oracle.com> (raw)
In-Reply-To: <1227388071.16060.698.camel@localhost>

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

<snipped>

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

<snipped>

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.






  reply	other threads:[~2008-11-22 21:45 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-19 16:16 pymacs & interactivel isp functions Matt Price
2008-11-19 17:37 ` Drew Adams
2008-11-22  8:39   ` Matt Price
2008-11-22 15:27     ` Kevin Rodgers
2008-11-22 15:27     ` Drew Adams
2008-11-22 21:07       ` Matt Price
2008-11-22 21:45         ` Drew Adams [this message]
     [not found] <mailman.747.1227111401.26697.help-gnu-emacs@gnu.org>
2008-11-20 19:48 ` Greg Detre

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='002101c94ceb$958d70f0$0200a8c0@us.oracle.com' \
    --to=drew.adams@oracle.com \
    --cc=help-gnu-emacs@gnu.org \
    --cc=matt.price@utoronto.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).