bug#12898: 24.2.50.1; Completion is not passed further on in emacs-lisp, org-mode etc.

[Vitalie Spinu <spinuvit@gmail.com>]

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