bug#18265: 24.3.92; lisp-completion-at-point should return nil in comments, unless after `

bug#18265: 24.3.92; lisp-completion-at-point should return nil in comments, unless after `

[Dmitry]

https://github.com/company-mode/company-mode/issues/167

`company-elisp' does that, by the way.

In GNU Emacs 24.3.92.4 (x86_64-unknown-linux-gnu, GTK+ Version 3.10.8)
 of 2014-08-06 on axl
Repository revision: 117425 eliz@gnu.org-20140805133406-w7477hyd1gl9h1d7
Windowing system distributor `The X.Org Foundation', version 11.0.11501000
System Description:	Ubuntu 14.04.1 LTS

bug#18265: 24.3.92; lisp-completion-at-point should return nil in comments, unless after `

[Stefan Monnier]

> https://github.com/company-mode/company-mode/issues/167
> `company-elisp' does that, by the way.

Good point.  Makes me wonder how to extend completion-at-point-functions
such that a function like lisp-completion-at-point could behave
differently for something like Company (which calls it without the user
making an explicit completion request) than for an explicit M-TAB.


        Stefan

bug#18265: 24.3.92; lisp-completion-at-point should return nil in comments, unless after `

[Dmitry Gutov]

On 08/15/2014 07:04 AM, Stefan Monnier wrote:

> Good point.  Makes me wonder how to extend completion-at-point-functions
> such that a function like lisp-completion-at-point could behave
> differently for something like Company (which calls it without the user
> making an explicit completion request) than for an explicit M-TAB.

Sometimes the user makes an explicit request, though. So it's "idle mode 
vs manual mode", not "Company vs complete-symbol".

Still, the fact that user called `M-x company-complete' inside a comment 
doesn't tell me that they actually want to see completions from 
`company-capf' and not some other backend like `company-dabbrev'.

Likewise, user pressing C-M-i inside a comment might prefer not to talk 
`lisp-completion-at-point', but some other completion function that goes 
after it that's more suited for completion in comments.

If we really want to use `lisp-completion-at-point' in comments in more 
cases, I'd try to detect whether we're probably in a code sample (by the 
extra indentation, maybe), and otherwise return nil.

bug#18265: 24.3.92; lisp-completion-at-point should return nil in comments, unless after `

[Stefan Monnier]

> Sometimes the user makes an explicit request, though. So it's "idle mode vs
> manual mode", not "Company vs complete-symbol".

That's right.

> Still, the fact that user called `M-x company-complete' inside a comment
> doesn't tell me that they actually want to see completions from
> `company-capf' and not some other backend like `company-dabbrev'.

Indeed, but it does say that it's better to return some completion table
than none.  We'd want the lisp-completion-at-point to use something like
the ":exclusive no" property (or maybe a new ":merge-with-rest") in
this case.

> Likewise, user pressing C-M-i inside a comment might prefer not to talk
> `lisp-completion-at-point', but some other completion function that goes
> after it that's more suited for completion in comments.

As it currently stands, there's no question that your original request
is right (the one stated in the "Subject:"), so feel free to fix it.

I'm just thinking of how we could also satisfy those who might want to
complete code-like things in comments, without having to resort
to customization.


        Stefan

bug#18265: 24.3.92; lisp-completion-at-point should return nil in comments, unless after `

[Dmitry Gutov]

On 08/15/2014 04:33 PM, Stefan Monnier wrote:

> As it currently stands, there's no question that your original request
> is right (the one stated in the "Subject:"), so feel free to fix it.

Ok thanks, I will. I've been holding off on committing to trunk until I 
start using it again, but maybe it's time.

> I'm just thinking of how we could also satisfy those who might want to
> complete code-like things in comments, without having to resort
> to customization.

I've suggested one approach (in addition to seeing if there's a 
backquote before the current prefix): look if the current text is 
specially indented and separated with empty lines (though this is a very 
imprecise heurystic).

And for the cases when it's not, we can add a new completion function at 
the end of the default c-a-p-f value, which would work like 
`company-dabbrev' does. Or like `company-dabbrev-code', in `prog-mode' 
descendants. `company-capf' would ignore it, for the time being, like it 
does with `tags-completion-at-point-function' currently.

You've called ":exclusive no" a hack yourself before, and 
:merge-with-rest looks not much different to me, going counter to the 
c-a-p-f interface.

