El Tue, Oct 27, 2009 at 11:23:44PM -0400, Stefan Monnier ens deleità amb les següents paraules: > > Are you looking for examples of hooks that would be needed, or examples > > of behaviors that need hooks to be designed? > > Examples of hooks that could make such things possible. Ok, so here's a high-level shot on a possible completion infrastructure. Note that much of what I describe is oriented towards programming. * Completion candidates ** Information Contains whatever information the system could gather about the symbol. When programming with semantic activated, this could be the semantic tag structure. ** Actions Various actions that can be applied on a candidate. This is basically the interface to view the candidate information. *** get-* Recollect the interesting bits from information, so that the user can easily access it independently of the "information backend" (e.g., semantic tags). **** get-name Candidate name **** get-location Where the candidate has been defined **** get-return Return type of the candidate (only meaningful on programming candidates) **** get-arguments Arguments of the candidate (idem) **** get-short-help Short version of candidate help **** get-long-help Long version of candidate help *** show Shows an arbitrary composition of get-*. E.g., (concat (get-signature candidate) "\n" (get-long-help candidate)) Where that sould be shown, must be user selectable (see below *** insert-* Insert "something" at point (cannot think of use-cases where insertion takes place in other places other than point). **** insert-name Insert the good old completion candidate name. **** insert-template Insert a "template" based on the candidate information. E.g., open(<>, <>) The <<...>> parts are yasnippet-like placeholders for the user to fill. This could be complicated even more, like: * insert a placeholder for the result if compeltion is at first non-blank column. * insert ";" at end if completion is at first non-blank column. * show parameter/return help (e.g., when help follows doxygen style) when moving between placeholders. * UI ** Types The completion-ui package has implementations for some (if not all) of them. The UI *** buffer Is the current *Completions* buffer. *** minibuffer The completion system used by, e.g., predictive-mode. *** overlay That's the one I prefer, see company-mode as an example. *** others There are many others, like menus, etc. ** Operations All action triggered by operations should be possibly be configured on a per-information-backend basis (e.g., completions from yasnippet do not have any meaningful `get-return'). *** start Start the completion process. E.g.: (show current-ui get-return get-name get-arguments) would show the full signature of a function. *** focus Let's the user "highlight" an entry of the possible candidates. It's the good old next/prev in an overlay UI. Focusing an element can trigger other actions. This will mainly be (show ...) The could be any of minibuffer, another buffer, tooltip, etc. *** select Called when the user selects a candidate. This can trigger insert and/or show actions. In fact, triggering only show actions could be used to reuse this very same infrastructure for other purposes other than completion, like a user-configurable tool to show help on symbol at point. *** completion-map Extra actions the user can trigger through keyboard when the completion UI is "active". E.g., i can focus to an interesting symbol and trigger (show some-buffer get-long-help) This probably means a whole lot of coding and I'm neither knowledgeable of current state of functionalities nor proficient in elisp. Just a thought, Lluis -- "And it's much the same thing with knowledge, for whenever you learn something new, the whole world becomes that much richer." -- The Princess of Pure Reason, as told by Norton Juster in The Phantom Tollbooth