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: [EMAIL PROTECTED] web: www.dr-qubit.org _______________________________________________ gnu-emacs-sources mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnu-emacs-sources
