Re: Bug in listings inset (Lyx 1.5.6, OS X)
Daniel Lohmann wrote: Actually, I had searched bugzilla and found bug 4884 before asking on the list, but to me it does not really describe the problem of sorting. Now after re-reading the entry I see that it is somewhat related, but that is not really obvious. Yes, the problem in bugzilla is a different one, but the cause of both problems is the strange parameter handling of the listings inset: In the .lyx file the parameters are stored in one string in LaTeX syntax. The same string is used for communication with the dialog. The intermediate representation in memory is sometimes a vector, and sometimes a std::map. Because of the latter the order of the parameters is not guaranteed at all, and because of the parsing of the LaTeX string all sorts of other problems can happen. Both problems would be fixed by a sane parameter handling that would not store all parameters in one string, but one parameter after the other in the .lyx file. Preservation of order would then be easy to implement as well. If you prefer I will add my suggestions there, otherwise I would open a new bug (with a reference to 4884). Do as you like, I don't really care. There are good reasons for both alternatives. Georg
Re: Bug in listings inset (Lyx 1.5.6, OS X)
On 29.08.2008, at 20:12, Georg Baum wrote: Both problems would be fixed by a sane parameter handling that would not store all parameters in one string, but one parameter after the other in the .lyx file. Preservation of order would then be easy to implement as well. If you prefer I will add my suggestions there, otherwise I would open a new bug (with a reference to 4884). Do as you like, I don't really care. There are good reasons for both alternatives. Thanks Georg, I have opened a new bug and added crossref comments to 4484 and 5203 http://bugzilla.lyx.org/show_bug.cgi?id=5203 Daniel
Re: Bug in listings inset (Lyx 1.5.6, OS X)
Daniel Lohmann wrote: Actually, I had searched bugzilla and found bug 4884 before asking on the list, but to me it does not really describe the problem of sorting. Now after re-reading the entry I see that it is somewhat related, but that is not really obvious. Yes, the problem in bugzilla is a different one, but the cause of both problems is the strange parameter handling of the listings inset: In the .lyx file the parameters are stored in one string in LaTeX syntax. The same string is used for communication with the dialog. The intermediate representation in memory is sometimes a vector, and sometimes a std::map. Because of the latter the order of the parameters is not guaranteed at all, and because of the parsing of the LaTeX string all sorts of other problems can happen. Both problems would be fixed by a sane parameter handling that would not store all parameters in one string, but one parameter after the other in the .lyx file. Preservation of order would then be easy to implement as well. If you prefer I will add my suggestions there, otherwise I would open a new bug (with a reference to 4884). Do as you like, I don't really care. There are good reasons for both alternatives. Georg
Re: Bug in listings inset (Lyx 1.5.6, OS X)
On 29.08.2008, at 20:12, Georg Baum wrote: Both problems would be fixed by a sane parameter handling that would not store all parameters in one string, but one parameter after the other in the .lyx file. Preservation of order would then be easy to implement as well. If you prefer I will add my suggestions there, otherwise I would open a new bug (with a reference to 4884). Do as you like, I don't really care. There are good reasons for both alternatives. Thanks Georg, I have opened a new bug and added crossref comments to 4484 and 5203 http://bugzilla.lyx.org/show_bug.cgi?id=5203 Daniel
Re: Bug in listings inset (Lyx 1.5.6, OS X)
Daniel Lohmann wrote: > Actually, I had searched bugzilla and found bug 4884 before asking on > the list, but to me it does not really describe the problem of > sorting. Now after re-reading the entry I see that it is somewhat > related, but that is not really obvious. Yes, the problem in bugzilla is a different one, but the cause of both problems is the strange parameter handling of the listings inset: In the .lyx file the parameters are stored in one string in LaTeX syntax. The same string is used for communication with the dialog. The intermediate representation in memory is sometimes a vector, and sometimes a std::map. Because of the latter the order of the parameters is not guaranteed at all, and because of the "parsing" of the LaTeX string all sorts of other problems can happen. Both problems would be fixed by a sane parameter handling that would not store all parameters in one string, but one parameter after the other in the .lyx file. Preservation of order would then be easy to implement as well. > If you prefer I will add my suggestions there, otherwise I would open > a new bug (with a reference to 4884). Do as you like, I don't really care. There are good reasons for both alternatives. Georg
Re: Bug in listings inset (Lyx 1.5.6, OS X)
On 29.08.2008, at 20:12, Georg Baum wrote: Both problems would be fixed by a sane parameter handling that would not store all parameters in one string, but one parameter after the other in the .lyx file. Preservation of order would then be easy to implement as well. If you prefer I will add my suggestions there, otherwise I would open a new bug (with a reference to 4884). Do as you like, I don't really care. There are good reasons for both alternatives. Thanks Georg, I have opened a new bug and added crossref comments to 4484 and 5203 http://bugzilla.lyx.org/show_bug.cgi?id=5203 Daniel
Bug in listings inset (Lyx 1.5.6, OS X)
Hi,
I just discovered a feature of the listings inset that actually
should be considered as a bug: Additional options given on the
advanced page are implicitly sorted alphabetically. However, if using
listing styles, the order of options is relevant. Consider the
following example:
In my preamble, I have defined a custom listings style:
\lstdefinestyle{acstyle}{
... % many, many settings
mathescape=true
}
Now I want to apply this style, but set mathescape to false. So I type
in the Advanced settings of the inset:
style=acstyle
mathescape=false
However, when I press Apply, LyX immediately sorts the options
alphabetically, which results in:
mathescape=false
style=acstyle
And hence, the mathescape=true from the style wins :-(
IMHO this problem also shows a more general issue: When combining main
settings and advanced settings, the order of application remains
unclear. It seems that the same sorting rules apply here, which might
as well yield surprising effects.
The best possible solution for this problem I can imagine would be:
(a) to not sort options, but respect their order; and
(b) to reflect all main settings on the Advanced page as well.
The idea behind (b) works as follows: When I activate an option in the
Main Settings, its string representation is automatically added to
the end of the advanced settings; when I deactivate it, it is removed.
When I manually add an option in the advanced settings for which a
checkbox exists in the main settings, the checkbox is activated.
Thereby, *all* settings become visible and editable on the Advanced
page, on which they can (because of (a)) be ordered in whatever order
the user prefers.
However, just implementing (a) would already be a suitable workaround
for most cases.
Daniel
Re: Bug in listings inset (Lyx 1.5.6, OS X)
Daniel Lohmann wrote: Hi, I just discovered a feature of the listings inset that actually should be considered as a bug: Additional options given on the advanced page are implicitly sorted alphabetically. However, if using listing styles, the order of options is relevant. Consider the following example: Yep, this is a known bug, caused by the manner how the parameters are stored: http://bugzilla.lyx.org/show_bug.cgi?id=4884 Maybe you just add your suggestions there? Georg
Re: Bug in listings inset (Lyx 1.5.6, OS X)
On 27.08.2008, at 19:59, Georg Baum wrote: Daniel Lohmann wrote: Hi, I just discovered a feature of the listings inset that actually should be considered as a bug: Additional options given on the advanced page are implicitly sorted alphabetically. However, if using listing styles, the order of options is relevant. Consider the following example: Yep, this is a known bug, caused by the manner how the parameters are stored: http://bugzilla.lyx.org/show_bug.cgi?id=4884 Maybe you just add your suggestions there? Thanks Georg, Are you sure? Actually, I had searched bugzilla and found bug 4884 before asking on the list, but to me it does not really describe the problem of sorting. Now after re-reading the entry I see that it is somewhat related, but that is not really obvious. If you prefer I will add my suggestions there, otherwise I would open a new bug (with a reference to 4884). Daniel
Bug in listings inset (Lyx 1.5.6, OS X)
Hi,
I just discovered a feature of the listings inset that actually
should be considered as a bug: Additional options given on the
advanced page are implicitly sorted alphabetically. However, if using
listing styles, the order of options is relevant. Consider the
following example:
In my preamble, I have defined a custom listings style:
\lstdefinestyle{acstyle}{
... % many, many settings
mathescape=true
}
Now I want to apply this style, but set mathescape to false. So I type
in the Advanced settings of the inset:
style=acstyle
mathescape=false
However, when I press Apply, LyX immediately sorts the options
alphabetically, which results in:
mathescape=false
style=acstyle
And hence, the mathescape=true from the style wins :-(
IMHO this problem also shows a more general issue: When combining main
settings and advanced settings, the order of application remains
unclear. It seems that the same sorting rules apply here, which might
as well yield surprising effects.
The best possible solution for this problem I can imagine would be:
(a) to not sort options, but respect their order; and
(b) to reflect all main settings on the Advanced page as well.
The idea behind (b) works as follows: When I activate an option in the
Main Settings, its string representation is automatically added to
the end of the advanced settings; when I deactivate it, it is removed.
When I manually add an option in the advanced settings for which a
checkbox exists in the main settings, the checkbox is activated.
Thereby, *all* settings become visible and editable on the Advanced
page, on which they can (because of (a)) be ordered in whatever order
the user prefers.
However, just implementing (a) would already be a suitable workaround
for most cases.
Daniel
Re: Bug in listings inset (Lyx 1.5.6, OS X)
Daniel Lohmann wrote: Hi, I just discovered a feature of the listings inset that actually should be considered as a bug: Additional options given on the advanced page are implicitly sorted alphabetically. However, if using listing styles, the order of options is relevant. Consider the following example: Yep, this is a known bug, caused by the manner how the parameters are stored: http://bugzilla.lyx.org/show_bug.cgi?id=4884 Maybe you just add your suggestions there? Georg
Re: Bug in listings inset (Lyx 1.5.6, OS X)
On 27.08.2008, at 19:59, Georg Baum wrote: Daniel Lohmann wrote: Hi, I just discovered a feature of the listings inset that actually should be considered as a bug: Additional options given on the advanced page are implicitly sorted alphabetically. However, if using listing styles, the order of options is relevant. Consider the following example: Yep, this is a known bug, caused by the manner how the parameters are stored: http://bugzilla.lyx.org/show_bug.cgi?id=4884 Maybe you just add your suggestions there? Thanks Georg, Are you sure? Actually, I had searched bugzilla and found bug 4884 before asking on the list, but to me it does not really describe the problem of sorting. Now after re-reading the entry I see that it is somewhat related, but that is not really obvious. If you prefer I will add my suggestions there, otherwise I would open a new bug (with a reference to 4884). Daniel
Bug in listings inset (Lyx 1.5.6, OS X)
Hi,
I just discovered a "feature" of the listings inset that actually
should be considered as a bug: Additional options given on the
advanced page are implicitly sorted alphabetically. However, if using
listing styles, the order of options is relevant. Consider the
following example:
In my preamble, I have defined a custom listings style:
\lstdefinestyle{acstyle}{
... % many, many settings
mathescape=true
}
Now I want to apply this style, but set mathescape to false. So I type
in the "Advanced" settings of the inset:
style=acstyle
mathescape=false
However, when I press "Apply", LyX immediately sorts the options
alphabetically, which results in:
mathescape=false
style=acstyle
And hence, the mathescape=true from the style "wins" :-(
IMHO this problem also shows a more general issue: When combining main
settings and advanced settings, the order of application remains
unclear. It seems that the same sorting rules apply here, which might
as well yield surprising effects.
The best possible solution for this problem I can imagine would be:
(a) to not sort options, but respect their order; and
(b) to reflect all main settings on the "Advanced" page as well.
The idea behind (b) works as follows: When I activate an option in the
"Main Settings", its string representation is automatically added to
the end of the advanced settings; when I deactivate it, it is removed.
When I manually add an option in the advanced settings for which a
checkbox exists in the main settings, the checkbox is activated.
Thereby, *all* settings become visible and editable on the "Advanced"
page, on which they can (because of (a)) be ordered in whatever order
the user prefers.
However, just implementing (a) would already be a suitable workaround
for most cases.
Daniel
Re: Bug in listings inset (Lyx 1.5.6, OS X)
Daniel Lohmann wrote: > Hi, > > I just discovered a "feature" of the listings inset that actually > should be considered as a bug: Additional options given on the > advanced page are implicitly sorted alphabetically. However, if using > listing styles, the order of options is relevant. Consider the > following example: Yep, this is a known bug, caused by the manner how the parameters are stored: http://bugzilla.lyx.org/show_bug.cgi?id=4884 Maybe you just add your suggestions there? Georg
Re: Bug in listings inset (Lyx 1.5.6, OS X)
On 27.08.2008, at 19:59, Georg Baum wrote: Daniel Lohmann wrote: Hi, I just discovered a "feature" of the listings inset that actually should be considered as a bug: Additional options given on the advanced page are implicitly sorted alphabetically. However, if using listing styles, the order of options is relevant. Consider the following example: Yep, this is a known bug, caused by the manner how the parameters are stored: http://bugzilla.lyx.org/show_bug.cgi?id=4884 Maybe you just add your suggestions there? Thanks Georg, Are you sure? Actually, I had searched bugzilla and found bug 4884 before asking on the list, but to me it does not really describe the problem of sorting. Now after re-reading the entry I see that it is somewhat related, but that is not really obvious. If you prefer I will add my suggestions there, otherwise I would open a new bug (with a reference to 4884). Daniel
