« first day (3364 days earlier)      last day (1555 days later) » 

12:02 AM
@JosephWright An idea: l3doc has that .cfg file thing. We could have a kernel config file that sets that boolean manually...
 
12:14 AM
@PhelypeOleinik. In your question tex.stackexchange.com/questions/524346 this looks wrong to me:
\tl_<some>_case:n(n)    % <case> = (upper|lower|mixed)
\str_<case>_case:n      % <case> = (upper|lower|fold)
\char_<some>_case:N     % <case> = (upper|lower|mixed|fold)
\char_str_<case>_case:N % <case> = (upper|lower|mixed|fold)
 
@Speravir Why?
 
I guess all <case> should be <some>. Right?
At least you have it once here and refer to it in the answer.
 
@Speravir Ah, that, yes. Initially I wrote \tl_<case>_case:n but then changed my mind as <case>_case looked odd
@Speravir Fixed. Thanks!
@Speravir I have no idea why I changed only two though...
 
12:29 AM
@PhelypeOleinik And I noticed your comment. I cannot react because of the character minimum. :-)
 
@Speravir Shame HTML doesn't work in comments. I <!--already tried--> would never think of doing such thing :-)
 
@PhelypeOleinik haha.
@PauloCereda When you chose the song for your TeXplate presentation did you even know who the interpret of this Neil Diamond/Monkees song is?
 
 
1 hour later…
1:56 AM
@PabloGonzálezL Sorry about that. The fixed and updated version has been uploaded now.
 
2:26 AM
@JosephWright you got late-night mail. Good night!
 
 
5 hours later…
7:21 AM
@DavidCarlisle Can you reproduce a weird link target in the following MWE when compiling with LaTeX -> dvips -> ps2pdf?
\documentclass{article}

\usepackage[super]{natbib}
\usepackage{hyperref}

\begin{document}
Text \cite{sigfridsson}
\begin{thebibliography}{1}
\bibitem{sigfridsson} Sigfridsson
\end{thebibliography}
\end{document}
The issue came up in tex.stackexchange.com/q/524407/35864 and reminded me of tex.stackexchange.com/q/524044/35864, but the fix there doesn't seem to help...
 
7:35 AM
@Speravir wow, a former football player
user image
2
@JosephWright ^^
 
8:01 AM
@moewe I get this but I still have an older gs (9.27) what do you get?
@PauloCereda imposter on team
 
@DavidCarlisle ooh
 
@DavidCarlisle I get the same with gs 9.23 (MikTeX on Win 10) and 9.26 (TeX live 2019 on Ubuntu).
pdfLaTeX produces the expected linking.
 
user image
5
@DavidCarlisle Firefox installed on Windows ^^
 
@DavidCarlisle I have to go now. Sorry to springing this onto you and leaving immediately. I'll have another look at this tonight, so if you have any more questions about my setup I'll be happy to answer them later.
 
8:22 AM
@PauloCereda oh, how fast does it run?
 
@Skillmon looks like a naughty fox. :)
 
8:40 AM
@moewe @DavidCarlisle I don't think that is a ghostscript problem. There is something going on with the hyperref link commands in superscripts. Basically Text\textsuperscript{\hyper@linkstart{cite}{cite.XXX}1\hyper@linkend} doesn't give the right link area. But I can't look now more, off skiing ...
 
@UlrikeFischer Have fun!
 
 
3 hours later…
yo'
11:53 AM
@DavidCarlisle @PauloCereda I don't know why I thoight of just the two of you: twitter.com/LindsayMasland/status/1217219359547981824?s=19
 
@yo' ooh :)
 
12:09 PM
@JosephWright seen Nicola recently? :-) tex.stackexchange.com/a/524494/1090
 
 
1 hour later…
1:22 PM
quack
 
@PauloCereda guess
 
2 days ago, by David Carlisle
@PauloCereda dinner
2 days ago, by Paulo Cereda
@DavidCarlisle oh no
ooh
 
I am no longer needed here. Goodbye.
 
@DavidCarlisle nooooooooooooooooooooooooooooo
@DavidCarlisle don't go
 
