@DavidCarlisle I guess: I'm going to sort out the final xparse stuff just before that, then we will be in a position to go for the colour updates safely
@DavidCarlisle and @JosephWright would you say that \cs_new:Npn \my_TF_true:w \fi: \use_ii:nn #1 #2 { \fi: #1 } is less robust than \cs_new:Npn \my_TF_true:w \fi: \use_ii:nn { \fi: \use_i:nn } (and could you think of a case where this is actually making a difference)?
@Skillmonlikestopanswers.xyz more joseph than me these days I can't think of a case where it will make a real difference so I can't say which is more robust but there are bound to be edge cases I haven't thought about:-)
@DavidCarlisle perhaps I should ask Bruno, he's really quick with finding edge cases.
@DavidCarlisle Well, the second version is as robust as \exp_after:wN \use_ii:nnn \fi:, so if in doubt I'd choose that one, but if the first version is equally robust I'd choose that one as it's faster.
@PauloCereda I had an account on an AIX cluster for a couple of years. But I don't recall many differences. Although it was super fast for the time. And all the cluster machine names were characters from Shakespeare. :)
@cis @UlrikeFischer answered already in a comment. Also highlightrow/.list/.expanded=\List works (It's in the line above .list in the TikZ manual). Nice, I didn't know you can nest operators.
I have a TikZ-matrix. And I want to highlight the rows
1, 3, 6, 10, 15, 21, 28,... =n*(n+1)/2
For small examples, I could do it this way:
highlight/.style={ row #1/.style={....} },
highlight/.list={1,3,6,10,15}
But my question is: Think about a quite bigger number of rows (say 1000) - how ca...
@Rmano This is not elegant and not not-elegant, this means to know the correct command. :) Ok, more then I knew. But I want to work out an automatisation, not a single-case thing which is fine at one special MWE - I always think globally, not locally.
... ...... .......... Argh! It's often stupid that the rows (columns) in pgfplotstable are counted as 0,1,2,3, ... Mostly one would need 1, 2, 3, ... I would also find more sensible, because 0 would be more like the head for me.
At least in m3token002.lvt I get an unclosed \if from the second line but not from the first (with some patches to \prg_new_conditional applied)
@DavidCarlisle I found an edge case in which it makes a difference: If there is no argument for \my_TF_true:w to grab its replacement will not be inserted and \fi: not executed, leaving an unbalanced \if: there. So the first would be less robust in something like the following { \if:w a a \my_TF_true:w \fi: \use_ii:nn { one argument } }. Admittedly that already contains an error but the effects of that error are more severe with the first variant.
@cis most programming languages (I use) index starting from 0.
@DavidCarlisle Well, I did. What really seems odd is, however, that in the code above (the one from m3token002.lvt I get that behaviour only from the second line, not from the first (while if I use this in a standalone file, both fail).
@DavidCarlisle well, there is no space token to test in the second case either, it is ignored by TeX-argument grabbing logic.
@DavidCarlisle Yes, I know, but that space token will be gobbled when \token_if_space:NTF grabs its first argument (since spaces are ignored that argument will be TRUE).
@Skillmonlikestopanswers.xyz yes I guess you have looked what \token_if_space:NTF is doing, and it grabs the N as an argument:-) (I haven't looked at the code at all so just looking at the input and commenting it's different) I suppose \tracingall will reveal all...
@DavidCarlisle Oh, I think I found the issue. They are both unbalanced ifs, butregression-test will only complain about one Bad conditional the full log shows that indeed both are bad:
Bad conditionals: 1!
END-TEST-LOG
)
(\end occurred when \ifcat on line 199 was incomplete)
(\end occurred when \ifcat on line 199 was incomplete)