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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
16 matches
Mail list logo