1:40 PM
@DavidCarlisle Not for a bit ...
@barbarabeeton I've started on a TUGboat based on my blog post but expanded
 
1:54 PM
@JosephWright yay, O(n) performance for my expkv :) (30 points per key, curves fitted on the data of $[1, 20]$ key=val pairs)
(the n log n plot looks strange though, maybe I've made a mistake there)
@JosephWright the l3text blog post?
 
@JosephWright -- Great! Thanks!
 
@JosephWright she replied via email:-)
 
@DavidCarlisle you are back <3
 
@PauloCereda was feeling hungry...
 
@DavidCarlisle uh-oh
 
2:08 PM
C is mean
 
@DavidCarlisle C the language? It's not mean.
 
@Skillmon It is if you access something with the wrong number of * :-) It believes in capital punishment not a mild slap on the wrist:-)
 
@DavidCarlisle :) void **(foo->bar)?
 
@Skillmon more or less yes, that then cast to what you expect to be there then try to use it...
 
2:36 PM
@Skillmon ooh
@DavidCarlisle EXACTLY
 
@DavidCarlisle I forgot the typecast :(
 
ooh bunnyplot
 
@PauloCereda well except I don't know what the ** pointer is pointing at just have an api to return bits of it as pointers to something else, plus I speak C the same way that I speak Portuguese (brilliantly?)
 
2:42 PM
@DavidCarlisle when handling double pointers, casting is merely a convenience. :)
 
@PauloCereda not if you have flags set to treat warnings as errors, but anyway casting doesn't really help if you are pointing at the wrong thing:-)
 
@DavidCarlisle bah who cares about warnings :)
alias gcc='gcc -w'
 
@PauloCereda -Wall -Wextra -Wno-unused-parameter -Wmissing-prototypes -Wstrict-prototypes -Wwrite-strings -Wunused -Werror=declaration-after-statement -Werror=vla
 
Now every evil plot without axis titles are uploaded :)
 
@Skillmon how many key val packages are there? (in my head there is only one)
 
2:52 PM
 
@Skillmon one and some pale imitations:-)
 
@DavidCarlisle those aren't all keyval, though, and I couldn't test every one (some are just bugfests) and some I just didn't test (e.g., pgfkeyx).
@DavidCarlisle tss, mine is fully expandable (as long as the code for the individual keys are). So not an imitation.
 
@Skillmon meanwhile I have dereferenced something that is not null , success:-)
 
@DavidCarlisle :)
@DavidCarlisle I like the keyval plot the most, even the quadratic fit says its linear :)
 
@DavidCarlisle holy cow
 
3:18 PM
@PauloCereda we like checking stuff
 
@DavidCarlisle I see :)
 
3:38 PM
Does someone have an idea what to do with xkeyval? My results say it's neither linear nor quadratic, more like O(n^{1.5}). Should I just assume O(n) or fit another O(n^{1.5}) to check how well that goes?
 
4:09 PM
Today something funny happened to me, l3doc didn't suppress a page break between subsection title and text.
 
@Skillmon Odd. It doesn't mess with section titles (it inherits them from article)... Unless there's a rather long function environment... Can I see the code?
 
@Skillmon I'm pleased to see l3keys is close to O(n)
 
@PhelypeOleinik sure, let me push it to github :)
 
@Skillmon No rush. I'll only look at it later
 
@Skillmon Have you got a specific use-case in mind?
 
4:13 PM
@PhelypeOleinik I need to get this done anyways, so I can finally work on my masters thesis again...
@JosephWright of course not. It's only expandable because it can be.
 
@Skillmon Sounds a lot like me :-)
 
@PhelypeOleinik github.com/Skillmon/tex_expkv compile the .dtx with pdflatex expkv.dtx && makeindex -s gind.ist -o expkv.ind expkv.idx && pdflatex expkv.dtx && pdflatex expkv.dtx, the offending heading is on page 6 "1.5 Error Messages"
 
@Skillmon Thanks!
 
