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. > 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. yes. this was the original implementation and i dont want to mess with it. > 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. > By the way, "complete" seems wrong. It doesn't fit the pattern of the > others. I'd suggest "completion-suggest". i dont have any opinion about it, imho this naming was done on purpose by Stefan. pavel
