@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!

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 or because yours has more underscores and that frighten someone.

@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.