@Skillmon I'm still wondering whether 'we' (I) should make \keyval_parse:NNn expandable (@DavidCarlisle?) - it might be handy but perhaps it's so specialised ...
 
This looks unreasonably hairy for the simple situation when one just wants multiple arguments.
12
Q: xparse: Define new command with multiple optional parameters

ThorstenI'd like to define a new command with optional parameters using the xparse package. Please consider the following example: \documentclass{minimal} \usepackage{xparse} \DeclareDocumentCommand{\mycommand}{ O{mydefault} m o o o }{% p:#2% \IfNoValueTF{#3}% {}% ...

Do I really need need to break out a key-value package if I have two optional arguments? Sigh.
 
4:20 PM
@FaheemMitha No, you can just use two optional arguments, it's just that this tends to be a sign of a poor interface
 
@MarcelKrüger Thank you very much
 
@FaheemMitha \DeclareDocumentCommand\foo{oom} ....
 
@JosephWright Well, those tests looks like more work than they should be, that's all. So you're saying I should be using a key-value package? There's nothing intrinsically bad about having multiple optional arguments.
 
@DavidCarlisle Related to (https://tex.stackexchange.com/a/524163/7832)

% OK ... fedora 31, TeXLive 2019 update
$ gs -v
GPL Ghostscript 9.27 (2019-04-04)
Copyright (C) 2018 Artifex Software, Inc. All rights reserved.

% OK ... Ubuntu 18, TeXLive 2019 update
$ gs -v
GPL Ghostscript 9.26 (2018-11-20)
Copyright (C) 2018 Artifex Software, Inc. All rights reserved.

% OK ... windows 10, TeXLive 2019 update
$ rungs -v
GPL Ghostscript 9.50 (2019-10-15)
Copyright (C) 2019 Artifex Software, Inc. All rights reserved.
 
@JosephWright That's the easy part.
 
4:23 PM
@Skillmon I found the problem
 
@PhelypeOleinik Hola ...como estas?
 
@JosephWright well, most of the time (read: always) you want to set some variable to store the actual value, so most keys will not be expandable. But one could write an expandable macro that first :e expands \keyval_parse:NNn and then reorders the resulting processor macros in the way it needs them, would be expandable, but a whole lot of work :)
 
@FaheemMitha The issue tends to be that if you have two consecutive optional arguments, setting only the second one is tricky
 
@PhelypeOleinik that was fast (I didn't start looking yet, just noticed it)
 
@Skillmon Of course I must say: It's not my fault!
 
4:24 PM
@Skillmon There've been times people have pondered wanting keyvals in an expansion context, but yes, using them is pretty tricky
@Skillmon In the end, the previous use cases have been resolved without expandable keyval
 
@Skillmon In the first paragraph, replace \expkv by expkv :-)
 
@Skillmon I might look again at performance, certainly if we want to replace xtemplate
 
@JosephWright Yes, I'm aware. I think most languages tend to offer support for named optional arguments, which makes the problem go away. Optional positional arguments aren't the greatest to work with.
 
@FaheemMitha Well yes, but that's just keyval by another name ;)
 
@DavidCarlisle hyperref is broken for dvipdfmx?...(using the same example)
 
4:25 PM
@JosephWright Exactly.
 
@Skillmon In your logo, use \textbf{...} instead of \begingroup\bfseries...\endgroup
 
@Skillmon @PhelypeOleinik Do you recommend just using key-value for this too?
 
@JosephWright well, though my expkv is expandable, it isn't expandable in a fixed number of expansions, nor does it some \unexpanded foo to be :e context expandable, so one has to smuggle values to get it the way one wants.
 
@PabloGonzálezL Bien, y tu? :-)
@FaheemMitha For what?
 
@FaheemMitha If you got multiple optional arguments and want to be able to only set the last one? Yes, most definitely.
 
4:27 PM
@Skillmon I do, and I do, yes.
@PhelypeOleinik Multiple optional arguments.
 
@FaheemMitha Example(s) please :)
 
@JosephWright this
 
@PhelypeOleinik or \leavevmode before \begingroup.
@FaheemMitha there is a new keyval package that is expandable, care to use it? :)
 
