On Wed, Oct 19, 2016 at 02:38:24PM +0200, Jean-Marc Lasgouttes wrote:
> 
> I do get warnings with default compiler switches (which include -Wall here).

Just checked and discovered that my building script has a --disable-warnigs
set as an unmodifiable read-only variable ;-)

> I guess it is a fight between source fundamentalists and warning
> fundamentalists, then.

I guess you are right.

> The issue is not only about fundamentalism, it is also about what happens
> when one introduces a new hullType. How do you find out what should be
> changed and where?

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 agree though that the list is becoming lengthy. If it happens that we are
> often special-casing a special group oh hull types, then it is probably a
> good idea to create a new athod to give a name to this particular group of
> hulls.

That would be a good idea, but see below.

> 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 :(

-- 
Enrico

Reply via email to