Pavel Sanda wrote:
Richard Heck wrote:
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.
to me that is what we wanted to achive, no? primary function in table should be
LFUN_CELL_FORWARD so we are backward compatible. if somebody dislike it, he can
unbind it. the rest of the edited text would be complete lfun. and may be we
can add patch from Vincent to have tab in listings.
I guess I saw this the other way around: BOTH completion AND next-cell
should work in tables. Otherwise, you, the user, have to remember that
completion has no binding in tables. This is very unintuitive, and it is
especially nasty with mathed (which, for me, is the only place I use
completion), since next-cell also works there in arrays, etc.
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.
to sum up by priority i would vote for this binding list:
1. tab bound to LFUN_CELL_FORWARD
2. tab bound to some new LFUN_INDENT_IN_LISTINGS
3. tab bound to complete
i really would like to see 1 & 3 solved before rc3.
2 & multiple binding in GUI would be nice but imho shouldn't be release stopper.
Well, my version is essentially upside down of your version. ;-) But
adding listings is trivial, if the LFUN exists.
rh
