Why do you think you are alone in TeX? I guess people would better understand your code if it was prettier.
Thanks! Then I'll change the note to self into: use inline code next time to avoid ligatures :)
`s` is `...` and `i` is `..`, but the ligatures on this site transform `..` into ..., so you did nothing wrong (and the online translator was fine -- except for the exclamation mark, that has a code as well)
Note to self: don't trust random online translators if I try to say "Nice idea!"
Presenting new package idea `remorse`: parses input and turns it into `\morseDIT` and `\morseDAH` calls according to the international Morse code. With `\morseDIT` and `\morseDAH` being redefinable to satiate different needs.
The fact that some of my team members have subpar English skills, but since we have 1 English speaker who doesn't speak German in the team everything has to be documented in English, doesn't help with reading their code °~°
For instance (well, more like, the most extreme example): `expkv` is *fast*. But the internals are a hot mess. Almost no code is reusable, because everything that's grab-able as an explicit token is grabbed as an explicit token. I could often use things like `\def\ekv@thingy#1\ekv@stop{<do-something>}` but instead the definition reads `\def\ekv@parse@thingy#1\ekv@mark\ekv@mark\ekv@parse@otherthingy#2\ekv@nil#3\ekv@mark#4\ekv@stop{}` and then there is something that does almost the same, but with the name `\ekv@set@thingy`.well, only in the TeX world. During dayjob I'm the strongest advocate for pretty code with nice interfaces and well thought-out structure of my team. Inside TeX I mostly work alone, at dayjob other people have to read my code, and more importantly I have to read theirs...
Do you like the documented interfaces of my code? That's how it looks from outside.
Usually I love how your code works, but not how it "looks", so I would disagree.
... and rabbits will just dig a burrow between the fast code and the good code :P
Most of the time it makes no odds - I switch to release if it seems relevant (it's just a drop-down in my editor, so it's easy)
Haha, three things and I failed to understand it yesterday. 1) It is more common for me to say "not me" than "not I". 2) Funnily, the font at my home system has a confusing shape for `I` that resembles with `|`. So I thought `| ↑↑↑` is a mathematical notation. 3) Wikipedia said that `↑↑↑` is Knuth's way of marking long integers (making it worse for me). Maybe I was too sleepy yesterday.. :joy:
Worst thing to ask for is an explanation for the joke, but not familiar with the notation, so I pass on this :P
sorry to disappoint you, but when I'm answering questions I don't use `-dev`.
Yeah, even I need it for my release, so I was wondering if I should release and then ask people to use dev or wait till it gets released, but since it is very close I will release my software :)
Oh yess! Sorry, I misunderstood that the date was of the publication of the news and didn't check it.
Of course, the 'project and friends' are all running dev anyway :-)
The pattern is nominally 06-01 and 11-01, but it depends on how busy I am the day before
When will the changes from [ltnews42](https://mirrors.ctan.org/macros/latex-dev/base/ltnews42.pdf) be public? Is there any predictable pattern to when do -dev formats become the usual generic ones?
For cheese fans: https://stockage.framapiaf.org/framapiaf/media_attachments/files/115/418/448/006/755/147/original/5ec1666292a73bc1.jpg
Yes, it's more robust to provide a setup macro, which is why most modern packages do that. Parsing key=value options is problematic, even if you use the new mechanism of the raw options list (as do `\ProcessKeyOptions`, `expkv-opt`, and `scrbase`) everything passed there has to survive a round of `\zap@space` (since the zapped list will still be assigned). Expansion control might help with that (in `\ProcessKeyOptions`-using lists you can use `key:c = macro` instead of `key = \macro` to pass in `\macro` without that being fully expanded in the zapping list, similarly in `expkv-opt`-parsing you can use `c: key = macro` to achieve the same -- unfortunately `l3keys` doesn't use the same syntax as `expkv`)
Thanks for sharing. It is difficult for me to stand the mix of `@`s and `_`s now.. :smile:
I didn't find an example in the wild, but with some experimentation, I figured out how the option works :) https://github.com/josephwright/ltx-talk/pull/102/files
Since there are known problems in key-values for `\usepackage` (i.e., `zap@space`), should modern packages rely less on package options? In my recent package bundle, I have a key-processing command that takes care of the local as well as global options. I did it when I didn't know the problems caused by `\zap@space`. Turns out that it is safer in general. Should/could this be a strategy for package writing?