>> >> 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. >> The patch inserts a tab into the Listing environment if the user presses >> Tab. That's how I found out that the autocompletion did something >> undemocratic to the handling of the Tab key, which lead to your frustrations >> and to new LFUNs. I basically use LFUN_CELL_FORWARD and LFUN_CELL_BACKWARD >> for handling the Tab key, in silent expectation of the implementation of >> multiple LFUN binding. > >i will look on this part of patch later. > > to sum up my pov - its not good to chaotically change key handling for each > release we make. the completion 'tab' removal was premature since we have no > real fix for normal users of rc2 now and we need need some systematic solution > for this. > > releasing now means: rc2 has its own binding of tab, rc3 has its own and you > have to invent how to get back to the old behaviour, rc4 will again have > different system so you have to find your ways again. i would prefer that > user won't even recognize we changed something under the hood and the tab > works similarly as before. 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. 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. 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. > up to Jose, what he decides. > > pavel Vincent
