@FaheemMitha 'Prototype document functions' ... er, they are a way of abstracting the idea of say 'a list' to but all of the design part into keyvals so you implement-once, use-many-times
@FaheemMitha It predates @Skillmon and I really working hard on this
@FaheemMitha There's a performance cost to being careful
@FaheemMitha OK, so we are currently working on lists (enumerate, itemize, etc.). The idea is to have a generic 'list' implementation, then define how it looks by setting a load of keys.
@JosephWright It seems that the chances of the pgfkeys behavior being changed is zero, so I should presumably not waste my time filing an issue. Correct?
@FaheemMitha You don't want to parse all of the keys for every list in a long document, so you want to turn the keys into a set of \def\foo{...} then use that set
@FaheemMitha You can log, so there is a record, but I think a change is extremely unlikely - of course a decision is down to @HenriMenke
@FaheemMitha Fixing the code is not so hard, as we have two reference implementations that work right - it's the problem that there would almost certainly be effects in documents, and that is an issue
@JosephWright Thank you for the explanations. I most likely won't file an issue for pgfkeys. I file enough bug reports that are ignored already. Though the current behavior isn't exactly ideal.
@FaheemMitha a few years ago I fixed the brace stripping in keyval.sty and it broke babel and essentially every non english latex document stopped working. Backing out the change seemed the right thing to do, even though it gives @Skillmon an excuse to remind me of suboptimal behaviour of the package at frequent intervals
@DavidCarlisle I'm afraid to ask, but fixing the documents wasn't an option? Some software, notably some Python packages, don't seem to worry that much about backward compatibility. Pandas comes to mind.
@FaheemMitha no. It's not documents but language support files, and that means reaching muliple possibly out of contact or deceased maintainers of languages, and possible extension packages and... At the time I needed to fix in hours not days so backing out the change the only possibility.
@FaheemMitha It would have then been possible to try to coordinate some longer term coordinated update, but why do it. Danger of breaking existing documents very high, and the weird brace behaviour had not prevented the package being used for 20 years with no one reporting the issue, so the need to sometimes double{{ is now a feature not a bug.
@egreg I knew you would have fun (I'd seen them all except the memoir one, I was too tired last night to look:-) Did you know of that package before?, seems very odd.
@UlrikeFischer some of my tests also gave warnigs, but given the number of overlapping packages here, happy to fix the errors for PL1, we can maybe look again when have more time (@JosephWright)
@DavidCarlisle Doing \tracingall I saw that the blank space involved \count151 which is \@curtab and was clearly visible in the replacement text of \@addamp. But \@curtab is not used by equationarray and array, so the only candidate was memoir (which has a long story of spurious spaces).
@JosephWright well my example is "latex only". But imho the bug with the unused option is unrelated. It happens already without the changes. something like pagecolor is removed, but pagecolor=red is not.
@DavidCarlisle @JosephWright xkeyval needs a similar fix. Do you know how to reach Hendri? I thought I had an address but can't find it.
@FaheemMitha because the original expkv was meant as feature comparable to keyval (with some additions to ease the expandable use), and it is meant to be as fast as possible, and the next design goal was to be somewhat lightweight (it's big compared to keyval though, but provides two parsers instead of only one, and grew to have a few bonus features which weren't contained originally), hence the decision back then to write expkv-def just as an additional front end for key defining.
@FaheemMitha correct, plus table 1 (which belongs to that section, but floated to come after section 1.8 in the current manual)
@UlrikeFischer probably needs same fix (remove just the name) from the list but original plan was not to change too much of the original handler to avoid breaking packages that patch it. But we have been (forced to be) braver recently
@JosephWright there are three reference implementations! kvsetkeys is correct as well (and I think even more robust against category code changes than we are), but it has quadratic runtime.
@UlrikeFischer Like @DavidCarlisle said, can we live with that for the present? Avoid the hard error and deal with the sub-optimal option list a bit later?
@FaheemMitha It depends heavily on what's the issue. If we can improve something without breaking shittons of documents, chances are pretty good (e.g. in the next release pgfkeys will gain \usepgfkeyslibrary for extensions).
We're also trying to fix some of the brace-stripping problems but these are much more likely to cause trouble for people “relying” on the broken behavior.
@UlrikeFischer \tracingall waded through dozens of lines of l3 code trace trying to work out where the \ was dropped then finally looked at the test example....
@FaheemMitha Even worse, when for example a style key (defined by /.style handler) passes its value to another key, which is another style key that passes the value on. :(
@FaheemMitha no I didn't as I didn't see a big advantage of showing yet another example (and there are many l3keys examples on the page), and the l3keys example would've been identical to the expkv-def one (modulo the different key defining syntax, and the expl3 naming conventions).
@UlrikeFischer ... and a couple of dozen confirmation queries "Are you sure?" -- "Are you really, really sure?" -- ... -- "You will hurt a lot of cute ducks if you do this!"
