Am 08.09.2008 um 00:44 schrieb Pavel Sanda:
Stefan Schimanski wrote:
still want to introduce some option for accepting completion after
first
tab,
so the current state is not the final one imho.
Adding another LFUN for this behaviour should be easy. So you could
bind
that to TAB instead
Stefan Schimanski wrote:
>> still want to introduce some option for accepting completion after first
>> tab,
>> so the current state is not the final one imho.
>
> Adding another LFUN for this behaviour should be easy. So you could bind
> that to TAB instead of the "normal" iterative completion.
Am 08.09.2008 um 00:30 schrieb Pavel Sanda:
Stefan Schimanski wrote:
I am not sure I like this fix either. This way the TAB key silently
changes
its meaning when the completion becomes visible. If one waits long
enough
for the inline completion to appear, suddenly the TAB in tables
does n
Stefan Schimanski wrote:
> I am not sure I like this fix either. This way the TAB key silently changes
> its meaning when the completion becomes visible. If one waits long enough
> for the inline completion to appear, suddenly the TAB in tables does not
> jump to the next cell anymore...
incide
Am 07.09.2008 um 18:01 schrieb Pavel Sanda:
Vincent van Ravesteijn - TNW wrote:
We should only determine the correct modifiers for the if-
statement. I propose:
if ((completer_->inlineVisible() || completer_->popupVisible())
{
eat the tab key before anyone else can do something with it;
I am not sure I like this fix either. This way the TAB key silently
changes its meaning when the completion becomes visible. If one waits
long enough for the inline completion to appear, suddenly the TAB in
tables does not jump to the next cell anymore...
Stefan
Am 07.09.2008 um 18:01 schr
Vincent van Ravesteijn - TNW wrote:
> We should only determine the correct modifiers for the if-statement. I
> propose:
>
> if ((completer_->inlineVisible() || completer_->popupVisible())
> {
> eat the tab key before anyone else can do something with it;
> }
i've commited something slig
>> of course we shouldn't remove it. but the point is to do it in a way
>> that both tab completion and tab navigation works. i think its possible,
>> but not through completer_->popupVisible() && ev->key() == Qt::Key_Tab.
>
>I fully agree, but until this is fixed, the TAB behaviour of LyX 1.5 need
>> of course we shouldn't remove it. but the point is to do it in a way
>> that both tab completion and tab navigation works. i think its possible,
>> but not through completer_->popupVisible() && ev->key() == Qt::Key_Tab.
>
>I fully agree, but until this is fixed, the TAB behaviour of LyX 1.5 need
Uwe Stöhr wrote:
> >> Sorry but this is the rule: When you add a new feature build it so that it
> >> doesn't introduce a regression except this was a discussed decision.
> >
> > it is not fair to be taught about the rules in the thread which start with
> > defective commit that was not discussed a
>> Sorry but this is the rule: When you add a new feature build it so that it
>> doesn't introduce a regression except this was a discussed decision.
>
> it is not fair to be taught about the rules in the thread which start with
> defective commit that was not discussed at all, in fact even announ
Uwe Stöhr wrote:
>>> Now we have no regressions
>> well, you removed the basic task of completion for a few glitches
>> in other parts of code.
>
> Sorry but this is the rule: When you add a new feature build it so that it
> doesn't introduce a regression except this was a discussed decision.
it
Vincent van Ravesteijn - TNW wrote:
> >what happens for you with this recipe? :
> >1. newfile, ctrl+m
> >2. hit two keys \a
> >3. immediately (before popup appears) hit tab
> >
> >(before this patch 'acute' gets completed on first hit
> >and accepted on second hit). now this stops work, so completi
Pavel Sanda schrieb:
what happens for you with this recipe? :
1. newfile, ctrl+m
2. hit two keys \a
3. immediately (before popup appears) hit tab
(before this patch 'acute' gets completed on first hit
and accepted on second hit). now this stops work, so completion
completion
I see your point,
>what happens for you with this recipe? :
>1. newfile, ctrl+m
>2. hit two keys \a
>3. immediately (before popup appears) hit tab
>
>(before this patch 'acute' gets completed on first hit
>and accepted on second hit). now this stops work, so completion
>completion
>
>pavel
This solves your probl
Uwe Stöhr wrote:
>> this patch is wrong and causes completion stop working when tab is used
>> without popup. please revert.
>
> I can see no problem. I use TAB without popup.
i can see the problem even from the code :)
what happens for you with this recipe? :
1. newfile, ctrl+m
2. hit two keys \
Pavel Sanda schrieb:
this patch is wrong and causes completion stop working when tab is used
without popup. please revert.
I can see no problem. I use TAB without popup.
Note that the code as it was before introduced two regressions: tabs in math
and tables.
Now we have no regressions, but o
[EMAIL PROTECTED] wrote:
> Author: uwestoehr
> Date: Sat Sep 6 23:10:59 2008
> New Revision: 26320
>
> URL: http://www.lyx.org/trac/changeset/26320
> Log:
> GuiWorkArea.cpp: allow to navigate in tables with the Tab key, patch by
> Vincent
>
> Modified:
> lyx-devel/trunk/src/frontends/qt4/Gu
18 matches
Mail list logo
