Re: pabbrev.el

[Toby Cubitt]

William Xu wrote:
> Phillip Lord <address@hidden> 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