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 actual
>
> +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
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
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
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: insets/InsetListingsParam
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 v
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
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 gu
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
p
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
parValidator(key)
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
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 in
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 co
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 keyword?
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[
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
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 st
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:
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
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 =_("Ente
Abdelrazak Younes wrote:
> Already done ;-)
merci beaucoup :-)
Jürgen
+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 (
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") },
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
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
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]>
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
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
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 minima
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
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
- char const * hint;
+ string hint;
Can you make it a docstring instead?
OK.
Abdel.
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 != parlist.end();
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
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
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
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
Abdelrazak Younes wrote:
> - char const * hint;
> + string hint;
Can you make it a docstring instead?
Jürgen
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)
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:
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 paramet
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
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
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
wou
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 st
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
==
46 matches
Mail list logo
