Well, in TeX speed and expandable things unfortunately come with slight levels of ugliness. The more you optimise for speed the uglier your code will get. And I have very strict rules I set for myself regarding code alignment and style, so everything is consistent. It's just filled with explicit token grabbing and such stuff.
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?