Bo Peng wrote:
Sorry Bo, it is been a bit late, but I wait for all the changes for
the source file settles.
It can go in if you change .find() to contains(), and trim() suffix to
avoid problem with '?style ' etc (if it has not been trimmed before
key is passed).
All these controls and string
On 5/30/07, Abdelrazak Younes [EMAIL PROTECTED] wrote:
Bo Peng wrote:
Sorry Bo, it is been a bit late, but I wait for all the changes for
the source file settles.
It can go in if you change .find() to contains(), and trim() suffix to
avoid problem with '?style ' etc (if it has not been
+1
I can move it to frontend after the release, if nobody objects.
After 1.5.0 please. Time would be better spent on real bugs now.
Bo
Otherwise, '?something ' will not match anything.
I guess, a trim is already applied. I updated the code for the situations '? something' and attached the patch. However, It does not cover the situations '?some thing'.
I used trim (), but since the string is already trimmed, rtrim() is
Bo Peng wrote:
Sorry Bo, it is been a bit late, but I wait for all the changes for
the source file settles.
It can go in if you change .find() to contains(), and trim() suffix to
avoid problem with '?style ' etc (if it has not been trimmed before
key is passed).
All these controls and string
On 5/30/07, Abdelrazak Younes <[EMAIL PROTECTED]> wrote:
Bo Peng wrote:
>> Sorry Bo, it is been a bit late, but I wait for all the changes for
>> the source file settles.
>
> It can go in if you change .find() to contains(), and trim() suffix to
> avoid problem with '?style ' etc (if it has not
>
> +1
I can move it to frontend after the release, if nobody objects.
After 1.5.0 please. Time would be better spent on real bugs now.
Bo
Otherwise, '?something ' will not match anything.
I guess, a trim is already applied. I updated the code for the situations '? something' and attached the patch. However, It does not cover the situations '?some thing'.
I used trim (), but since the string is already trimmed, rtrim() is
Attached is a patch for a small feature that Bo asked for. It simply
filters InsetListingsParams when the text in the corresponding dialog
is entered as ?string .
Sorry Bo, it is been a bit late, but I wait for all the changes for
the source file settles.
cheers
Ugras
Index:
Sorry Bo, it is been a bit late, but I wait for all the changes for
the source file settles.
It can go in if you change .find() to contains(), and trim() suffix to
avoid problem with '?style ' etc (if it has not been trimmed before
key is passed).
Thanks.
Bo
Attached is a patch for a small feature that Bo asked for. It simply
filters InsetListingsParams when the text in the corresponding dialog
is entered as ? .
Sorry Bo, it is been a bit late, but I wait for all the changes for
the source file settles.
cheers
Ugras
Index:
Sorry Bo, it is been a bit late, but I wait for all the changes for
the source file settles.
It can go in if you change .find() to contains(), and trim() suffix to
avoid problem with '?style ' etc (if it has not been trimmed before
key is passed).
Thanks.
Bo
Abdelrazak Younes wrote:
The attached updated patch works the same and goes farther in the
cleanup. I got an implicit (private) OK from Bo. Jurgen?
OK.
Jürgen
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
The attached updated patch works the same and goes farther in the
cleanup. I got an implicit (private) OK from Bo. Jurgen?
OK.
OK, thanks, I've committed a further cleanup version where ListingsParam
is a full blown class which do its own
Abdelrazak Younes wrote:
> The attached updated patch works the same and goes farther in the
> cleanup. I got an implicit (private) OK from Bo. Jurgen?
OK.
Jürgen
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
The attached updated patch works the same and goes farther in the
cleanup. I got an implicit (private) OK from Bo. Jurgen?
OK.
OK, thanks, I've committed a further cleanup version where ListingsParam
is a full blown class which do its own
Bo Peng wrote:
Hi Bo,
1. table[idx].name is char * so != is better because no conversion
would be needed.
... and then you'll be comparing pointers, which is probably not what you
want... afaict the original patch was correct in this respect.
Regards
A/
PS: incidentally this may work
5. I would appreciate it you can also implement
?xx == all parameters that contains xx. That is to say, ?placement
would show floatplacement. style would show all style related
parameters. You can also consider xx == all parameters that
prefixIs(xx), and other parameters that contains(xx).
I
Ozgur Ugras BARAN wrote:
5. I would appreciate it you can also implement
?xx == all parameters that contains xx. That is to say, ?placement
would show floatplacement. style would show all style related
parameters. You can also consider xx == all parameters that
prefixIs(xx), and other
variable that we compare with empty string is of type const char, not
string.. A possible way of doing it would be:
!string(listings_param_table[idx].name).empty()
But it is more difficult to read, IMHO.
Ugras
Use string::empty() instead.
Abdel.
Ozgur Ugras BARAN wrote:
variable that we compare with empty string is of type const char, not
string.. A possible way of doing it would be:
!string(listings_param_table[idx].name).empty()
Ah... OK, I didn't get the thing.
Why don't you use string in the first place (in listings_param_table)
Abdelrazak Younes wrote:
- char const * hint;
+ string hint;
Can you make it a docstring instead?
Jürgen
Abdelrazak Younes wrote:
Ozgur Ugras BARAN wrote:
variable that we compare with empty string is of type const char, not
string.. A possible way of doing it would be:
!string(listings_param_table[idx].name).empty()
Ah... OK, I didn't get the thing.
Why don't you use string in the first place
On 5/26/07, Jürgen Spitzmüller [EMAIL PROTECTED] wrote:
Abdelrazak Younes wrote:
-char const * hint;
+string hint;
Can you make it a docstring instead?
In the good old days, string is considered as expensive compared to
char *, and now you want to use docstring?
I agree to change it to
Yes. You could as well use:
if (listings_param_table[idx].name[0])
This is what lyx usually uses, and what I will do if I am awake enough
not to use == .
Cheers,
Bo
Ah... OK, I didn't get the thing.
Why don't you use string in the first place (in listings_param_table) ?
But it is more difficult to read, IMHO.
Yes. You could as well use:
if (listings_param_table[idx].name[0])
:D I guess, I remember this from hilarious web site how to write an
Indeed, I am agree with Alfredo on this issue. Therefore I have
attached another patch which uses string() for comparison. Use
whichever you think is best.
+ string suffix(name,1);
+ string pars;
+ for(pariter = parlist.begin(); pariter !=
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
- char const * hint;
+ string hint;
Can you make it a docstring instead?
OK.
Abdel.
Do you like if I apply other suggestions of the web site for lyx development? :)
Sure, just do not bring up the 'char const' issue. :-)
Cheers,
Bo
Bo Peng wrote:
On 5/26/07, Jürgen Spitzmüller
[EMAIL PROTECTED] wrote:
Abdelrazak Younes wrote:
-char const * hint;
+string hint;
Can you make it a docstring instead?
In the good old days, string is considered as expensive compared to
char *,
Memory and CPU wise the overhead is minimal.
Bo Peng wrote:
In the good old days,
laudatio temporis acti ...
string is considered as expensive compared to
char *, and now you want to use docstring?
saves us a few conversions.
I agree to change it to docstring. :-)
Fine.
Jürgen
Ah, yes I forgot contains.. I'll fix it.
Shall I also make the conversion to docstring for every string and
char* I use in parValidator::parValidator?
ugras
On 5/26/07, Bo Peng [EMAIL PROTECTED] wrote:
Indeed, I am agree with Alfredo on this issue. Therefore I have
attached another patch
Ozgur Ugras BARAN wrote:
Ah, yes I forgot contains.. I'll fix it.
Shall I also make the conversion to docstring for every string and
char* I use in parValidator::parValidator?
I am doing the conversion right now. Will post in a minute.
Abdel.
ugras
On 5/26/07, Bo Peng [EMAIL PROTECTED]
Abdelrazak Younes wrote:
Ozgur Ugras BARAN wrote:
Ah, yes I forgot contains.. I'll fix it.
Shall I also make the conversion to docstring for every string and
char* I use in parValidator::parValidator?
I am doing the conversion right now. Will post in a minute.
Here is it. The bonus is that
Abdelrazak Younes wrote:
+ { emptylines, , false, ALL, , from_ascii(Expect a number
with an optional * before it) },
please mark this translatable as well:
+ { emptylines, , false, ALL, , _(Expect a number with an
optional * before it) },
Jürgen
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
+ { emptylines, , false, ALL, , from_ascii(Expect a number
with an optional * before it) },
please mark this translatable as well:
+ { emptylines, , false, ALL, , _(Expect a number with an
optional * before it) },
Already done
+docstring empty_hint;
+docstring style_hint = _(Use \\footnotesize, \\small, \\itshape, \\ttfamily or
something like that);
+docstring frame_hint = _(none, leftline, topline, bottomline, lines, single,
shadowbox or subset of trblTRBL);
+docstring frameround_hint =_(Enter four letters
Abdelrazak Younes wrote:
Already done ;-)
merci beaucoup :-)
Jürgen
Bo Peng wrote:
+docstring empty_hint;
+docstring style_hint = _(Use \\footnotesize, \\small, \\itshape,
\\ttfamily or something like that);
+docstring frame_hint = _(none, leftline, topline, bottomline, lines,
single, shadowbox or subset of trblTRBL);
+docstring frameround_hint =_(Enter
Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
Ozgur Ugras BARAN wrote:
Ah, yes I forgot contains.. I'll fix it.
Shall I also make the conversion to docstring for every string and
char* I use in parValidator::parValidator?
I am doing the conversion right now. Will post in a minute.
Ozgur Ugras BARAN wrote:
Attached patch sorts listings inset params, and hence solves bug 3639.
Please somebody review and apply the patch.
I could also sort the listings_param_table[] entries manually, but I
find this way easier (and more guaranteed).
I went one step further and used a map
Abdelrazak Younes wrote:
Ozgur Ugras BARAN wrote:
Attached patch sorts listings inset params, and hence solves bug 3639.
Please somebody review and apply the patch.
I could also sort the listings_param_table[] entries manually, but I
find this way easier (and more guaranteed).
I went one
On 5/26/07, Abdelrazak Younes [EMAIL PROTECTED] wrote:
Abdelrazak Younes wrote:
Ozgur Ugras BARAN wrote:
Attached patch sorts listings inset params, and hence solves bug 3639.
Please somebody review and apply the patch.
I could also sort the listings_param_table[] entries manually, but I
Bo Peng wrote:
On 5/26/07, Abdelrazak Younes [EMAIL PROTECTED] wrote:
Abdelrazak Younes wrote:
Ozgur Ugras BARAN wrote:
Attached patch sorts listings inset params, and hence solves bug
3639.
Please somebody review and apply the patch.
I could also sort the listings_param_table[] entries
It is cleaner,
I prefer {} initialization to a bunch of assignments. I like neither
static bool firsttime, nor the fact that stylehint is repeated several
times.
saves code for the searching
maybe.
and the sorting is automatic.
Why is that? You mean things in a map is ordered by
Bo Peng wrote:
It is cleaner,
I prefer {} initialization to a bunch of assignments. I like neither
static bool firsttime, nor the fact that stylehint is repeated several
times.
This is just cosmetic, I could have just put the initialisation code in
the ParValidator constructor.
saves
On 5/26/07, Abdelrazak Younes [EMAIL PROTECTED] wrote:
Bo Peng wrote:
It is cleaner,
I prefer {} initialization to a bunch of assignments. I like neither
static bool firsttime, nor the fact that stylehint is repeated several
times.
This is just cosmetic, I could have just put the
Bo Peng wrote:
On 5/26/07, Abdelrazak Younes [EMAIL PROTECTED]
wrote:
Bo Peng wrote:
It is cleaner,
I prefer {} initialization to a bunch of assignments. I like neither
static bool firsttime, nor the fact that stylehint is repeated several
times.
This is just cosmetic, I could have just
I forgot to say that we need only one ParValidator.
The constructor of parValidator, curently, check against this
structure and throw if fail. You will have to change this to something
like
parValidator globalValidator;
globalValidator.validate(key, value);
Currently, I have
Bo Peng wrote:
I forgot to say that we need only one ParValidator.
The constructor of parValidator, curently, check against this
structure and throw if fail. You will have to change this to something
like
parValidator globalValidator;
globalValidator.validate(key, value);
Currently, I have
Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
Ozgur Ugras BARAN wrote:
Attached patch sorts listings inset params, and hence solves bug
3639. Please somebody review and apply the patch.
I could also sort the listings_param_table[] entries manually, but I
find this way easier (and more
Bo Peng wrote:
Hi Bo,
>
> 1. table[idx].name is char * so != "" is better because no conversion
> would be needed.
... and then you'll be comparing pointers, which is probably not what you
want... afaict the original patch was correct in this respect.
Regards
A/
PS: incidentally this may
5. I would appreciate it you can also implement
?xx ==> all parameters that contains xx. That is to say, ?placement
would show floatplacement. style would show all style related
parameters. You can also consider xx ==> all parameters that
prefixIs(xx), and other parameters that contains(xx).
Ozgur Ugras BARAN wrote:
5. I would appreciate it you can also implement
?xx ==> all parameters that contains xx. That is to say, ?placement
would show floatplacement. style would show all style related
parameters. You can also consider xx ==> all parameters that
prefixIs(xx), and other
variable that we compare with empty string is of type const char, not
string.. A possible way of doing it would be:
!string(listings_param_table[idx].name).empty()
But it is more difficult to read, IMHO.
Ugras
Use string::empty() instead.
Abdel.
Ozgur Ugras BARAN wrote:
variable that we compare with empty string is of type const char, not
string.. A possible way of doing it would be:
!string(listings_param_table[idx].name).empty()
Ah... OK, I didn't get the thing.
Why don't you use string in the first place (in listings_param_table)
Abdelrazak Younes wrote:
> - char const * hint;
> + string hint;
Can you make it a docstring instead?
Jürgen
Abdelrazak Younes wrote:
Ozgur Ugras BARAN wrote:
variable that we compare with empty string is of type const char, not
string.. A possible way of doing it would be:
!string(listings_param_table[idx].name).empty()
Ah... OK, I didn't get the thing.
Why don't you use string in the first place
On 5/26/07, Jürgen Spitzmüller <[EMAIL PROTECTED]> wrote:
Abdelrazak Younes wrote:
> -char const * hint;
> +string hint;
Can you make it a docstring instead?
In the good old days, string is considered as expensive compared to
char *, and now you want to use docstring?
I agree to change it to
Yes. You could as well use:
if (listings_param_table[idx].name[0])
This is what lyx usually uses, and what I will do if I am awake enough
not to use == "".
Cheers,
Bo
Ah... OK, I didn't get the thing.
Why don't you use string in the first place (in listings_param_table) ?
> But it is more difficult to read, IMHO.
Yes. You could as well use:
if (listings_param_table[idx].name[0])
:D I guess, I remember this from hilarious web site "how to write an
Indeed, I am agree with Alfredo on this issue. Therefore I have
attached another patch which uses string() for comparison. Use
whichever you think is best.
+ string suffix(name,1);
+ string pars;
+ for(pariter = parlist.begin(); pariter !=
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
- char const * hint;
+ string hint;
Can you make it a docstring instead?
OK.
Abdel.
Do you like if I apply other suggestions of the web site for lyx development? :)
Sure, just do not bring up the 'char const' issue. :-)
Cheers,
Bo
Bo Peng wrote:
On 5/26/07, Jürgen Spitzmüller
<[EMAIL PROTECTED]> wrote:
Abdelrazak Younes wrote:
> -char const * hint;
> +string hint;
Can you make it a docstring instead?
In the good old days, string is considered as expensive compared to
char *,
Memory and CPU wise the overhead is
Bo Peng wrote:
> In the good old days,
laudatio temporis acti ...
> string is considered as expensive compared to
> char *, and now you want to use docstring?
saves us a few conversions.
> I agree to change it to docstring. :-)
Fine.
Jürgen
Ah, yes I forgot contains.. I'll fix it.
Shall I also make the conversion to docstring for every string and
char* I use in parValidator::parValidator?
ugras
On 5/26/07, Bo Peng <[EMAIL PROTECTED]> wrote:
> Indeed, I am agree with Alfredo on this issue. Therefore I have
> attached another
Ozgur Ugras BARAN wrote:
Ah, yes I forgot contains.. I'll fix it.
Shall I also make the conversion to docstring for every string and
char* I use in parValidator::parValidator?
I am doing the conversion right now. Will post in a minute.
Abdel.
ugras
On 5/26/07, Bo Peng <[EMAIL PROTECTED]>
Abdelrazak Younes wrote:
Ozgur Ugras BARAN wrote:
Ah, yes I forgot contains.. I'll fix it.
Shall I also make the conversion to docstring for every string and
char* I use in parValidator::parValidator?
I am doing the conversion right now. Will post in a minute.
Here is it. The bonus is that
Abdelrazak Younes wrote:
> + { "emptylines", "", false, ALL, "", from_ascii("Expect a number
> with an optional * before it") },
please mark this translatable as well:
+ { "emptylines", "", false, ALL, "", _("Expect a number with an
optional * before it") },
Jürgen
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
+ { "emptylines", "", false, ALL, "", from_ascii("Expect a number
with an optional * before it") },
please mark this translatable as well:
+ { "emptylines", "", false, ALL, "", _("Expect a number with an
optional * before it")
+docstring empty_hint;
+docstring style_hint = _("Use \\footnotesize, \\small, \\itshape, \\ttfamily or
something like that");
+docstring frame_hint = _("none, leftline, topline, bottomline, lines, single,
shadowbox or subset of trblTRBL");
+docstring frameround_hint =_("Enter four letters
Abdelrazak Younes wrote:
> Already done ;-)
merci beaucoup :-)
Jürgen
Bo Peng wrote:
+docstring empty_hint;
+docstring style_hint = _("Use \\footnotesize, \\small, \\itshape,
\\ttfamily or something like that");
+docstring frame_hint = _("none, leftline, topline, bottomline, lines,
single, shadowbox or subset of trblTRBL");
+docstring frameround_hint =
Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
Ozgur Ugras BARAN wrote:
Ah, yes I forgot contains.. I'll fix it.
Shall I also make the conversion to docstring for every string and
char* I use in parValidator::parValidator?
I am doing the conversion right now. Will post in a minute.
Ozgur Ugras BARAN wrote:
Attached patch sorts listings inset params, and hence solves bug 3639.
Please somebody review and apply the patch.
I could also sort the listings_param_table[] entries manually, but I
find this way easier (and more guaranteed).
I went one step further and used a map
Abdelrazak Younes wrote:
Ozgur Ugras BARAN wrote:
Attached patch sorts listings inset params, and hence solves bug 3639.
Please somebody review and apply the patch.
I could also sort the listings_param_table[] entries manually, but I
find this way easier (and more guaranteed).
I went one
On 5/26/07, Abdelrazak Younes <[EMAIL PROTECTED]> wrote:
Abdelrazak Younes wrote:
> Ozgur Ugras BARAN wrote:
>> Attached patch sorts listings inset params, and hence solves bug 3639.
>> Please somebody review and apply the patch.
>>
>> I could also sort the listings_param_table[] entries
Bo Peng wrote:
On 5/26/07, Abdelrazak Younes <[EMAIL PROTECTED]> wrote:
Abdelrazak Younes wrote:
> Ozgur Ugras BARAN wrote:
>> Attached patch sorts listings inset params, and hence solves bug
3639.
>> Please somebody review and apply the patch.
>>
>> I could also sort the
It is cleaner,
I prefer {} initialization to a bunch of assignments. I like neither
static bool firsttime, nor the fact that stylehint is repeated several
times.
saves code for the searching
maybe.
and the sorting is automatic.
Why is that? You mean things in a map is ordered by
Bo Peng wrote:
It is cleaner,
I prefer {} initialization to a bunch of assignments. I like neither
static bool firsttime, nor the fact that stylehint is repeated several
times.
This is just cosmetic, I could have just put the initialisation code in
the ParValidator constructor.
saves
On 5/26/07, Abdelrazak Younes <[EMAIL PROTECTED]> wrote:
Bo Peng wrote:
>> It is cleaner,
>
> I prefer {} initialization to a bunch of assignments. I like neither
> static bool firsttime, nor the fact that stylehint is repeated several
> times.
This is just cosmetic, I could have just put the
Bo Peng wrote:
On 5/26/07, Abdelrazak Younes <[EMAIL PROTECTED]>
wrote:
Bo Peng wrote:
>> It is cleaner,
>
> I prefer {} initialization to a bunch of assignments. I like neither
> static bool firsttime, nor the fact that stylehint is repeated several
> times.
This is just cosmetic, I could
I forgot to say that we need only one ParValidator.
The constructor of parValidator, curently, check against this
structure and throw if fail. You will have to change this to something
like
parValidator globalValidator;
globalValidator.validate(key, value);
Currently, I have
Bo Peng wrote:
I forgot to say that we need only one ParValidator.
The constructor of parValidator, curently, check against this
structure and throw if fail. You will have to change this to something
like
parValidator globalValidator;
globalValidator.validate(key, value);
Currently, I have
Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
Ozgur Ugras BARAN wrote:
Attached patch sorts listings inset params, and hence solves bug
3639. Please somebody review and apply the patch.
I could also sort the listings_param_table[] entries manually, but I
find this way easier (and more
Attached patch sorts listings inset params, and hence solves bug 3639.
Please somebody review and apply the patch.
I could also sort the listings_param_table[] entries manually, but I find
this way easier (and more guaranteed).
regards,
ugras
Index: insets/InsetListingsParams.cpp
On 5/25/07, Ozgur Ugras BARAN [EMAIL PROTECTED] wrote:
Attached patch sorts listings inset params, and hence solves bug 3639.
Please somebody review and apply the patch.
1. table[idx].name is char * so != is better because no conversion
would be needed.
2. you used both std::string and
On 5/25/07, Bo Peng [EMAIL PROTECTED] wrote:
On 5/25/07, Ozgur Ugras BARAN [EMAIL PROTECTED] wrote:
Attached patch sorts listings inset params, and hence solves bug 3639.
Please somebody review and apply the patch.
1. table[idx].name is char * so != is better because no conversion
would be
Attached patch sorts listings inset params, and hence solves bug 3639.
Please somebody review and apply the patch.
I could also sort the listings_param_table[] entries manually, but I find
this way easier (and more guaranteed).
regards,
ugras
Index: insets/InsetListingsParams.cpp
On 5/25/07, Ozgur Ugras BARAN <[EMAIL PROTECTED]> wrote:
Attached patch sorts listings inset params, and hence solves bug 3639.
Please somebody review and apply the patch.
1. table[idx].name is char * so != "" is better because no conversion
would be needed.
2. you used both std::string and
On 5/25/07, Bo Peng <[EMAIL PROTECTED]> wrote:
On 5/25/07, Ozgur Ugras BARAN <[EMAIL PROTECTED]> wrote:
> Attached patch sorts listings inset params, and hence solves bug 3639.
> Please somebody review and apply the patch.
1. table[idx].name is char * so != "" is better because no conversion
92 matches
Mail list logo
