Le 19/10/2016 à 15:09, Enrico Forestieri a écrit :
Just checked and discovered that my building script has a --disable-warnigs
set as an unmodifiable read-only variable ;-)
No warnings, no trouble :)
Why do you disable them, BTW? The build is quite clean these days (some
warnings are disabled by hand in autoconf).
Look, I was being deliberately provocatory but did not want to start
a flame war about that. Anyway, the strategy above will fail when
--disable-warnings is used.
I understand, and I am not trying a flame ware either. Actually, I do
not really know what is the right way to handle all these hull types.
For example, for what reason is the list here different from the list in
InsetMathHull::display()?
Because that list contains environments that are themselves nested in
outer environments and are redundant for the check in question.
This check is about whether the outer environment will be in display
mode. For example, "alignedat" can also be used in inline mode.
However, this last observation makes me aware that maybe I shouldn't
distinguish between display and inline modes, as math constructs for
which ulem fails can also appear in inline mode. So, either all math
insets are treated the same way, or inline ones should be inspected
to check for dangerous enviroments. Either way, this discussion is
going to be moot, as all cases have to be considered and I will
have to spend some more time on this :(
I do not know whether we can manage to create this handful of math hull
properties that cover most switch()es we may have, but it would give
better semantics to our code. Rather than « I spend 20 minutes looking
at all cases, this is the list in this case ».
The best virtue of these lengthy switches is to entice to think about
ways to avoid them...
JMarc
