From: Stefan Monnier <monnier@IRO.UMontreal.CA>
To: Vitalie Spinu <spinuvit@gmail.com>
Cc: emacs-devel@gnu.org
Subject: Re: Completion with (:exclusive 'no) is called twice, and doesn't pass over on sole completion.
Date: Sun, 18 Mar 2012 20:53:11 -0400 [thread overview]
Message-ID: <jwvvcm1ju9r.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <87ehspogzt.fsf@gmail.com> (Vitalie Spinu's message of "Sun, 18 Mar 2012 20:18:14 +0100")
>>> Yes, and no. What I meant is that the underlying mechanisms are very
>>> different. 99.99% of the time the completion candidates are the same,
>>> but there are objects which are not meaningful to cache, like arguments
>>> of the user functions, or components of the recursive structures (lists,
>>> environments, data.frames etc.). In this cases AC also calls the
>>> process, and it's usually fast. But in some extreme corner cases, like
>>> if user changed a function in an attached package, AC will still use the
>>> cached version.'
>> So, IIUC it would be perfectly OK for TAB completion to use the AC code.
> Indeed, you could be right that always one-for-all completion function
> might be made enough for the prefix completion. But I don't see how popup
> menu can properly deal with partial completions for example,
I'd expect popup menus wouldn't use the partial-completion style, but
that's not a problem: the completion-styles only care about what to do
once we have the completion data, whereas completion-at-point-function
does not care about it at all since it only cares about providing that
completion data.
Every kind of completion UI can use its own (set of) completion
style(s). If AC can be made to use a partial-completion style, great,
but if not that's just as well.
> or expansions a la yas.
I guess you're referring to some part of yasnippet, but I don't know
which part, nor why it is related to completion-at-point-functions.
> So you would still need a separate list for those.
As explained, partial-completion is another problem. As for abbrev-like
"completion+expansion", I don't see why it can't work with AC (and if
it can't work, the completion-at-point-function can return some data
in its `props' making it clear it can't be used for AC).
> And the old argument still stands - would the user like to have the same
> redundant list of completion functions for C-M-i and popup menu?
I don't see why not. Tho, for completions like etags-completion or
dabbrev-completion, i.e. forms of completions which don't actually know
whether the candidates they return are actually relevant at point, maybe
we'd like to make exceptions (like we already do for dabbrev-completions
which are bound to a special key rather than to TAB).
>>>> Hmm... more consistency in the naming might be good here, indeed.
>>>> It's important to keep the "<package>-" prefix since I don't want to
>>>> consider all of this as part of Emacs's "core", but maybe we could
>>>> settle on "<something>-completion-at-point-function" or maybe something
>>>> shorter than that.
>>> I am a fan of the -completion postfix convention. It's easy to match in
>>> apropos, anything or IDO regexp: comint-filename-completion,
>>> tags-completion, imenu-completion, imenu-in-same-mode-completion,
>>> words-in-same-buffer-commpletion etc. It can get pretty long by itself,
>>> so a short postfix is better.
>> But I suspect it will generate false positives because it's not
>> specific enough. Maybe "-completion-data"?
> Maybe -c-a-p, or -c-a-p-data?
I used "-capf" within the code of completion-at-point, but I think it's
too cryptic for use outside of that context.
Stefan
next prev parent reply other threads:[~2012-03-19 0:53 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-16 11:05 Completion with (:exclusive 'no) is called twice, and doesn't pass over on sole completion Vitalie Spinu
2012-03-16 12:18 ` Vitalie Spinu
2012-03-16 17:20 ` Stefan Monnier
2012-03-16 19:33 ` Vitalie Spinu
2012-03-17 22:34 ` Stefan Monnier
2012-03-17 22:43 ` Lennart Borgman
2012-03-17 23:33 ` Vitalie Spinu
2012-03-18 2:03 ` Stefan Monnier
2012-03-18 9:35 ` Vitalie Spinu
2012-03-18 15:42 ` Stefan Monnier
2012-03-18 19:18 ` Vitalie Spinu
2012-03-19 0:53 ` Stefan Monnier [this message]
2012-03-19 8:35 ` Vitalie Spinu
2012-03-19 12:49 ` Stefan Monnier
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwvvcm1ju9r.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=emacs-devel@gnu.org \
--cc=spinuvit@gmail.com \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.