RE: pymacs & interactivel isp functions

[Drew Adams]

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