@Skillmon ooh rabbitval
 
@JosephWright Some code of @egregs. I just added a second optional argument. Hey presto, problem.
\NewDocumentCommand{\stack}{O{0.75}O{c}m}
{
  \typeout{FIRST~ARG~IS~#1}
  \typeout{SECOND~ARG~IS~#2}
  \typeout{THIRD~ARG~IS~#3}
  \renewcommand\arraystretch{#1}
  \begin{tabular}[#2]{@{}c@{}}
     \tl_map_function:nN { #3 } \__tom_stack:n
  \end{tabular}
}
 
4:29 PM
@PauloCereda CTAN doesn't like obfuscating names (but that would've been great, I should ask you before naming my packages), no, it's called expkv.
 
@Skillmon Which is?
 
@FaheemMitha What @Skillmon said. I myself am personally bad at remembering things, so a command that can be used as \cmd[thing] or \cmd[][otherthing], and then the behaviour changes if I leave the thing empty is particularly terrible for me to use. So yes, in that case keyval is good. But of course there are exceptions
 
@FaheemMitha Right, so that all looks straight-forward enough
 
Anyway, I guess I'll use pgfkeys. I've done it before. But it would be nice to be able to do it without the overhead.
 
@FaheemMitha expkv, will be on CTAN in a couple of days, currently only exists on github.
 
4:31 PM
@FaheemMitha Overhead?
 
@JosephWright If you're used to the syntax, sure.
 
@Skillmon they accepted arara. :)
 
@FaheemMitha the overhead of pgfkeys is actually not that bad.
 
@Skillmon Yet another key-val package, then.
 
@Skillmon Pretty tiny
 
4:31 PM
@JosephWright ooh
 
@Skillmon Agreed, it's not that bad as TeX goes.
 
@FaheemMitha that already exists, it's called yax.
 
And it actually manages to have reasonable error messages, at least some of the time.
 
@Skillmon yax is ... odd
 
So what distinguishes expkv from all the other key-val packages out there?
@JosephWright Sadly, I'm a bear of small brain. Or something like that.
 
4:33 PM
@JosephWright that's correct. Still the name is taken.
 
@JosephWright bah no divisible by 2...
 
@Skillmon Like I've said, think a TUGboat is in order, once I finish the case changing one
 
Link for expkv? Google doesn't find it. I guess that I could search directly on GitHub?
 
Speaking of TUGBoat, Frank has promised one on the 'new' NFSS Real Soon Now
 
@FaheemMitha it's the fastest key-val package that handles category code changes of = and , and input braces correctly.
 
4:34 PM
@Skillmon For the moment ;)
 
@Skillmon I don't really know what that means, but ok.
 
@Skillmon Thank you.
 
@JosephWright ooh rabbit vs duck
2
 
@Skillmon Like I've said, I may well look at picking this up for expl3: arguably performance in this area is important, and one aim of expl3 is to have a set of best-practice tools
 
4:36 PM
@JosephWright honestly, I doubt that you will beat it, but maybe there could be an even faster approach (Bruno?).
 
@Skillmon ooh Bruno probably eats keyvals as cereal. :)
 
@Skillmon I don't know the significance of an expandable key-val thingy is.
 
@FaheemMitha The brace-bug is easy to describe: With keyval loaded \setkeys{set}{key={ val}} will result in val as the argument to the key handler of set@key.
 
But remember that documentation is important.
 
@Skillmon Probably you are right, not least because I've got the constraint of stripping all spaces, but I can probably speed up \keyval_parse:NNn and perhaps sort out the long-standing issue of the name (it's the only public \keyval_... function)
 
4:38 PM
@FaheemMitha well, you keep asking things here, so it does not seem too important after all. :)
 
@Skillmon You mean it can't deal with text of the form {foo} as a key value?
 
@Skillmon Might be one 'for later', if we need real performance enhancements
 
@PauloCereda I read the documentation too.
 
@FaheemMitha They can, but the 'correct' outcome here is " val" with the space
 
