William Xu wrote:
Phillip Lord <[EMAIL PROTECTED]> writes:
pabbrev.el provides predictive, as you type abbreviation expansion, based on
words already typed in the buffer, offering expansions in buffer with a
natural and immediate user interface.
So the main difference with hippie-expand is that pabbrev inserts one
predictive candicate when typing? I wonder if this could be incorporated
into hippie-expand.
Most of the pabbrev code is hidden behind that "main difference"! It
would make as much sense to incorporate hippie-expand into pabbrev as
the other way around.
Luckily, something like this has already been done. My completion-UI
package provides a generic in-buffer completion user-interface, cleanly
separating the user-interface aspects (displaying and selecting
completions) from the task of actually finding the completions in the
first place. Completion-UI's "dynamic completion" interface is
unashamedly based on hippie-expand's neat ideas, and should be a good
substitute. Think of completion-UI's "dynamic completion" as stripping
out the UI part of hippie-expand and allowing it to work generically
with any completion package. (Though the code-bases are completely
independent.) Of course, completion-UI provides many other interfaces,
beyond "dynamic completion", and leaves it up to the user to choose and
customize which they want to use (which means it may not behave exactly
like hippie-expand "out of the box").
The Emacs Wiki contains code snippets that provide the simple glue
between completion-UI and a number of completion-finding mechanisms (so
far: dabbrevs, etags, and predictive-mode). It would be trivial to write
the ten-or-so-line wrapper function needed to do the same for pabbrev.
I'd encourage anyone who does so to post it to the CompletionUI wiki
page, and link it from the pabbrev page. (Unsurprisingly I personally
use predictive-mode rather than pabbrev, so I've never gotten around to
doing this myself.)
Toby Cubitt
_______________________________________________
gnu-emacs-sources mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/gnu-emacs-sources
