[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: predictive.el -- New Release

From: Toby Cubitt
Subject: Re: predictive.el -- New Release
Date: Wed, 3 May 2006 18:39:28 +0200
User-agent: Mutt/1.5.11

On Wed, May 03, 2006 at 02:44:15PM +0100, Phillip Lord wrote:
> >>>>> "TC" == Toby Cubitt <address@hidden> writes:
>   TC> On Tue, May 02, 2006 at 07:29:33PM +0200, David Hansen wrote:
>   TC> Trouble is, I have to rebind RET or the whole dynamic completion
>   TC> mechanism gets screwed up. I'll see what I can do about making
>   TC> RET sort out any dynamic completion, and then run whatever it
>   TC> would have been bound to otherwise.
>   TC> Shouldn't be too difficult, since I already have a macro that
>   TC> does something very similar. But I wonder if there's a standard
>   TC> solution to this? (Defadvice won't help, since I'd have to
>   TC> advise every function that might be bound to RET!)
> I has the same problem with pabbrev.el, although I bind tab. What I
> tried to do is drop through to the underlying command when there was
> no completion. This ofter works well, but fails if you are, for
> instance indenting five lines by doing "tab,down,tab,down" repeat. You
> end up doing a completion by mistake on one line. 

If I understand correctly, this is because you'll end up at a position
where tab will find a completion, right? I avoided this kind of
problem by binding my equivalent completion function to "\M-tab"
(which is bound to some kind of completion function in most modes)
instead of to tab, and not even attempting to drop to the underlying
command. With dynamic completion, you hardly ever need to hit "\M-tab"

I do need to drop to the underlying command for a lot of other
commands (like I should have for RET), but they're all commands that
only make sense when completion candidates are already on offer. So
there's no ambiguity about which command should be called, it's just
painful at the Lisp level.

> But I've had endless problems getting this working; keybinding in
> emacs is harder than it should be. In the end, I've gone for this.
> (defun pabbrev-get-previous-binding ()
>   "Show the binding of tab if pabbrev were not active.
> The command `pabbrev-show-previous-binding' prints this out."
>   (let ((pabbrev-mode nil))
>     ;; This is the original and satisfying solution
>     ;;(key-binding (char-to-string last-command-event)))))
>     ;; This is the new and unsatisfying one. The
>     ;; keybindings are hard coded here, because I defined
>     ;; [tab] and \t earlier. Both are tab, but the former
>     ;; gets used in preference to the later. 
>     (or (key-binding [tab])
>         (key-binding "\t"))))

I have a "run-if-completion-in-progress" function that does something
similar. I guess this is the only solution then.

I still think the neatest solution would be if Emacs had some way to
"defadvice" keybindings. The advice would run before and/or after the
original binding. Anyone care to implement it? (The above function
already does part of what's needed.)

> BTW, glad to see that you have factored the completion code out; I
> should have done this with pabbrev years ago. I'm sure other people
> would have found it useful. 

Yup, me! ;-)

When I've finished the rewrite, I might try tacking my interface onto
pabbrev mode using my "easy-completion-mm-mode", and you can see what
you think of it.


PhD Student
Quantum Information Theory group
Max Planck Institute for Quantum Optics
Garching, Germany

email: address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]