@FaheemMitha no, it's stripping the braces before it's stripping spaces. Correct would be to get <space>val as argument.
 
4:40 PM
@Skillmon Oh. Well, that's subtle.
 
@FaheemMitha also you'll need to do \setkey{set}{key={{{val}}}} to have {val} as the argument.
 
@Skillmon Eek, that's terrifying.
 
@FaheemMitha and with xkeyval loaded, the situation turns worse, then you'll need to do \setkeys{set}{key={{{{val}}}}} (iirc).
 
@Skillmon I think I'll have a small stroke now.
 
@FaheemMitha It's handled correctly by expl3 and @Skillmon's expkv
 
4:42 PM
@JosephWright small interruption to keyval stuff: Is there a hook after l3build doc so that I copy the pdf to the main folder?
 
@JosephWright And only those two? Not pgfkeys?
 
@JosephWright and a few others, in the documentation of expkv there is a list of packages which have these two bugs and which not.
@FaheemMitha pgfkeys has this bug.
 
@UlrikeFischer Not at present, gets copied back to docfiledir
 
@Skillmon Is it fixable?
 
@Skillmon Well yes, I know 'and others', but I've said before that really for keyval it's one of kevyal itself, pgfkeys or l3keys, to which I might now add expkv :-) the others are interesting but I wouldn't recommend them
 
4:43 PM
@FaheemMitha there once was a package (pgfkeyx) which aimed to fix this (together with other changes), but it was last updated in 2012, I know that its maintainer is currently not active, and I don't know whether it has other bugs.
 
@Skillmon Oh.
 
@Skillmon Oh, him, yes
 
@JosephWright what about kvsetkeys? That one is O(n²) though.
 
Why not merge l3keys and expkv? Since they are presumably similar.
 
@Skillmon Well, not really, no
 
4:44 PM
@FaheemMitha no, they are not.
 
@Skillmon Oh, ok.
Never mind, then.
 
@FaheemMitha expkv is written with only two things in mind: Performance and robustness against the brace-bug and category fragility.
 
@FaheemMitha A better comparison is expl3's lower-level \keyval_parse:NNn, which does the kevyal splitting but doesn't offer higher-level set ups
 
@Skillmon Ok.
 
@FaheemMitha of course there are portions of it that could be copied over to l3keys (well actually to \keyval_parse:NNn), but expkv only knows two kinds of keys: those taking a value, and those that don't (and there might be a key that has both of those attributes).
 
4:46 PM
@FaheemMitha As I've indicated, it's possible I'll look to pick up some of the performance tricks for expl3: we've collected up lots of good ideas over the years
@Skillmon Exactly, much closer to the core parser
 
@JosephWright yes.
 
@Skillmon @JosephWright Well, ok. This all seems very complicated. I'm just a humble user with simple needs. pgfkeys will do me. I might branch out to l3keys at some point (which I'm guessing is more powerful in some respects) if I need to.
One question. Is performance important for a key-value thingy?
 
@FaheemMitha I'd prefer l3keys, but only because for higher level packages I tend to use expl3 anyways...
 
@Skillmon Yes, I see.
 
@FaheemMitha It becomes important when you use lots of keyvals: ConTeXt does (but they parse in a very different way)
 
4:52 PM
@FaheemMitha yes/no. Most packages are in the same range (at least for a single key), but some are especially bad. Keep away from ltxkeys (as far as possible), xkeyval was pretty wide-spread, but the brace-bug is almost unmanagable with it, also it's 10 times slower than expkv.
@FaheemMitha actually pgfkeys performs better than expkv for 8 or more keys (of simple nature, e.g., 8 times a key defined as key .code = \def\foo{#1})
 
@Skillmon Is pgfkeys an acceptable choice, then? At least for now.
 
@FaheemMitha not if you need a document in Turkish.
 
@Skillmon :)
 
@Skillmon selam ben Paulo!
 
@FaheemMitha that's the category code fragility common in many key=val packages. They don't work as soon as = has the category code 13 (so is turned active) which is what babel does for some languages (like Turkish). Also they don't work with , being active. Packages which still work with active category codes of their delimiters are (from fastest to slowesr): expkv, kvsetkeys, l3keys, and ltxkeys. ltxkeys` introduces way too many other bugs, though, to be considered
 
5:01 PM
MacOS Catalina is a plot to turn everyone into a libertarian.
 
@AlanMunn oh no
@AlanMunn what happened?
I am stuck with High Sierra forever.
 
@FaheemMitha and kvsetkeys needs quadratic runtime, so while it's faster for a single key than l3keys, it gets much slower real quick.
 
@Skillmon Happily I don't know any Turkish.
 
@Skillmon Like I've said, joint TUGboat?
 
@Skillmon So that leaves l3keys? :-)
I didn't realise that key-vals were such important business.
Can't pgfkeys be fixed up to pass these tests?
 
