Vincent van Ravesteijn - TNW wrote: > >> I can answer this, but then I have to know what you mean by > 'touching' ? > > > >i meant if keyboard handling of 'tab' is changed somehow by this patch. > > This patch, which is not committed yet, will introduce no further > changements to key handling. It only adds a new function when Tab is > pressed in a Listing environment.
are we talking about the patch in "Tabbing in listings" thread from 7th Sep, or is there some newer one floating around? > The recent change of the Tab key handling was a reversion of the > 'chaotic' implementation of the Tab-key binding for autocompletion. As > pointed out before, this introduced a regression in the sense that a > very natural and already existing use of the Tab-key for moving between > cells in a table was removed. while i agree that the previous implementation was not right, by chaotic i mean something different than to be buggy. there is a need to systematically solve the tab handling. chaos is when one issue is fixed and another just pops up because of it. once we publicly released rc2, 1.6 started to have its own history and you can't look only how 1.5.x used to be. its clear from the feedback that many people started using 1.6 too. >So if you mean what you just said, you > should be happy that the Tab-key now behaves as it did in 1.5.x. now you are joking, right? :) one of major 1.6 features is disabled and even developers have to ask what to bind to get it work again. i hope i make more clear what i mean by what i said :D > My patch doesn't change the Tab key handling any further, it only adds > something _if_ the Tab key is bound to LFUN_CELL_FORWARD and friend. i see. if i understand it correctly you solved the tab problem here by making table LFUN_CELL_FORWARD lfun to be polymorphic and do also something different than its name reveal. i don't like it much, since lfun should do what its name refers to. but i know - we don't have working machinery for correct solution yet... pavel
