Add "={...}" modifier and suppress brace stripping

[josephwright]

Pull requests in this repository are intended for LaTeX Team members only.

Internal housekeeping

Status of pull request

• Feedback wanted
• Under development
• [x] Ready to merge

Checklist of required changes before merge will be approved

• [x] Test file(s) added
• [x] Version and date string updated in changed source files
• [x] Relevant \changes entries in source included
• [x] Relevant changes.txt updated
• [x] ltnewsX.tex (and/or latexchanges.tex) updated

[josephwright]

I think the obvious questions here are

• Do we want to apply to all argument types
• Are we happy with a non-expandable approach at present (it's easier than doing by expansion, and I think realistically not needed for expandable commands)
• Does the fuzzy logic for detecting keyvals match our expectations?

[FrankMittelbach]

I think the obvious questions here are

* Do we want to apply to all argument types

Maybe we want to allow for it (as the code does now unless I'm totally misreading it), but I would suggest to explicitly suggest to limit its use as "best practice" to only normal optionals and preferable the first argument

* Are we happy with a non-expandable approach at present (it's easier than doing by expansion, and I think realistically not needed for expandable commands)

expandable would mean that you could have an expandable command that in an expansion situation parses the arguments and turns them into key/vals, correct? I can't really see usecase for it, because processing those keyvals in the payload would then most likely be not expandable in places. So I think that restriction is fine

* Does the fuzzy logic for detecting keyvals match our expectations?

to me it looks good.

[Skillmon]

I can't really see usecase for it, because processing those keyvals in the payload would then most likely be not expandable in places.

Oh no, all my expandable key=value work goes to waste :) I can understand if the full rule set isn't implemented expandably (and maybe I'll find the time somewhen in the future to implement an expandable alternative)

[josephwright]

I can't really see usecase for it, because processing those keyvals in the payload would then most likely be not expandable in places.

Oh no, all my expandable key=value work goes to waste :) I can understand if the full rule set isn't implemented expandably (and maybe I'll find the time somewhen in the future to implement an expandable alternative)

It's not impossible, of course, it's just that the combination of

• An existing document command with a free text (optional) argument
• A move of this argument to a keyval form
• A need to work by expansion in some context

seems extremely unlikely, so the effort isn't at this stage worth it. I've quite deliberately set up such that we could revisit this if there are use cases.