@barbarabeeton I want to submit one or more abstracts for TUG2019. Do you know when I would be notified if my paper was accepted?

@egreg: tex.stackexchange.com/questions/464962/how-to-type-or-in-minted Really? I get the ligatures...

@egreg: oh wait, I get the correct output.

@egreg: I think it's a cache issue.

I currently have problems with comments on the main site, not loading hidden ones and unable to add one.

Anybody else affected?

Adding did work just now.

@Skillmon I noticed that the asynchronous requests are terribly slow since a couple of days ago...

@PauloCereda ok, so it's not just me.

Seems that not only comments are broken ...

@samcarter hmmm

@PauloCereda The cat fixed the problemz :)

@samcarter ooh Die Katzproblem

@PauloCereda Die Katzenproblemlösung

Sometimes I don't get the voting system!

I have an answer which is 39 min older than the second one and solves the problem OP is facing with the means OP used (L3). The other answer uses L2e with a package and got upvoted only 1 or 2 minutes after it was posted. Mine has no votes...

Oh, and the L2e answer does use the same trick essentially, only the other package to further parse the argument. Voting system is strange :(

@Skillmon it's not a system, it's people. Don't try to understand. chat.stackexchange.com/transcript/message/47860062#47860062

@UlrikeFischer I know :( The other upvote is fine, I just don't get why the other users answer was upvoted while mine wasn't. Probably because it has fewer lines (I could obfuscate my code to be a single line, do I get more upvotes then?)

@Skillmon I would upvote neither: they're hacks around a wrong idea. The delimiter should simply not be a comma.

@egreg depending on the used keyboard layout, a , is much faster to type, and if the cases where one has to protect the commas are few, I can understand the preference of such syntax. In general another delimiter would be easier, though, you're right.

@HenriMenke -- i'm not sure. i'll ask, and also ask for the information to be put on the web site.

@egreg Or they can use an empty entry (a bit awkward, but no weird parsing)

@samcarter NOW I know why cats always want to play with a mouse.

@marmot :) and if they catch a bird, they are using twitter :)

Thursday a bug report complained that the source code for OpenJDK, the free and open-source implementation of Java, "has too many swear words." An anonymous reader writes:
"There are many instances of swear words inside OpenJDK jdk/jdk source, scattered all over the place," reads the bug report. "As OpenJDK is used in a professional context, it seems inappropriate to leave these 12 instances in there, so here's a changeset to remove them."

IBM software developer (and OpenJDK team member and contributor) Adam Farley responded that "after discussion with the community, three determinations w…

@L3Team: I'm voting to add tex.stackexchange.com/a/466018/117050 (or a reasonable variant) to the l3keys module.

@Skillmon add your suggestion to github.com/latex3/latex3/issues/505.

@UlrikeFischer didn't know he also opened a ticket. Will do so.

@Skillmon You know it's not a democracy, right? ;)

@JosephWright Yes, I know. It's a small change, though, and might benefit many in the future (but I don't have a use case myself).

@Skillmon See my GitHub comment: I wonder about the conceptual aspect

@JosephWright Would you rather patch the defined cmd if one used the .hook:n type? Would be an overhead during key definition but wouldn't require the test whether the hook-macro is defined. And the hook would be discarded if the key got redefined.

@Skillmon I was thinking that one could always define the hook, and then leave it to run or not ...

@JosephWright With a redefinition of the hook to be a gobble if the key gets redefined? So one could change \__keys_define_cmd:nn to something like

 \cs_set:cpn { \c__keys_code_root_tl #1 _hook } ##1 {}
 \cs_set_protected:cpx { \c__keys_code_root_tl #1 } ##1
   {
     \exp_not:N #2
     \exp_not:c { \c__keys_code_root_tl #1 _hook } { \exp_not:N ##1 }
   }

@Skillmon No, I meant keeping it entirely separate

@JosephWright ooh. That would require a bit more rewrite than I did, as far as I can tell. Is it worth it, performance wise? My approach shouldn't add to much of an overhead, as far as I can tell.

@Skillmon It's no different in performance terms: it's just a question of where you put in the code

@Skillmon At the setting stage, I think a hook would be disallowed for generic code:n in any case: it doesn't make sense there ...

@JosephWright Well though it doesn't, it doesn't hurt. And that would be a hurdle for users not reading documentation properly at the price of more code on our/the teams side.

@JosephWright @Skillmon I'm not sure that I like the idea. It looks a bit unorderly. I would prefer the meta-key setup.

@UlrikeFischer well the meta-key setup could lead to slightly irritating error messages. Imagine you pass in \setkeys:nn { mymodule } { my-bool = fals } and get the error message that the key my-bool-bool doesn't like the argument fals. I guess it's a matter of taste which approach to prefer, I'd be fine if the team says "no, we don't want those hooks", but I think it wouldn't hurt to provide them.

@Skillmon, @UlrikeFischer The coding is easy enough, but I want to see what everyone feels

@JosephWright well I do understand the part about the value validation. It is nice that foo=blb gives the error ! LaTeX3 Error: Key 'foo' accepts boolean values only.. But imho instead of adding hooks to a .bool_set:N, it would be more useful to have a check is_value_boolean at the begin of a .code:n part.

@UlrikeFischer But you already get an error for boolean keys .. you don't need to do a manual one

@JosephWright but not if the code is a .code:n key. I mean it is easy in a .code:n argument to store the value in a dim or a tl, but it is not straightforward to store the value in a boolean (and get a sensible error message if there is typo).

 foo .code:n = {%\bool_set:Nn \l_uf_bool:N { #1 } %doesn't work.
                       some~complicated code
                     }

@UlrikeFischer \str_case:nnF { #1 } { { true } { \bool_set_true:N \l_uf_bool } { false } { \bool_set_false:N \l_uf_bool } } { \msg_error:nn { uf } { only-boolean } } isn't too complicated though.