ltmarks doc should not claim multicol support implemented

[cfr42]

Brief outline of the bug

ltmarks-doc.pdf page 9 includes the following in the description of \__mark_get_marks_for_reinsertion:nNN:

This is, for example, used by multicol when a short balanced multicols is returned to the galley for typesetting.

But, as far as I can tell, multicol is incompatible with the new marks code. There are at least two bug reports in which this is stated and the code doesn't obviously use expl3 syntax at all, so definitely doesn't use this particular function.

Minimal example showing the bug

Really not sure what you want for this. A copy of multicol.sty seems a bit verbose. With apologies to Windows users:

grep '_mark_' $(kpsewhich multicol.sty) 1>&2 2> /tmp/grep.log ; printf %b "exit: $?\n" >> /tmp/grep.log

Log file (required) and possibly PDF file

I was going to upload an empty file, but decided a more verbose version might be more to GitHub's taste.

grep.log

It would be really helpful if you could avoid documenting future code as extant. Maybe mark it as 'planned'? This is the only mention of multicol I could find in the doc. In particular, it wasn't at all obvious to me that I should not try this with ltxdoc and I spent several hours trying to figure out what I was doing wrong. (And it worked so well until \PrintChanges ....)

[josephwright]

Cf. #1421

[FrankMittelbach]

It would be really helpful if you could avoid documenting future code as extant. Maybe mark it as 'planned'? This is the only mention of multicol I could find in the doc. In particular, it wasn't at all obvious to me that I should not try this with ltxdoc and I spent several hours trying to figure out what I was doing wrong. (And it worked so well until \PrintChanges ....)

yes, I'm sorry, but that wasn't how it was supposed to be. That function was added for multicol and similar packages that manipulate the OR behavior and when I wrote that the plan was to make multicol use it at the same time. As it turned out it needed (and still needs) some more in multicol for which I didn't had the time back then, so that change got delayed and then moved down the stack (as so many things tend to do if they come at the wrong time).

I have now changed the text there to account for the fact that this hasn't happened yet.

[cfr42]

That function was added for multicol and similar packages that manipulate the OR behavior and when I wrote that the plan was to make multicol use it at the same time. As it turned out it needed (and still needs) some more in multicol for which I didn't had the time back then, so that change got delayed and then moved down the stack (as so many things tend to do if they come at the wrong time).

Of course. This is absolutely understandable. But it is also why I think the docs should mark planned features as planned rather than actual, because otherwise you'll always end up with cases where the docs claim things which aren't yet true. At least, they'd be inevitable if it was my material.

[FrankMittelbach]

yes, but when I wrote it they wheren't planned, they should have been added at the same time, that's where it went wrong. If they were the statement would have been correct and "planned" would have been wrong.