lisp-completion-at-point "end" position.

lisp-completion-at-point "end" position.

[Thierry Volpiatto]

Hi,
lisp-completion-at-point return:
beg end [completions] :predicate  :annotation-function

If i complete:(cursor is !)
(def!

The value of beg is the value of point at "d"
The value of end is the value of point at !

Which is correct.

If i complete:
(def! some_text
Same it is correct.

If i complete:(note that there is no space between "!" and "s")
(def!some_text

The value of beg is the value of point at "d"
The value of end is the value of point at "t"

Which is maybe not correct.

Is there a good reason for that?

I must use just `point' here instead of the end value that
lisp-completion-at-point return to handle this case.

BTW i see a comment in source code:
  ;; FIXME: the `end' could be after point?
Don't know what that mean.

-- 
A+ Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: lisp-completion-at-point "end" position.

[Stefan Monnier]

> If i complete:(note that there is no space between "!" and "s")
> (def!some_text

> The value of beg is the value of point at "d"
> The value of end is the value of point at "t"

Yes, so you can do complete (wit!sel to (with-selected-.
Whether that is done or not will depend on completion-styles, where the
difference between `basic', `emacs22', and `emacs21' is exactly about
what to do in such a case.

> Is there a good reason for that?

I'll let you judge whether it's good or not.  But it's the same behavior
as in the minibuffer.


        Stefan

Re: lisp-completion-at-point "end" position.

[Thierry Volpiatto]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> If i complete:(note that there is no space between "!" and "s")
>> (def!some_text
>
>> The value of beg is the value of point at "d"
>> The value of end is the value of point at "t"
>
> Yes, so you can do complete (wit!sel to (with-selected-.
> Whether that is done or not will depend on completion-styles, where the
> difference between `basic', `emacs22', and `emacs21' is exactly about
> what to do in such a case.
It seem these completion-styles work when using completion-at-point, but
not when using directly lisp-completion-at-point and i see nothing here taking
care of this:

--8<---------------cut here---------------start------------->8---
(end
 (unless (or (eq beg (point-max))
             (member (char-syntax (char-after beg)) '(?\" ?\( ?\))))
   (condition-case nil
       (save-excursion
         (goto-char beg)
         (forward-sexp 1)
         (when (>= (point) pos)
           (point)))
     (scan-error pos)))))
--8<---------------cut here---------------end--------------->8---

So 
(let ((completion-styles 'emacs22)) 
  (lisp-completion-at-point))

(let ((completion-styles 'partial-completion))
  (lisp-completion-at-point))

(let ((completion-styles 'basic)) (lisp-completion-at-point))

Returns the same value.

But well, it's ok i use always the value of `point' here instead of
(cadr lisp-completion-at-point).

>> Is there a good reason for that?
>
> I'll let you judge whether it's good or not.  But it's the same behavior
> as in the minibuffer.
It's inconvenient to have to type a space just to have completion.
e.g:
(def!(something) => doesn't complete def
(def! (something) => complete def

-- 
A+ Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: lisp-completion-at-point "end" position.

[Stefan Monnier]

> (let ((completion-styles 'emacs22))
>   (lisp-completion-at-point))

completion-styles does not influence the set of completions and the
completion field (which is what lisp-completion-at-point returns).
Instead it influences how the completion UI acts on that information.

I.e. the value of completion-styles is only used when completion is
actually performed (e.g. by completion-in-region).

>>> Is there a good reason for that?
>> I'll let you judge whether it's good or not.  But it's the same behavior
>> as in the minibuffer.
> It's inconvenient to have to type a space just to have completion.
> e.g:
> (def!(something) => doesn't complete def
> (def! (something) => complete def

A space should not be needed when the subsequent char is an open-paren.


        Stefan

Re: lisp-completion-at-point "end" position.

[Thierry Volpiatto]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> (let ((completion-styles 'emacs22))
>>   (lisp-completion-at-point))
>
> completion-styles does not influence the set of completions and the
> completion field (which is what lisp-completion-at-point returns).
> Instead it influences how the completion UI acts on that information.
>
> I.e. the value of completion-styles is only used when completion is
> actually performed (e.g. by completion-in-region).
I understood that.

>>>> Is there a good reason for that?
>>> I'll let you judge whether it's good or not.  But it's the same behavior
>>> as in the minibuffer.
>> It's inconvenient to have to type a space just to have completion.
>> e.g:
>> (def!(something) => doesn't complete def
>> (def! (something) => complete def
>
> A space should not be needed when the subsequent char is an open-paren.
At another level, not lisp-completion-at-point.

My concern was lisp-completion-at-point, not the completion UI of
emacs. (i don't use it).

Thanks for infos.

-- 
A+ Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: lisp-completion-at-point "end" position.

[Stefan Monnier]

>>> (def(something) => doesn't complete def
>>> (def! (something) => complete def
>> A space should not be needed when the subsequent char is an open-paren.
> At another level, not lisp-completion-at-point.

No, I mean for lisp-completion-at-point.  I.e. I can't reproduce the
problem you show above.

> My concern was lisp-completion-at-point, not the completion UI of
> emacs. (i don't use it).

I understand that.  But completion-at-point-functions does allow point
to be within the to-be-completed element (rather than only at its end)
and so a UI that wants to use it needs to take this into account (it
may for example elect to ignore the `end' and always use point instead).


        Stefan

Re: lisp-completion-at-point "end" position.

[Thierry Volpiatto]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>>> (def(something) => doesn't complete def
>>>> (def! (something) => complete def
>>> A space should not be needed when the subsequent char is an open-paren.
>> At another level, not lisp-completion-at-point.
>
> No, I mean for lisp-completion-at-point.  I.e. I can't reproduce the
> problem you show above.
If you eval:

(let ((data (lisp-completion-at-point))) (cadr data)) 

with point (!) at: 

(def!(something)

and then point (!) at: 

(def! (something)

You will get a different value.


>> My concern was lisp-completion-at-point, not the completion UI of
>> emacs. (i don't use it).
>
> I understand that.  But completion-at-point-functions does allow point
> to be within the to-be-completed element (rather than only at its end)
> and so a UI that wants to use it needs to take this into account (it
> may for example elect to ignore the `end' and always use point instead).
Yes, i prefer `point' for my lisp completion.

-- 
A+ Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: lisp-completion-at-point "end" position.

[Stefan Monnier]

>>>>> (def(something) => doesn't complete def
>>>>> (def! (something) => complete def
>>>> A space should not be needed when the subsequent char is an open-paren.
>>> At another level, not lisp-completion-at-point.
>> 
>> No, I mean for lisp-completion-at-point.  I.e. I can't reproduce the
>> problem you show above.
> If you eval:

> (let ((data (lisp-completion-at-point))) (cadr data)) 

> with point (!) at: 

> (def!(something)

> and then point (!) at: 

> (def! (something)

> You will get a different value.

No, I get the same value.  I just tried with an "emacs -Q" on the trunk.


        Stefan

Re: lisp-completion-at-point "end" position.

[Thierry Volpiatto]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>>>>> (def(something) => doesn't complete def
>>>>>> (def! (something) => complete def
>>>>> A space should not be needed when the subsequent char is an open-paren.
>>>> At another level, not lisp-completion-at-point.
>>> 
>>> No, I mean for lisp-completion-at-point.  I.e. I can't reproduce the
>>> problem you show above.
>> If you eval:
>
>> (let ((data (lisp-completion-at-point))) (cadr data)) 
>
>> with point (!) at: 
>
>> (def!(something)
>
>> and then point (!) at: 
>
>> (def! (something)
>
>> You will get a different value.
>
> No, I get the same value.  I just tried with an "emacs -Q" on the trunk.
Yes, sorry, it works with this example.
It doesn't with:
(def!something

It's why i prefer always the value of point instead of end.

Thanks. 

-- 
A+ Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: lisp-completion-at-point "end" position.

[Stefan Monnier]

> Yes, sorry, it works with this example.
> It doesn't with:
> (def!something

I know.  But it's a feature, not a bug.

> It's why i prefer always the value of point instead of end.

That's perfectly fine and is under the control of the completion UI.


        Stefan