Well it uses the same hand technique as I explained earlier. I don't
understand why you couldn't
work around this problem.
I know now why: http://bugzilla.lyx.org/show_bug.cgi?id=5274
which is a must fix.
regards Uwe
> Well it uses the same hand technique as I explained earlier. I don't
understand why you couldn't
> work around this problem.
I know now why: http://bugzilla.lyx.org/show_bug.cgi?id=5274
which is a must fix.
regards Uwe
Uwe Stöhr wrote:
How is support for XeLaTeX?
XeTeX has not reached version 1.0 and it is in the major distributions for
only about a year now. The last months the first packages for XeTeX
appeared, but these needs to be stabilized and more are needed before XeTeX
can be used as currently
On 22/09/2008 01:00, Uwe Stöhr wrote:
Uwe Stöhr schrieb:
Anyway, I just put some code to detect changes in the ui files.
Please test.
Your patch fixes the problem. I don't understand why, but it works ;-)
Well it uses the same hand technique as I explained earlier. I don't
understand why
(I still want the TAB support from Vincent in, but this can also done
afterwards.)
There are a number of patches from Vincent floating around. Maybe time
to put them in.
Abdel.
I implemented the 4-spaces TAB stop yesterday-evening and it worked fine for
me.
I adjusted the
So from my point of view rc3 can be released.
would be nice to fix this one too
http://bugzilla.lyx.org/show_bug.cgi?id=5225
i suspect the fix is real easy, but am away on conference so can't look into it
right now...
Uwe Stöhr wrote:
(I still want the TAB support from Vincent in, but this can also done
afterwards.)
i didn't followed this issue closely - does this patch touches keyboard 'tab'
handling?
pavel
Uwe Stöhr wrote:
(I still want the TAB support from Vincent in, but this can also done
afterwards.)
i didn't followed this issue closely - does this patch touches keyboard 'tab'
handling?
pavel
I can answer this, but then I have to know what you mean by 'touching' ?
The patch inserts a tab
Vincent van Ravesteijn - TNW wrote:
(I still want the TAB support from Vincent in, but this can also done
afterwards.)
i didn't followed this issue closely - does this patch touches keyboard 'tab'
handling?
pavel
I can answer this, but then I have to know what you mean by
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
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
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
Pavel Sanda wrote:
Vincent van Ravesteijn - TNW wrote:
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
Uwe Stöhr wrote:
> > How is support for XeLaTeX?
>
> XeTeX has not reached version 1.0 and it is in the major distributions for
> only about a year now. The last months the first packages for XeTeX
> appeared, but these needs to be stabilized and more are needed before XeTeX
> can be used as
On 22/09/2008 01:00, Uwe Stöhr wrote:
Uwe Stöhr schrieb:
Anyway, I just put some code to detect changes in the ui files.
Please test.
Your patch fixes the problem. I don't understand why, but it works ;-)
Well it uses the same hand technique as I explained earlier. I don't
understand why
>> (I still want the TAB support from Vincent in, but this can also done
>> afterwards.)
>
>There are a number of patches from Vincent floating around. Maybe time
>to put them in.
>
>Abdel.
I implemented the 4-spaces TAB stop yesterday-evening and it worked fine for
me.
I adjusted the
> So from my point of view rc3 can be released.
would be nice to fix this one too
http://bugzilla.lyx.org/show_bug.cgi?id=5225
i suspect the fix is real easy, but am away on conference so can't look into it
right now...
Uwe Stöhr wrote:
> (I still want the TAB support from Vincent in, but this can also done
> afterwards.)
i didn't followed this issue closely - does this patch touches keyboard 'tab'
handling?
pavel
>Uwe Stöhr wrote:
>> (I still want the TAB support from Vincent in, but this can also done
>> afterwards.)
>
>i didn't followed this issue closely - does this patch touches keyboard 'tab'
>handling?
>
>pavel
>
I can answer this, but then I have to know what you mean by 'touching' ?
The patch
Vincent van Ravesteijn - TNW wrote:
> >> (I still want the TAB support from Vincent in, but this can also done
> >> afterwards.)
> >
> >i didn't followed this issue closely - does this patch touches keyboard 'tab'
> >handling?
> >
> >pavel
> >
>
> I can answer this, but then I have to know what
>>
>> 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
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.
>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
Pavel Sanda wrote:
Vincent van Ravesteijn - TNW wrote:
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
How is support for XeLaTeX?
XeTeX has not reached version 1.0 and it is in the major distributions for only about a year now.
The last months the first packages for XeTeX appeared, but these needs to be stabilized and more are
needed before XeTeX can be used as currently LaTeX. I'm following
What would you like to see in before rc3 is out?
As I several times complained, since 2 weeks the toolbar handling is completely
broken:
http://bugzilla.lyx.org/show_bug.cgi?id=5249
This is a showstopper since this regression to rc2 makes LyX hardly unusable.
Besides this, I'd like to have
On 21/09/2008 22:26, Uwe Stöhr wrote:
What would you like to see in before rc3 is out?
As I several times complained, since 2 weeks the toolbar handling is
completely broken:
http://bugzilla.lyx.org/show_bug.cgi?id=5249
This is a showstopper since this regression to rc2 makes LyX hardly
Abdelrazak Younes schrieb:
Aren't you exaggerating a bit? There is a simple work-around: erase the
session data.
This doesn't work. The toolbars are then still not visible. E.g. go into a formula or table and the
corresponding toolbars won't come up.
I don't understand why nobody cared
On 22/09/2008 00:06, Uwe Stöhr wrote:
Abdelrazak Younes schrieb:
Aren't you exaggerating a bit? There is a simple work-around: erase
the session data.
This doesn't work. The toolbars are then still not visible. E.g. go
into a formula or table and the corresponding toolbars won't come up.
Uwe Stöhr schrieb:
Anyway, I just put some code to detect changes in the ui files. Please
test.
Your patch fixes the problem. I don't understand why, but it works ;-)
So from my point of view rc3 can be released.
(I still want the TAB support from Vincent in, but this can also done
> How is support for XeLaTeX?
XeTeX has not reached version 1.0 and it is in the major distributions for only about a year now.
The last months the first packages for XeTeX appeared, but these needs to be stabilized and more are
needed before XeTeX can be used as currently LaTeX. I'm following
> What would you like to see in before rc3 is out?
As I several times complained, since 2 weeks the toolbar handling is completely
broken:
http://bugzilla.lyx.org/show_bug.cgi?id=5249
This is a showstopper since this regression to rc2 makes LyX hardly unusable.
Besides this, I'd like to have
On 21/09/2008 22:26, Uwe Stöhr wrote:
> What would you like to see in before rc3 is out?
As I several times complained, since 2 weeks the toolbar handling is
completely broken:
http://bugzilla.lyx.org/show_bug.cgi?id=5249
This is a showstopper since this regression to rc2 makes LyX hardly
Abdelrazak Younes schrieb:
Aren't you exaggerating a bit? There is a simple work-around: erase the
session data.
This doesn't work. The toolbars are then still not visible. E.g. go into a formula or table and the
corresponding toolbars won't come up.
I don't understand why nobody cared
On 22/09/2008 00:06, Uwe Stöhr wrote:
Abdelrazak Younes schrieb:
Aren't you exaggerating a bit? There is a simple work-around: erase
the session data.
This doesn't work. The toolbars are then still not visible. E.g. go
into a formula or table and the corresponding toolbars won't come up.
Uwe Stöhr schrieb:
Anyway, I just put some code to detect changes in the ui files. Please
test.
Your patch fixes the problem. I don't understand why, but it works ;-)
So from my point of view rc3 can be released.
(I still want the TAB support from Vincent in, but this can also done
On Fri, Sep 19, 2008 at 10:28:27PM -0400, rgheck wrote:
The problem is that there is no such thing as inset-specific binding.
Tab is bound, by site.bind, to LFUN_CELL_FORWARD. This LFUN acts
differently in different insets, or at least it can---see, e.g., the
recently much discussed
On Fri, Sep 19, 2008 at 10:28:27PM -0400, rgheck wrote:
> The problem is that there is no such thing as inset-specific binding.
> Tab is bound, by site.bind, to LFUN_CELL_FORWARD. This LFUN acts
> differently in different insets, or at least it can---see, e.g., the
> recently much discussed
Pavel Sanda wrote:
Richard Heck wrote:
By the way, what are we using now to accept completions? I mean, before
the little dropbox thingy comes up.
That's an issue we have to decide on. I have bound it to TAB locally and
it bahaves exactly like in the hardcoded case before. But of
Pavel Sanda wrote:
Richard Heck wrote:
By the way, what are we using now to accept completions? I mean,
before the little dropbox thingy comes up.
That's an issue we have to decide on. I have bound it to TAB
locally and it bahaves exactly like in the hardcoded case before.
But of
Am 19.09.2008 um 13:25 schrieb Vincent van Ravesteijn - TNW:
Pavel Sanda wrote:
Richard Heck wrote:
By the way, what are we using now to accept completions? I mean,
before the little dropbox thingy comes up.
That's an issue we have to decide on. I have bound it to TAB
locally and it
... And they can of course use the tabbing in Listings, .. If I
polish
the patch. Can you explain why tabbing in Listings and in Tables
cooperate well, while completion gets broken ?
Without looking at the code, I guess it's because completion does not
bind
to the tab key directly via a
Stefan Schimanski wrote:
Am 19.09.2008 um 13:25 schrieb Vincent van Ravesteijn - TNW:
Pavel Sanda wrote:
Richard Heck wrote:
By the way, what are we using now to accept completions? I mean,
before the little dropbox thingy comes up.
That's an issue we have to decide on. I have bound it
Vincent van Ravesteijn - TNW wrote:
... And they can of course use the tabbing in Listings, .. If I
polish
the patch. Can you explain why tabbing in Listings and in Tables
cooperate well, while completion gets broken ?
Without looking at the code, I guess it's because
Pavel Sanda wrote:
> Richard Heck wrote:
> >>> By the way, what are we using now to accept completions? I mean, before
> >>> the little dropbox thingy comes up.
> >>
> >> That's an issue we have to decide on. I have bound it to TAB locally and
> >> it bahaves exactly like in the hardcoded case
>Pavel Sanda wrote:
>> Richard Heck wrote:
>> >>> By the way, what are we using now to accept completions? I mean,
>> >>> before the little dropbox thingy comes up.
>> >>
>> >> That's an issue we have to decide on. I have bound it to TAB
>> >> locally and it bahaves exactly like in the
Am 19.09.2008 um 13:25 schrieb Vincent van Ravesteijn - TNW:
Pavel Sanda wrote:
Richard Heck wrote:
By the way, what are we using now to accept completions? I mean,
before the little dropbox thingy comes up.
That's an issue we have to decide on. I have bound it to TAB
locally and it
>>
>> ... And they can of course use the tabbing in Listings, .. If I
polish
>> the patch. Can you explain why tabbing in Listings and in Tables
>> cooperate well, while completion gets broken ?
>
> Without looking at the code, I guess it's because completion does not
bind
> to the tab key
Stefan Schimanski wrote:
Am 19.09.2008 um 13:25 schrieb Vincent van Ravesteijn - TNW:
Pavel Sanda wrote:
Richard Heck wrote:
By the way, what are we using now to accept completions? I mean,
before the little dropbox thingy comes up.
That's an issue we have to decide on. I have bound it
Vincent van Ravesteijn - TNW wrote:
... And they can of course use the tabbing in Listings, .. If I
polish
the patch. Can you explain why tabbing in Listings and in Tables
cooperate well, while completion gets broken ?
Without looking at the code, I guess it's because
José Matos wrote:
We are approaching now of the time to have a new release. I am satisfied with
a 3/4 weeks period between releases as the testing by users that usually just
take a released version is not too far from the trunk head.
Asking a user to test if a problem remains one or two weeks
Am 18.09.2008 um 16:28 schrieb rgheck:
José Matos wrote:
We are approaching now of the time to have a new release. I am
satisfied with a 3/4 weeks period between releases as the testing
by users that usually just take a released version is not too far
from the trunk head.
Asking a user
Stefan Schimanski wrote:
Am 18.09.2008 um 16:28 schrieb rgheck:
José Matos wrote:
We are approaching now of the time to have a new release. I am
satisfied with a 3/4 weeks period between releases as the testing by
users that usually just take a released version is not too far from
the
t. If you press space after the end of the macro, you are in the
first cell. I do that without thinking about that every time. Btw.,
\frac\alpha has the same behaviour. It has nothing to do with
macros...
Yes, that is correct. OK.
(Tab takes me to the second argument, in fact.) I guess I
Stefan Schimanski wrote:
t. If you press space after the end of the macro, you are in the
first cell. I do that without thinking about that every time. Btw.,
\frac\alpha has the same behaviour. It has nothing to do with macros...
Yes, that is correct. OK.
(Tab takes me to the second
Richard Heck wrote:
By the way, what are we using now to accept completions? I mean, before
the little dropbox thingy comes up.
That's an issue we have to decide on. I have bound it to TAB locally and
it bahaves exactly like in the hardcoded case before. But of course I lost
TAB in the
José Matos wrote:
We are approaching now of the time to have a new release. I am satisfied with
a 3/4 weeks period between releases as the testing by users that usually just
take a released version is not too far from the trunk head.
Asking a user to test if a problem remains one or two weeks
Am 18.09.2008 um 16:28 schrieb rgheck:
José Matos wrote:
We are approaching now of the time to have a new release. I am
satisfied with a 3/4 weeks period between releases as the testing
by users that usually just take a released version is not too far
from the trunk head.
Asking a user
Stefan Schimanski wrote:
Am 18.09.2008 um 16:28 schrieb rgheck:
José Matos wrote:
We are approaching now of the time to have a new release. I am
satisfied with a 3/4 weeks period between releases as the testing by
users that usually just take a released version is not too far from
the
t. If you press space after the end of the macro, you are in the
first cell. I do that without thinking about that every time. Btw.,
\frac\alpha has the same behaviour. It has nothing to do with
macros...
Yes, that is correct. OK.
(Tab takes me to the second argument, in fact.) I guess I
Stefan Schimanski wrote:
t. If you press space after the end of the macro, you are in the
first cell. I do that without thinking about that every time. Btw.,
\frac\alpha has the same behaviour. It has nothing to do with macros...
Yes, that is correct. OK.
(Tab takes me to the second
Richard Heck wrote:
>>> By the way, what are we using now to accept completions? I mean, before
>>> the little dropbox thingy comes up.
>>
>> That's an issue we have to decide on. I have bound it to TAB locally and
>> it bahaves exactly like in the hardcoded case before. But of course I lost
>>
We are approaching now of the time to have a new release. I am satisfied with
a 3/4 weeks period between releases as the testing by users that usually just
take a released version is not too far from the trunk head.
Asking a user to test if a problem remains one or two weeks later on the new
José Matos wrote:
We are approaching now of the time to have a new release. I am satisfied
with a 3/4 weeks period between releases as the testing by users that
usually just take a released version is not too far from the trunk head.
Asking a user to test if a problem remains one or two
On Wed, Sep 17, 2008 at 11:36 AM, José Matos [EMAIL PROTECTED] wrote:
We are approaching now of the time to have a new release. I am satisfied
with
a 3/4 weeks period between releases as the testing by users that usually
just
take a released version is not too far from the trunk head.
Bennett Helm wrote:
A couple quick and easy changes for mac.bind and the lyxeditor script in the
Mac bundle should go in (attached). (Note that cmdg is the Mac default for
search again.)
its in.
pavel
On Wed, Sep 17, 2008 at 5:29 PM, Pavel Sanda [EMAIL PROTECTED] wrote:
Bennett Helm wrote:
A couple quick and easy changes for mac.bind and the lyxeditor script in
the
Mac bundle should go in (attached). (Note that cmdg is the Mac default
for
search again.)
its in.
Thanks!
Bennett
On Wednesday 17 September 2008 18:13:30 Neal Becker wrote:
How is support for XeLaTeX?
Absent? :-)
--
José Abílio
We are approaching now of the time to have a new release. I am satisfied with
a 3/4 weeks period between releases as the testing by users that usually just
take a released version is not too far from the trunk head.
Asking a user to test if a problem remains one or two weeks later on the new
José Matos wrote:
> We are approaching now of the time to have a new release. I am satisfied
> with a 3/4 weeks period between releases as the testing by users that
> usually just take a released version is not too far from the trunk head.
>
> Asking a user to test if a problem remains one or
On Wed, Sep 17, 2008 at 11:36 AM, José Matos <[EMAIL PROTECTED]> wrote:
> We are approaching now of the time to have a new release. I am satisfied
> with
> a 3/4 weeks period between releases as the testing by users that usually
> just
> take a released version is not too far from the trunk head.
Bennett Helm wrote:
> A couple quick and easy changes for mac.bind and the lyxeditor script in the
> Mac bundle should go in (attached). (Note that g is the Mac default for
> "search again".)
its in.
pavel
On Wed, Sep 17, 2008 at 5:29 PM, Pavel Sanda <[EMAIL PROTECTED]> wrote:
> Bennett Helm wrote:
> > A couple quick and easy changes for mac.bind and the lyxeditor script in
> the
> > Mac bundle should go in (attached). (Note that g is the Mac default
> for
> > "search again".)
>
> its in.
Thanks!
On Wednesday 17 September 2008 18:13:30 Neal Becker wrote:
> How is support for XeLaTeX?
Absent? :-)
--
José Abílio
74 matches
Mail list logo