It raises questions, like if `lisp-completion-at-point' would like to be 
merged with the rest, will it be merged with all of them? Won't the 
other completion functions get a choice in the matter? What if one of 
them is smart enough to provide all completions for the current context, 
by itself?

And anyway, it doesn't seem to help with the distinction between manual 
and idle completion, unless you'd prefer to only activate the 
:merge-with-rest logic in the case of manual invocation. Which seems 
orthogonal to the property's purpose.

bug#18265: 24.3.92; lisp-completion-at-point should return nil in comments, unless after `

[Stefan Monnier]

> You've called ":exclusive no" a hack yourself before, and :merge-with-rest
> looks not much different to me, going counter to the c-a-p-f interface.

While it's "counter to the c-a-p-f interface", the need to combine
several backends is sufficiently common that we need to support it somehow.

I hope a "merge" solution can use a less hackish solution than the
current ":exclusive no".

> It raises questions, like if `lisp-completion-at-point' would like to be
> merged with the rest, will it be merged with all of them?

That'd be my choice, so far, yes.

> Won't the other completion functions get a choice in the matter?

Not sure if/when this would be needed.  I'd rather avoid it if I can.

> What if one of them is smart enough to provide all completions for the
> current context, by itself?

Then it should come earlier.

> And anyway, it doesn't seem to help with the distinction between manual and
> idle completion,

Indeed, it's a largely orthogonal issue.


        Stefan

bug#18265: 24.3.92; lisp-completion-at-point should return nil in comments, unless after `

[Dmitry Gutov]

Version: 24.5

On 08/16/2014 10:00 PM, Stefan Monnier wrote:

> While it's "counter to the c-a-p-f interface", the need to combine
> several backends is sufficiently common that we need to support it somehow.
>
> I hope a "merge" solution can use a less hackish solution than the
> current ":exclusive no".

I'm not convinced with this approach. At least, AFAICS, different users 
prefer to merge different backends together. For instance, some 
https://github.com/iquiw/company-ghc users like to merge its results 
with the plain company-dabbrev-code. Some, I believe, don't.

If the completion function gets to decide that, it would be harder for 
users to customize.

>> And anyway, it doesn't seem to help with the distinction between manual and
>> idle completion,
>
> Indeed, it's a largely orthogonal issue.

I've installed the in-string-or-comment piece of logic that's been 
missing compared to company-elisp, so this bug should be settled.

The distinction between manual and idle completion doesn't seem to be 
very useful here, so let's leave that until there's a definite demand 
for it.

bug#18265: 24.3.92; lisp-completion-at-point should return nil in comments, unless after `

[Stefan Monnier]

>> While it's "counter to the c-a-p-f interface", the need to combine
>> several backends is sufficiently common that we need to support it somehow.
>> I hope a "merge" solution can use a less hackish solution than the
>> current ":exclusive no".

> I'm not convinced with this approach. At least, AFAICS, different users
> prefer to merge different backends together. For instance, some
> https://github.com/iquiw/company-ghc users like to merge its results with
> the plain company-dabbrev-code. Some, I believe, don't.

> If the completion function gets to decide that, it would be harder for users
> to customize.

It might be textually a bit more verbose, but other than that it
shouldn't be harder.  I'm thinking of something like

  (add-hook 'completion-at-point-functions
            (completion-table-merge
             ghc-completion-table dabbrev-completion-table)
            nil t)


-- Stefan

bug#18265: 24.3.92; lisp-completion-at-point should return nil in comments, unless after `

[Dmitry Gutov]

On 09/19/2014 06:49 PM, Stefan Monnier wrote:

>> If the completion function gets to decide that, it would be harder for users
>> to customize.
>
> It might be textually a bit more verbose, but other than that it
> shouldn't be harder.  I'm thinking of something like
>
>    (add-hook 'completion-at-point-functions
>              (completion-table-merge
>               ghc-completion-table dabbrev-completion-table)
>              nil t)

The users might find it harder to modify these new c-a-p-f values if 
some packages add them during initialization, but otherwise this 
direction is quite in line with what we already do in Company.

And it's different from the `:merge-with-rest' property which you 
suggested earlier (a good thing, IMO).

bug#18265: 24.3.92; lisp-completion-at-point should return nil in comments, unless after `

[Stefan Monnier]

> The users might find it harder to modify these new c-a-p-f values if some
> packages add them during initialization,

Indeed.  But I think there's no very serious obstacle.


        Stefan