[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#12898: 24.2.50.1; Completion is not passed further on in emacs-lisp,
From: |
Vitalie Spinu |
Subject: |
bug#12898: 24.2.50.1; Completion is not passed further on in emacs-lisp, org-mode etc. |
Date: |
Tue, 20 Nov 2012 15:47:30 +0100 |
User-agent: |
Gnus/5.130004 (Ma Gnus v0.4) Emacs/24.2.50 (gnu/linux) |
>> Stefan Monnier <monnier@iro.umontreal.ca>
>> on Tue, 20 Nov 2012 08:42:56 -0500 wrote:
>>>> In elisp mode completion-at-point-functions is set to
>>>> (lisp-completion-at-point t). If I set it to (t), filename completion
>>>> works as expected. So, it's the lisp-completion-at-point that is not
>>>> handing the completion over.
SM> Indeed, lisp-completion-at-point should return nil when it determines
SM> that it cannot provide completion information for the text around point.
SM> Problem is: how should it determine that?
>> There is an inbuilt facility (:exclusive 'no). Why is that not the
default?
SM> Because it only works for prefix-completion, so it's a crutch.
This completely defeats the idea of completion-at-point-functions, and
is makes the completion in emacs-24 pretty much useless at this point.
SM> The right way to do it is for lisp-completion-at-point function to
SM> determine whether the data at point should/can be a Lisp name or a file
SM> name or both (if it's both, it could use the :exclusive crutch, or it
SM> could combine the completion tables with completion-table-in-turn).
Are you suggesting that every single xxx-mode-completion-function should
do that? That is, check for all possible combination that a symbol at
point might represent? That doesn't look right to me.
Why the final completion is done in completion-at-point and not in
completion--capf-wrapper? This split across two functions asks for
trouble. Wouldn't it be possible to handle everything in
completion--capf-wrapper and call completion-in-region instead of
try-completion in the handling of (:exclusive 'no) part?
Vitalie