Re: predictive.el -- New Release

[Toby Cubitt]

On Wed, May 03, 2006 at 04:19:27AM +0200, David Hansen wrote:
> On Tue, 2 May 2006 23:33:52 +0200 Toby Cubitt wrote:
> 
> > On Tue, May 02, 2006 at 07:29:33PM +0200, David Hansen wrote:
> >> Just a note: rebinding RET is IMHO a very bad idea.  In programming
> >> modes i have bound it to `reindent-then-newline-and-indent' and
> >> e.g. rcirc won't work with predictive at all (RET is bound to
> >> `rcirc-send-input').
> >
> > You're right, of course.
> >
> > Trouble is, I have to rebind RET or the whole dynamic completion
> > mechanism gets screwed up. I'll see what I can do about making RET
> > sort out any dynamic completion, and then run whatever it would have
> > been bound to otherwise.
> >
> > Shouldn't be too difficult, since I already have a macro that does
> > something very similar. But I wonder if there's a standard solution to
> > this? (Defadvice won't help, since I'd have to advise every function
> > that might be bound to RET!)
> 
> You can get the original command bound to RET from
> `current-local-map' or `current-global-map'.

Maybe I'm missing something, but won't that fail if RET is bound in
another minor mode map? At the moment, I just temporarily disable the
minor mode map in which predictive mode binds RET, call normal key
lookup functions to get the old binding, execute it, then re-enable
the predictive mode map (this is all hidden inside a macro). This has
the advantage of making absolutely sure I run whatever RET would have
been bound to.

I should mention that I don't actually do this for RET yet. I missed
that one. I do it for various other key bindings, which is why it will
be simple to do it for RET too.

> But maybe `*-command-hook' or `*-change-functions' are a
> more clean solution.

I doubt it. There's no need to run the whole kaboodle for each and
every command! The cleanest solution would be to "defadvice" the RET
key binding, but I don't know how to do that.

> Do you plan do add semantics completion feature to your
> package?  I think your UI is far better than semantics
> tooltip or completion buffer UI.

Thanks for the positive feedback. It's good to know the interface is
along the right directions.

I'm currently re-writing the completion-ui code so that all you have
to do to define a minor mode that does in-buffer completion is write a
function that accepts a prefix and returns a list of completion
candidates. Pass that to a `completion-easy-mm-mode' macro (or set a
variable in your minor mode function), and you will get all the
completion UI I've developed for free. That should make it very easy
to write a minor mode that uses semantic's completion with my
interface. Or any other type of completion, for that matter.

My longer-term plan is to use semantic to do context-sensitive
*predictive* completion in any code buffer that semantic can
parse. (Predictive mode already does this, without needing semantic,
for LaTeX and HTML, but not for real programming languages.) I've
discussed it a bit with Eric on the semantic mailing list, and if I
can understand the CEDET code base it shouldn't be all that hard. But
I've banned myself from starting this until I have more time :)

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

email: address@hidden
web: www.dr-qubit.org