Pavel Sanda wrote:
Richard Heck wrote:
The attached patch is a start on this. It does work, in the sense that
you can have both completion-accept and cell-forward bound to Tab, and
this works in tables.
"completion-accept" is added from me and works in a different way then
"complete"
which was bound to tab before. i'm not sure, but most people probably want
"complete" one.
Yes, complete suggests a completion, whereas completion-accept accepts it.
I think you probably do NOT want Tab bound to complete. I did that first,
and then Tab never works if you are at the end of a word in a table
(because LFUN_COMPLETE will be enabled). Of course, we can bind
LFUN_COMPLETE to something else....
wouldn't binding tab to the table movement _on_the_first_place_in_lfuns_list
solve this? completion-accept was pushed mainly because i use completion
in a bit different fashion and don't want to force anybody on it.
But then whatever completion thing is bound to Tab will never work in
tables---and that, of course, includes math tables---except in the last
cell, because LFUN_CELL_FORWARD will always be enabled. But I guess I
see why you'd want to do complete. Correct me if I'm wrong, but the
first time you hit "Tab", then, you'd get either the inline thing or, if
there were more than one option, the little popup. And IF you got the
inline thing, then you could hit "Tab" again to actually complete it?
But, as I said, this ends up causing its own problems.
How does this work
Obviously, the main thing is to have the framework to allow this kind of
thing. Figuring out the exact bindings is a different matter. I guess
the first question is which LFUNs we want to be bound.
By the way, "complete" seems wrong. It doesn't fit the pattern of the
others. I'd suggest "completion-suggest".
rh
