Re: [PATCH] Allow parameters to bypass InsetListingsParams validation.
Bo Peng wrote: I think the proper way to solve any option would have been to outsource the option definitions in a text file which is easily upgradable. But then 1.5.0 will not be usable for listings 2009... Adding a backdoor is always safer. :-) First strict validation, and then a work-around in case the validation is no longer correct. This seems complicated. How about relaxing the validation then, so the user isn't _forced_ to enter valid input? Then there is no need at all for a workaround with @-signs or whatever. Or any other workaround. You can still provide a strong clue that something might be wrong. For example, all invalid parameters could be higlighted with red bold. Put the cursor on a bad parameter, and a status field could light up with a descriptive message like 'foobar' is an invalid/unsupported parameter or You need a positive number here. Helge Hafting
Re: [PATCH] Allow parameters to bypass InsetListingsParams validation.
Bo Peng wrote: I think the proper way to solve any option would have been to outsource the option definitions in a text file which is easily upgradable. But then 1.5.0 will not be usable for listings 2009... Adding a backdoor is always safer. :-) First strict validation, and then a work-around in case the validation is no longer correct. This seems complicated. How about relaxing the validation then, so the user isn't _forced_ to enter valid input? Then there is no need at all for a workaround with @-signs or whatever. Or any other workaround. You can still provide a strong clue that something might be wrong. For example, all invalid parameters could be higlighted with red bold. Put the cursor on a bad parameter, and a status field could light up with a descriptive message like " 'foobar' is an invalid/unsupported parameter" or "You need a positive number here." Helge Hafting
Re: [PATCH] Allow parameters to bypass InsetListingsParams validation.
On Friday 08 June 2007 04:29:16 Bo Peng wrote: The validation mechanism of InsetListingsParams is great but is not flexible to handle unrecognized parameters introduced, e.g., by a new version of the listings. The attached patch allows users to input arbitrary parameters by prefixing it with a '@' sign. @ will be removed in latex output, but reserved in lyx files. Please test. Bo Just one note, could you document this behaviour somewhere (probably near the listing documentation)? Else this will be equivalent to black magic. :-) -- José Abílio
Re: [PATCH] Allow parameters to bypass InsetListingsParams validation.
Just one note, could you document this behaviour somewhere (probably near the listing documentation)? Else this will be equivalent to black magic. :-) This approach has been ditched. Another patch, which adds 'pass validation' check boxes, is proposed. Cheers, Bo
Re: [PATCH] Allow parameters to bypass InsetListingsParams validation.
On Monday 11 June 2007 15:26:01 Bo Peng wrote: This approach has been ditched. Another patch, which adds 'pass validation' check boxes, is proposed. I only read this later and MUA does not have any function to recall sent messages. ;-) Cheers, Bo -- José Abílio
Re: [PATCH] Allow parameters to bypass InsetListingsParams validation.
On Friday 08 June 2007 04:29:16 Bo Peng wrote: > The validation mechanism of InsetListingsParams is great but is not > flexible to handle unrecognized parameters introduced, e.g., by a new > version of the listings. > > The attached patch allows users to input arbitrary parameters by > prefixing it with a '@' sign. @ will be removed in latex output, but > reserved in lyx files. > > Please test. > Bo Just one note, could you document this behaviour somewhere (probably near the listing documentation)? Else this will be equivalent to black magic. :-) -- José Abílio
Re: [PATCH] Allow parameters to bypass InsetListingsParams validation.
Just one note, could you document this behaviour somewhere (probably near the listing documentation)? Else this will be equivalent to black magic. :-) This approach has been ditched. Another patch, which adds 'pass validation' check boxes, is proposed. Cheers, Bo
Re: [PATCH] Allow parameters to bypass InsetListingsParams validation.
On Monday 11 June 2007 15:26:01 Bo Peng wrote: > This approach has been ditched. Another patch, which adds 'pass > validation' check boxes, is proposed. I only read this later and MUA does not have any function to recall sent messages. ;-) > Cheers, > Bo -- José Abílio
Re: [PATCH] Allow parameters to bypass InsetListingsParams validation.
I see no comment on this patch. Because this is within my field, I will commit tomorrow if there is no objection. No objection, so it is in. Cheers, Bo
Re: [PATCH] Allow parameters to bypass InsetListingsParams validation.
Bo Peng wrote: I see no comment on this patch. Because this is within my field, I will commit tomorrow if there is no objection. No objection, so it is in. I think the proper way to solve any option would have been to outsource the option definitions in a text file which is easily upgradable. Abdel.
Re: [PATCH] Allow parameters to bypass InsetListingsParams validation.
I see no comment on this patch. Because this is within my field, I will commit tomorrow if there is no objection. No objection, so it is in. Cheers, Bo
Re: [PATCH] Allow parameters to bypass InsetListingsParams validation.
Bo Peng wrote: I see no comment on this patch. Because this is within my field, I will commit tomorrow if there is no objection. No objection, so it is in. I think the proper way to solve any option would have been to outsource the option definitions in a text file which is easily upgradable. Abdel.
Re: [PATCH] Allow parameters to bypass InsetListingsParams validation.
The attached patch allows users to input arbitrary parameters by prefixing it with a '@' sign. @ will be removed in latex output, but reserved in lyx files. I see no comment on this patch. Because this is within my field, I will commit tomorrow if there is no objection. Cheers, Bo
Re: [PATCH] Allow parameters to bypass InsetListingsParams validation.
The attached patch allows users to input arbitrary parameters by prefixing it with a '@' sign. @ will be removed in latex output, but reserved in lyx files. I see no comment on this patch. Because this is within my field, I will commit tomorrow if there is no objection. Cheers, Bo
[PATCH] Allow parameters to bypass InsetListingsParams validation.
The validation mechanism of InsetListingsParams is great but is not
flexible to handle unrecognized parameters introduced, e.g., by a new
version of the listings.
The attached patch allows users to input arbitrary parameters by
prefixing it with a '@' sign. @ will be removed in latex output, but
reserved in lyx files.
Please test.
Bo
Index: src/insets/InsetListingsParams.h
===
--- src/insets/InsetListingsParams.h (revision 18709)
+++ src/insets/InsetListingsParams.h (working copy)
@@ -35,7 +35,9 @@
void read(Lexer );
/// valid parameter string
- std::string params(std::string const sep=,) const;
+ /// \param valid_key whether or not strip leading @, which is
+ /// used to bypass validator
+ std::string params(std::string const sep=,, bool valid_key=false) const;
/// add key=value to params_
void addParam(std::string const key, std::string const value);
Index: src/insets/InsetListings.cpp
===
--- src/insets/InsetListings.cpp (revision 18709)
+++ src/insets/InsetListings.cpp (working copy)
@@ -131,7 +131,7 @@
int InsetListings::latex(Buffer const buf, odocstream os,
OutputParams const runparams) const
{
- string param_string = params().params();
+ string param_string = params().params(,, true);
// NOTE: I use {} to quote text, which is an experimental feature
// of the listings package (see page 25 of the manual)
int lines = 0;
Index: src/insets/InsetListingsParams.cpp
===
--- src/insets/InsetListingsParams.cpp (revision 18709)
+++ src/insets/InsetListingsParams.cpp (working copy)
@@ -35,6 +35,7 @@
using support::bformat;
using support::trim;
+using support::ltrim;
using support::rtrim;
using support::subst;
using support::isStrInt;
@@ -123,7 +124,7 @@
switch (type_) {
case ALL:
- if (par2.empty() !onoff_) {
+ if (par2.empty() !onoff_ hint_ != _(Bypass validation)) {
if (!hint_.empty())
return hint_;
else
@@ -301,6 +302,12 @@
/// options copied from page 26 of listings manual
// FIXME: add default parameters ... (which is not used now)
+
+ // special ListingsParam returned for parameters starting with @
+ // which helps them bypass validation.
+ all_params_[@] =
+ ListingsParam(, false, ALL, , _(Bypass validation));
+
all_params_[float] =
ListingsParam(false, true, SUBSETOF, *tbph, empty_hint);
all_params_[floatplacement] =
@@ -620,6 +627,10 @@
from_utf8(suffix), from_utf8(param_names)));
}
+ // do not validate keys starting with @
+ if (prefixIs(name, @))
+ return all_params_.find(@)-second;
+
// locate name in parameter table
ListingsParams::const_iterator it = all_params_.find(name);
if (it != all_params_.end())
@@ -636,7 +647,7 @@
}
}
if (matching_names.empty())
- throw invalidParam(bformat(_(Unknown listing parameter name: %1$s),
+ throw invalidParam(bformat(_(Unknown listing parameter name: %1$s. Prefix this parameter with @ to bypass validation.),
from_utf8(name)));
else
throw invalidParam(bformat(_(Parameters starting with '%1$s': %2$s),
@@ -683,7 +694,7 @@
}
-string InsetListingsParams::params(string const sep) const
+string InsetListingsParams::params(string const sep, bool valid_key) const
{
string par;
for (mapstring, string::const_iterator it = params_.begin();
@@ -691,10 +702,16 @@
if (!par.empty())
par += sep;
// key=value,key=value1 is stored in params_ as key=value,key_=value1.
+ // @key=value is returned as key=value
+ string key = rtrim(it-first, _);
+ // remove prefix @ which is used to forcefully pass parameters that
+ // can not pass validation
+ if (valid_key)
+ key = ltrim(key, @);
if (it-second.empty())
- par += rtrim(it-first, _);
+ par += key;
else
- par += rtrim(it-first, _) + '=' + it-second;
+ par += key + '=' + it-second;
}
return par;
}
[PATCH] Allow parameters to bypass InsetListingsParams validation.
The validation mechanism of InsetListingsParams is great but is not
flexible to handle unrecognized parameters introduced, e.g., by a new
version of the listings.
The attached patch allows users to input arbitrary parameters by
prefixing it with a '@' sign. @ will be removed in latex output, but
reserved in lyx files.
Please test.
Bo
Index: src/insets/InsetListingsParams.h
===
--- src/insets/InsetListingsParams.h (revision 18709)
+++ src/insets/InsetListingsParams.h (working copy)
@@ -35,7 +35,9 @@
void read(Lexer &);
/// valid parameter string
- std::string params(std::string const & sep=",") const;
+ /// \param valid_key whether or not strip leading @, which is
+ /// used to bypass validator
+ std::string params(std::string const & sep=",", bool valid_key=false) const;
/// add key=value to params_
void addParam(std::string const & key, std::string const & value);
Index: src/insets/InsetListings.cpp
===
--- src/insets/InsetListings.cpp (revision 18709)
+++ src/insets/InsetListings.cpp (working copy)
@@ -131,7 +131,7 @@
int InsetListings::latex(Buffer const & buf, odocstream & os,
OutputParams const & runparams) const
{
- string param_string = params().params();
+ string param_string = params().params(",", true);
// NOTE: I use {} to quote text, which is an experimental feature
// of the listings package (see page 25 of the manual)
int lines = 0;
Index: src/insets/InsetListingsParams.cpp
===
--- src/insets/InsetListingsParams.cpp (revision 18709)
+++ src/insets/InsetListingsParams.cpp (working copy)
@@ -35,6 +35,7 @@
using support::bformat;
using support::trim;
+using support::ltrim;
using support::rtrim;
using support::subst;
using support::isStrInt;
@@ -123,7 +124,7 @@
switch (type_) {
case ALL:
- if (par2.empty() && !onoff_) {
+ if (par2.empty() && !onoff_ && hint_ != _("Bypass validation")) {
if (!hint_.empty())
return hint_;
else
@@ -301,6 +302,12 @@
/// options copied from page 26 of listings manual
// FIXME: add default parameters ... (which is not used now)
+
+ // special ListingsParam returned for parameters starting with @
+ // which helps them bypass validation.
+ all_params_["@"] =
+ ListingsParam("", false, ALL, "", _("Bypass validation"));
+
all_params_["float"] =
ListingsParam("false", true, SUBSETOF, "*tbph", empty_hint);
all_params_["floatplacement"] =
@@ -620,6 +627,10 @@
from_utf8(suffix), from_utf8(param_names)));
}
+ // do not validate keys starting with @
+ if (prefixIs(name, "@"))
+ return all_params_.find("@")->second;
+
// locate name in parameter table
ListingsParams::const_iterator it = all_params_.find(name);
if (it != all_params_.end())
@@ -636,7 +647,7 @@
}
}
if (matching_names.empty())
- throw invalidParam(bformat(_("Unknown listing parameter name: %1$s"),
+ throw invalidParam(bformat(_("Unknown listing parameter name: %1$s. Prefix this parameter with @ to bypass validation."),
from_utf8(name)));
else
throw invalidParam(bformat(_("Parameters starting with '%1$s': %2$s"),
@@ -683,7 +694,7 @@
}
-string InsetListingsParams::params(string const & sep) const
+string InsetListingsParams::params(string const & sep, bool valid_key) const
{
string par;
for (map::const_iterator it = params_.begin();
@@ -691,10 +702,16 @@
if (!par.empty())
par += sep;
// key=value,key=value1 is stored in params_ as key=value,key_=value1.
+ // @key=value is returned as key=value
+ string key = rtrim(it->first, "_");
+ // remove prefix @ which is used to forcefully pass parameters that
+ // can not pass validation
+ if (valid_key)
+ key = ltrim(key, "@");
if (it->second.empty())
- par += rtrim(it->first, "_");
+ par += key;
else
- par += rtrim(it->first, "_") + '=' + it->second;
+ par += key + '=' + it->second;
}
return par;
}
