On 05/03/2012 04:51 PM, Allen Barker wrote:
On 05/03/2012 04:18 AM, Allen Barker wrote:
I recently downloaded the SVN code (revision 40920) in order to
look into a bug involving the ordering of listings parameters.
This is bug #5203: http://www.lyx.org/trac/ticket/5203
(BTW, even on the unmodified SVN code almost every time I hit
View > View Source I get a crash and a SIGSEGV error window pops
up.)
The complaint in #5203 is that the ordering of Listings parameters
is changed to be sorted, although ordering is actually significant
to the Listings package.
The reason for this seems to be that the routines in
InsetListingsParams.h and InsetListingsParams.cpp used a map
to save the key=value pairs, but STL maps always sort their keys.
I've attached modified versions of the two files. It's really a
mindless substitution of a pair of vectors (one for keys, one for
values) in place of the map. It seems to work, based on limited
testing.
My C++ is rusty, and I don't know much about the Lyx code, but
someone might want to use this as a starting point for the
official fix.
When the attached changes are applied the lists always stay in
order, both as displayed and as written to Latex. The parameter
settings from the main menu are applied before the additional
settings from the advanced menu.
There is also a fix to bug #8144. Duplicated keys have underscores
appended to them to keep them distinct. There was an attempt to
validate a repeated key (they have trailing underscores) without
first trimming the raw value. (Giving a key=value assignment for
a key already set from the main menu counts as a repeated key.)
This still does not address the issues of the semantics of
setting parameter values from the main menu versus setting them in
the advanced menu (which is mentioned in #5203). Parameters set
from the main window are placed at the beginning of the list in
the Latex output.
There is also an attempt to grab parameters set from the advanced
page which are settable from the main page. In that case, the
string disappears in the advanced list when "Apply" is pressed.
For example, basicstyle=\small will be eaten and the result
will be reflected on the main menu. Yet basicstyle=\itshape
will not be recognized and removed and it will stomp the
font settings from the main menu. (Try setting the font to tiny
from the main menu and then setting basicstyle=\color{red} from
the advanced menu and view each result.)
There seem to be some problems, as basicstyle=\Large is eaten but
the main menu then shows Larger as the size. Huge occasionally
appears as an option, but not always. Also, the disappeared
items are sometimes "still there" and appear in the Latex output.
They then cannot be removed.
On further investigation, this parameter-display modification is
being done in the file frontends/qt4/GuiListings.cpp,
in the function GuiListings::updateContents()
The parameters which are given special processing (because at
least some options can be set from the main menu) are as follows.
The right column is when the special processing is done.
language if it is an option in gui
float always
numbers always
stepnumber always
numberstyle always
firstline always
lastline always
basicstyle equals style+size or size+style, either can be empty
breaklines always
showspaces always
showstringspaces always
tabsize always
extendedchars always
The processing goes something like the following.
The "Apply" button sets the saved parameter list to the list
generated by the construct_params() function. This function
generates a list of options from the main menu GUI settings,
and then appends all the "extra" settings from the advanced
menu.
The updateContent() function gets that saved parameter list
and processes it line-by-line. If special processing is
detected and done then 1) the main page GUI is reset,
2) the key=value string is modified to any new values, and
3) the key=value string is deleted from the list which will
appear in the advanced menu box (and which the
construct_params function will use next time).
A simple mod is to count the number of lines which
construct_params creates from the main GUI (but not the extra
ones from the advanced menu). Then the display-suppression
function that updateContent() effectively applies can be only
applied to settings which the main GUI generated in the first
place. Once the count is reached then one can either 1) stop
setting strings empty after processing, or 2) just break from
the processing loop.
The effect of both is that the main GUI selections are applied
first, and the extra, advanced settings are always kept and
allowed to override those settings. In option 1 the main GUI
items would always be updated to the last setting on the full
key=value list which were recognized for processing (including
on the advanced list). In option 2, just breaking from the
loop, the main GUI and the advanced settings are essentially
independent. They are both kept, and do not affect each other;
the main ones are applied first and the advanced ones follow
and can override.
Option 2, at least, seems to work in the code (after the earlier
fixes keeping items in order). As long as nothing important
depends on the main menu listings settings matching the actual
listings output it should presumably be OK...
I spoke too soon. File saves depend on the "suppression mechanism"
to keep main menu settings from appearing on the advanced list
when the file is reopened. That would require a larger change.
Since items from the main menu always appear first there could
be problems in overriding the settings of some other parameters
(like language=Python, which does multiple things).
The easiest thing to do would seem to be just to turn off the
matching and "disappearing" function and trust that the advanced
users know that some of their advanced settings may override the
settings from the main page. Then all the settings can just be
generated and placed in the Latex, and the users get exactly what
they asked for (hopefully intentionally).
Most of the main menu commands would work fine with the above,
but basicstyle is more problematic since multiple properties are
set from that one command. The user may not know that setting
basicstyle=\itshape will stomp the font size and font family.
Yet that is already the case; the current version does not
recognize and remove an itshape setting. This might be less of a
problem if font shape and color were also settable from the main
menu, since non-advanced users would not be forced to set those
properties from the advanced menu. Yet most users will not want
to globally modify those properties anyway.
One possibility after turning off the disappearing function would
be to add another, non-editable window to the advanced page
showing the commands which will be generated by the settings on
the main page. Then the users would at least have more warning
that they might be stomping something there (and they could see
what values to repeat in their own settings).
#5203 suggests displaying everything in the one window (including
the main menu key=value parameter settings) and then searching and
modifying those commands when main menu options are selected. The
whole search-and-modify thing brings up various issues, however,
as to how it should be done.