5:02 PM
@PauloCereda Well software that runs fine on earlier versions doesn't on Catalina because of the "nanny state" security system (hence the libertarian joke.) I'm not running it yet, but I was trying to get some software running on a student's computer and it won't.
 
@FaheemMitha then what about Latin?
 
@AlanMunn Maybe use a free OS?
@Skillmon Nope, no Latin either.
 
@JosephWright it becomes more and more likely :)
 
@Skillmon There's lots to talk about, and possibly might push me to speed up \keyval_parse:NNn a bit more
 
@AlanMunn ouch. I had some issues with macOS regarding security and whatnot, but nowhere near this nonsense.
 
5:04 PM
@AlanMunn I mean, since Apple's official motto is "do be evil".
 
@FaheemMitha so if it's just for yourself and you don't plan on making neither "=", "/", nor "," active and don't want to write in Turkish or Latin, and are confident to handle the brace-bug yourself through correcting input, then yes, why not use pgfkeys.
 
@Skillmon That sounds like a lot of conditions, but ok. So not fixable, then?
 
@FaheemMitha would be fixable, but I don't know whether the TikZ maintainers want to fix it (I might have a look sometime in the future, but don't feel responsible for it, I only maintain the parser pgf-module for now).
 
@FaheemMitha That's by far a worse option. Most of the time Mac stuff just works but lately they've been making it harder.
 
@FaheemMitha consider the following: there are millions of TikZ users who don't complain all the time. While those technical reasons are valid reasons, in practice they'll only sparsely be a real problem.
 
5:07 PM
@AlanMunn I don't agree, but then of course, I don't know what your usage is.
 
@PhelypeOleinik any idea why this errors?
\documentclass{l3doc}
\usepackage{tcolorbox}
\tcbuselibrary{listingsutf8}
\begin{document}
\begin{tcblisting}{}
abc
\end{tcblisting}
\end{document}
 
@Skillmon Sure. What would be the downside of fixing it? More fragile/incomprehensible error messages in the common cases?
 
@FaheemMitha there is a huge speed impact. expkv would be a third faster if I didn't care for the category code fragility. The error messages you'll currently get with those category settings are cryptic (something like undefined control sequence =).
 
@AlanMunn would disabling SIP mitigate the issues?
 
@JosephWright Well, 50% of the benchmarking is already done :) Also I have rudimentary tests for the brace-bug and category code fragility set up.
 
5:11 PM
@FaheemMitha Robustness here is essential, certainly for any new code, so for example for me/@DavidCarlisle for expl3 it's a must
 
@FaheemMitha or, if = was defined, you might get even more cryptic errors.
 
@Skillmon Wonderful. Cryptic even by TeX standards, you mean.
 
@UlrikeFischer Thanks for minimising the example. I opened an issue at the hyperref GitHub (github.com/latex3/hyperref/issues/115). (@DavidCarlisle)
 
@FaheemMitha The point though is that you, as a user, don't really need to worry: l3keys and expkv both deal with this
 
@FaheemMitha yes, this might happen. But as I said, most likely you'll never be affected as a user. So if you're used to pgfkeys you might as well use it. But l3keys is pretty similar in many of the basic concepts of its key handling (keys are in *nix-like paths). It doesn't allow one to easily set up cryptic syntax (like pgfkeys would allow you to define a key grabbing its argument as #1/#2,#3), and knows fewer keys, but in practice the keys it has suffice for a clean structure.
 
