Skillmon

We could implement the new code for pdfTeX and XeTeX, and the old code for LuaTeX -- if diverging is fine by the team of course.

@zauguin sorry, didn't see your message. I guess in the meantime you wrote it yourself, but you can find the stuff I usually use for benchmarks here: https://topanswers.xyz/tex?q=2096

No idea on the letter. `f` might be misleading as it is an expansion type in `expl3` but I can't think of something more reasonable. Also what would the behaviour...

@PhelypeOleinik good point.

@blefloch for `+v` I currently use something like `\cs_new:Npx \__mymodule_process_verb_newline:nnn #1 #2 #3 { \tl_set:Nn \exp_not:N \ProcessedArgument { #3 } \tl_replace_all:Nnn \exp_not:N \ProcessedArgument { \char_generate:nn { 13 } { 12...

@PhelypeOleinik would be easy enough to put it in a `seq` inside the environments code (`\seq_set_split:Nxn \l_tmpa_seq { \char_generate:nn { 13 } { 12 } } { #1 }`), no...

Prototypes of those processors could be something like the following: ``` \documentclass[]{article} \usepackage{xparse} \ExplSyntaxOn \bool_new:N \l__xparse_is_in_bool \cs_new_protected:Npn \__xparse_replace_newline_loop:nnn #1 #2 #3 { \tl_if_in:NnTF \ProcessedArgument { #1 } { \bool_set_true:N \l__xparse_is_in_bool...

@tail-reversion my suggested processor implementation would allow you to place some arbitrary code instead of each literal newline and otherwise provides a big tl (just like any other argument type...

Suppressing a known set of ligatures during output can also be done by using `\tl_replace_all:Nnn` and replacing the problematic character with something that won't form the ligature.

@josephwright depending on the number of tokens to be replaced the performance will be a lot worse with the `\tl_replace_all:Nnn` approach.