unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Dmitry Gutov <dgutov@yandex.ru>
Cc: emacs-devel@gnu.org
Subject: Re: /srv/bzr/emacs/elpa r395: * company.el (company-capf): Add support for `sorted' and `post-completion'.
Date: Sun, 05 May 2013 02:32:36 -0400	[thread overview]
Message-ID: <jwv4neilzpc.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <87vc6yz9r4.fsf@yandex.ru> (Dmitry Gutov's message of "Sun, 05 May 2013 01:59:59 +0400")

>> ;; (defun company-my-backend (command &optional arg &rest ignored)
>> -;;   (case command
>> -;;     (prefix (when (looking-back "foo\\>")
>> +;;   (pcase command
>> +;;     (`prefix (when (looking-back "foo\\>")
>> ;;               (match-string 0)))
>> -;;     (candidates (list "foobar" "foobaz" "foobarbaz"))
>> -;;     (meta (format "This value is named %s" arg))))
>> +;;     (`candidates (list "foobar" "foobaz" "foobarbaz"))
>> +;;     (`meta (format "This value is named %s" arg))))

> Like the header in company.el says, we still try to support Emacs 22 and
> 23. `pcase' was only added in 23.3, I believe.

But this is in a comment, so it's not a problem.

>> +(defun company-capf (command &optional arg &rest _args)
> ...
>> +    (duplicates nil) ;Don't bother.
>> +    (no-cache t)     ;FIXME: Improve!
>> +    (meta nil)       ;FIXME: Return one-line docstring for `arg'.
>> +    (doc-buffer nil) ;FIXME: Return help buffer for `arg'.
>> +    (location nil)   ;FIXME: Return (BUF . POS) or (FILE . LINENB) of `arg'.
>> +    (init nil)      ;Don't bother: plenty of other ways to initialize
>> the code.
> a) There's no need to return nils explicitly, other backends don't.

Indeed, I only need them to have a place where to put the FIXMEs.

> b) Who are these FIXMEs for?

Whoever takes on the challenge.

> I guess `meta' can be implemented by
> calling `:annotation-function' (don't know if it's appropriate), but
> `doc-buffer' and `location' don't have anything corresponding in
> `completion-extra-properties'.

`completion-extra-properties' can have anything you want in it.
Same for `completion-metadata'.  Of course, new entries in these
alists/plists won't be understood by other users of
completion-at-point-functions, but that's not a problem in itself.

>> +    (require-match nil)            ;This should be a property of the
>> front-end!
> Should it really?

Hmm... after writing an answer and throwing it away a few times, I think
you're right: this definitely makes sense for a backend and basically
means "I, as a backend, know that only those elements make sense here".

But in most cases the front-end can't use it to *prevent* the user from
writing something else (Emacs likes to let the user shoot himself in the
foot, on the assumption that the user knows better).  It could use it to
highlight a non-matching entry, OTOH.

>> +(defvar company-backend)
> This variable is declared about ~30 lines below that. Is it appropriate
> to have both declarations in the same file?

No, it was a quick fix.  Moving the declaration is probably a better option.

> It probably should, but, again, lexical-binding is not available in
> Emacs < 24. ATM I'm only using it to improve some logic that uses
> `boundp' in `company-elisp'.

I work under the assumption that my time is better spent if
I concentrate on users of Emacs-24 (users who want the newer features of
company can upgrade to Emacs-24).


        Stefan



  reply	other threads:[~2013-05-05  6:32 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <E1UW5x9-0001hw-8W@vcs.savannah.gnu.org>
2013-05-04 21:59 ` /srv/bzr/emacs/elpa r395: * company.el (company-capf): Add support for `sorted' and `post-completion' Dmitry Gutov
2013-05-05  6:32   ` Stefan Monnier [this message]
2013-05-05  8:50     ` Dmitry Gutov
2013-05-05 10:05       ` Sebastian Wiesner
2013-05-05 10:13         ` Dmitry Gutov
2013-05-06  1:18       ` Stefan Monnier
2013-05-06  2:43         ` Dmitry Gutov
2013-05-06  3:22           ` Stefan Monnier
2013-05-09 20:35             ` Dmitry Gutov

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=jwv4neilzpc.fsf-monnier+emacs@gnu.org \
    --to=monnier@iro.umontreal.ca \
    --cc=dgutov@yandex.ru \
    --cc=emacs-devel@gnu.org \
    /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.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

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