5:17 PM
@PauloCereda It might, but since this is a student's computer, I don't want to do things that will compromise it other than the bare minimum. Because they don't know too much about how their system works.
 
@AlanMunn Ah yes, that's sensible indeed.
 
@PauloCereda And since I haven't installed it on any of my Macs I can't test easily.
 
@Skillmon The latter is STATUS-BYDESGIN: I feel splitting keys should be handed off using .code:n and a proper splitter function
 
@JosephWright I know and appreciate this.
 
@PauloCereda And I'm not likely to install it right now because Canon, who makes our department copier/printers is notoriously bad about supplying Mac drivers and I don't want to be printerless.
 
5:20 PM
@AlanMunn ouch :)
 
@JosephWright in the end expkv has STATUS-BYDESIGN that it only knows keys and NoVal-keys, which is the most restricted behaviour possible I guess.
 
@AlanMunn I am actually denied by Apple. :)
 
@Skillmon Sure, that's like keyval
@Skillmon Or like \keyval_parse:NNn, really
 
@JosephWright almost. There can be a difference in the code between a key and its corresponding NoVal-key, unlike keyval that sets up defaults (something I've considered in the beginning, but didn't like as much)
@JosephWright I could add a key-setting parser though, which just does \protected\ekvdef{set}{key}{\mydim=#1\relax} in the background, but I doubt 100+ lines would be worth it, as that one is most likely not implementable with the existing parser...
 
@PauloCereda The only thing worse than their Mac support is their Linux support... @FaheemMitha
 
5:31 PM
@JosephWright regarding the space-stripping behaviour: Being able to strip an arbitrary amount of spaces from both ends (\tl_trim_spaces:n like), is an overhead of 2 ops per key per space (or space on both ends, I don't remember). My space trimmer has almost constant run-time with and without spaces, also it got the brace stripping built in, so that saves another expansion.
 
@AlanMunn Include HP in that list. HPLIP almost gave me a heart attack two months ago. :)
 
gotta go. Maybe until later!
 
5:46 PM
I just wanted to say so long and thanks for all the fish. I am leaving the SE network. I have learned so much about TeX and about being a welcoming community from you all.
7
 
@StrongBad oh no, dr StrongBad! You will be sorely missed. :(
/sad quack
Keep at least hanging out here, in this chat, please. <3
 
@StrongBad Sorry to see you go, although I understand why you might. There is some move a foot to create a competing system. Whether that will work or not remains to be seen. I think most of us are still content enough with the community here that there won't be a lot of impetus to leave.
 
yo'
6:00 PM
@StrongBad I saw your resignation. Thanks for building bridges, and I completely understand you!
@StrongBad I'd love for you to stay around, at least in some wqy! And I have to confess, the Ac.SE is a very nice place too. Inlike us, you've had to be solving very personal issues sometimes as thr matter of thr site is much more "humanly", and the fell of respect of others is so strong there. Thank you for being part of this!
 
6:16 PM
@moewe I answered in the github and in the tex.sx question too.
 
@StrongBad sorry to see you go, but I totally understand. Is there some way outside of SE to contact you (that you're willing to share)?
 
6:39 PM
@UlrikeFischer Thank you very much!
 
@Skillmon sure daniel.e.shub@gmail.com
 
@StrongBad you might want to delete this post from this chat again once your sure that everyone you want to share this information with has seen it :)
 
@Skillmon I am pretty sure my email address is available in so many places that it is not going to noticeably increase the amount of spam I get and besides I am curious what LaTeX related spam might look like (now that I write that, maybe I do not want to know what latex spam looks like, probably NSFW)
 
@StrongBad most definitely nsfw. Never tell your mom that you're interested in LaTeX, she might try to google it!
 
@StrongBad -- Sad news for me too. We've all had disappointments along with our hopes. Keep on trying for a better world -- I hope you find it and I know you'll contribute toward making it.
 
6:49 PM
@StrongBad The LaTeX spam gets especially bad if you're also running Shiny :)
 
@AlanMunn oh, shiny latex.
 
@UlrikeFischer I'll look
@UlrikeFischer Ugh, because underscore exists :(
@UlrikeFischer I'm seriously considering removing underscore from l3doc. It's not the first time it breaks things...
 
@StrongBad Take care, all the best
 
@UlrikeFischer Found it! latin1.def uses \DeclareInputText, which does:
   \ifcat_\expandafter\reserved@a\meaning\reserved@b$ $_%
      \DeclareInputMath{#1}{#2}%
   \else
      \DeclareInputMath{#1}{\IeC{#2}}%
   \fi
and it breaks with the active _
I think we could use a \noexpand there, just for safety...
 
7:18 PM
people are leaving left and right. I start to think the goal is to close the public Q&A at some point and sell teams, only.
sad quack indeed..
 
@FélixGagnon-Grenier The number of leavers remains small out of the total; I think ads on SO will keep making money
 
you're probably right
I'm sad, I don't know how to express it anymore. anger simply does not cut it anymore
 
7:33 PM
@Skillmon ooh
 
7:56 PM
Does anyone know how to modify Mark Wibrow's triangles example to draw black segments rather than leave white gaps/spaces between the triangles? tex.stackexchange.com/questions/258742/…
 
@Mathemanic you could ask a follow up question on the main site.
 
Ok. Wasn't sure if it was big enough to open a new question. I might do that. Thanks!
 
I think the character requirement is like, 200 characters, that can be like 200 bytes, quite small. /s
 
8:14 PM
@Skillmon true although since 99% of keys are width=.5\textwidth that has not bothered many people in practice
 
3 hours ago, by Skillmon
@FaheemMitha consider the following: there are millions of TikZ users who don't complain all the time. While those technical reasons are valid reasons, in practice they'll only sparsely be a real problem.
 
@DavidCarlisle he is not an impostor! He is a fan and has a fan-shirt!
 
@Skillmon Took your advice and opened a new question. :) Thanks!
 
8:30 PM
@PauloCereda You like this, right?
 
@UlrikeFischer thanks for help with the accessibility black magic:-)
 
@DavidCarlisle No problem ;-). What do you think about the hyperref/textsuperscript problem? Why does \textsuperscript set baselineskip to 0?
 
@UlrikeFischer I think as it was in an mbox it didn't really matter and it only really knows the font size not any class specified baselineskip for \scriptsize so it just seemed easier, we could work around it in hyperref but maybe we should change it in the format, could open an issue, or just raise it on team list?
 
@DavidCarlisle Ok, I will write to the team list first.
 
9:32 PM
@UlrikeFischer just so you know, I'm currently taking a look at your repositories to get a glimpse on how to use l3build, so if you get blamed in the near future you know why.
 
@Skillmon hm, not sure if this a good idea. You should better look at @JosephWright repos ...
 
@UlrikeFischer but then I couldn't blame you :)
@UlrikeFischer I learned a lot from @DavidCarlisle
 
@Skillmon oh you always can - after all I pointed you to Joseph ;-)
 
@UlrikeFischer right. Good.
 
9:48 PM
@mickep ooh <3
 
10:03 PM
@JosephWright should I try to prototype an expandable \keyval_parse:NNn macro in expkv, too? Currently one could build something similar using the \ekvsneak mechanism on top of \ekvset (but that'd be pretty complicated and don't have a good performance).
 
@Skillmon Might be interesting to see how the performance looks
 
11:00 PM
@JosephWright first draft needs ca. 39.2 ops for a single key "` height = 6 " (inserting \def\handleone#1{\def\foo{#1}}` and \def\handletwo#1#2{\def\foo{#1#2}}), that's about 2.5 times slower than keyval, but it expands in exactly two steps using \expanded and \unexpanded.
@JosephWright for comparison \keyval_parse:NNn needs ca. 51.3 ops for the same task.
 

« first day (3364 days earlier)      last day (1555 days later) »