@JosephWright this was rather my impression. I don't want this to sound rude, but is it supposed to actually work? either I just failed to understand the documentation or it was somewhat buggy. (note that I've not tried anything at all recently. that answer maybe the last time I looked at it. it is probably also the first time I actually tried to use it. so I can't claim I persisted with it.)

@PabloGonzálezL Well the galley is quite low-level really - the question l3galley is trying to answer was really aimed at the days when we were still hoping for a new format. Some of the ideas have made it into 2e, but whether we can port the rest or not I don't know - if we do, there would be very different docs at the end

@cfr Yes, it works with the restriction that it's essentially incompatible with a large number of packages that rely on how the galley in 2e works. Without an example, I can't really guess what the issue is.

@JosephWright I guess the answer @PabloGonzálezL referred to earlier (chat.stackexchange.com/transcript/message/66185696#66185696):

I can actually remember answering this, but I could not get it to work without resetting the indentation. that is, I couldn't figure out how to limit the effect to a single paragraph with e.g. \galley_parshape_set_single:nVVN and the way in which it failed to work confused me.

(but the 'new' version is from 2016 which is why I asked @PabloGonzálezL if anything had changed.)

@PabloGonzálezL I won't do that, but I thought wrapstuff or wrapfig2 support lists.

@cfr I've not tested things since we added the paragraph hooks, which overlap to some extent with the galley ideas, so it would not surprise me if work is needed - but as I've said, I'm not sure if we can ever take the ideas further, and so it's not on the to-do list ATM

@Skillmon no, for what I know wrapfig &co does not work with any list (enumeration or similar: it is explicitly stated in wrapfig and not mentioned in wrapfig2, so I suppose it's still there), which is a PITA (one the top ones in my personal list of pains with LaTeX in general).

@Rmano wrapstuff explicitly documents that it (attempts to) works in lists...

@Skillmon Indeed: a quick look suggests it is basically using th same idea as l3galley for that specific area (l3galley changes all osrts)

\documentclass{article}
\usepackage{wrapstuff}
\usepackage{lipsum}
\usepackage{graphicx}
\begin{document}

\begin{wrapstuff}[l]
  \includegraphics[width=\dimeval{\linewidth/3}]{example-image-a}
\end{wrapstuff}
\begin{itemize}
  \item A
  \item B
  \item C
  \item D
\end{itemize}
\lipsum[2]

\end{document}

Seems to work OK

@JosephWright I originally planned to create a package for this but then wrapstuff hit the floor and I dropped my plans, so I'm rather sure that it supports it... :) But I thought wrapfig2 also supports it, that's a mistake on my end it seems...

\documentclass{article}
\usepackage{wrapstuff}
\usepackage{lipsum}
\usepackage{graphicx}
\begin{document}

\begin{wrapstuff}[l]
  \includegraphics[width=\dimeval{\linewidth/3}]{example-image-a}
\end{wrapstuff}
\begin{itemize}
  \item A
  \item B
  \item C
  \item D
\end{itemize}
\lipsum[2]

\end{document}

@Skillmon Can't come up with an example that works with a list

@cfr, @PabloGonzálezL As @Skillmon points out, wrapstuff seems to do the job and when you read the code is taking much the same approach asl3galley, using the new paragraph hook code

@cfr, @PabloGonzálezL As the hook code is one of the ideas that's in l3galley, it's not a complete surprise - what might never make it out of l3galley is the stuff about inter-paragraph spacing, etc. - I'm not sure we could use that and not break documents

@JosephWright ?! Your example works, does your message there miss a "doesn't"?

@JosephWright of course the l3galley code only being incompatible with a large number of packages is a big improvement on the original latex3 galley code which was incompatible with everything (and a large part of the reason latex3 got put on a back burner while we did 2e:-)

\documentclass{article}
\usepackage{wrapfig2}
\usepackage{lipsum}
\usepackage{graphicx}
\begin{document}

\begin{wrapfigure}{l}{\dimeval{\linewidth/3}}
  \includegraphics[width=\linewidth]{example-image-a}
\end{wrapfigure}
\begin{itemize}
  \item A
  \item B
  \item C
  \item D
\end{itemize}
\lipsum[2]

\end{document}

@Skillmon ^^ This is what I tried working from, never get the list indented

@DavidCarlisle :)

@DavidCarlisle I think actually the paragraph hooks cover quite a bit of what l3galley is really doing - things like paragraph shape can be added on (as shown in wrapstuff) - it's mainly a question of whether one could port the ideas about \addvspace, etc.

@DavidCarlisle Perhaps one to add to the mid-term to-do list: if nothing else, we should review status and make things clearer to people like @PabloGonzálezL :)

But first, really need to fix that templates are not documented properly ATM, and also things like \IfPackageLaterTF didn't get added to clsguide

That is something that can be sorted for the next release :)

@DavidCarlisle I'll mail the team list so galley doesn't get forgotten

@JosephWright yes addvspace is the tricky thing. The original idea was simpy document that packages should not directly access vertical mode (and undefining \vskip and friends helped) but that means essentially nothing worked until you re-wrote it which wasn't the most popular upgrade strategy (even for the half a dozen peopel who actually had the format)

@JosephWright ahh, you meant wrapfig2... Yes, as I said, that was a mistake on my end, my memory tricked me yet again...

(elipsis)

@DavidCarlisle :)

@Skillmon Ah, cool

@Skillmon Makes sense: you need some form of the paragraph hook mechanism to get propagation of shape - it's just detail after that how you implement (which is more-or-less what I'm going to say to the team)

@Skillmon yep, this seems to work:

\documentclass{article}
\usepackage{wrapstuff, caption}
\usepackage{lipsum}
\usepackage{graphicx}
\begin{document}

\begin{wrapstuff}[l, width=\dimeval{\linewidth/2}]
  \includegraphics[width=\linewidth]{example-image-a}
  \captionof{figure}{Blah}
\end{wrapstuff}
\begin{itemize}
  \item A
  \item B
  \item C
  \item D
\end{itemize}
\lipsum[2]

\end{document}

...although I am not sure about the spacing under the figure caption, but well.. It would be very nice if it could be integrated in wrapfigure2 or whatever to have the same syntax... Hmmm...

@Rmano you don't need to load caption, you can use \begin{wrapstuff}[type=figure].

@Rmano also, you don't need \dimeval for half a linewidth, that's possible via standard TeX syntax for length registers: width=0.5\linewidth.

@Rmano I think wrapfig2 is using the same approach as wrapfig (based on the abstract in their documentation), so I guess this is a "won't happen".

@Skillmon Yes, it does

@Skillmon oh, wow, I should read documentation ;-)

@Rmano nah, documentation isn't to be read, it's just to be used as "I told you so".

@Skillmon I expect @Rmano has read every word of the wrapstuff documentation.

@DavidCarlisle it is available in English.

@Skillmon oh so it is, texdoc showed me the original version in preference, presumably as it knows my linguistic skills.

Doesn't \href like to be called in an Expl context? I'm converting a CV formatting template to expl3 (as it is better to handle list data than etollbox). I was typesetting an ORCID number using in expl context using ORCID:~\href{https://orcid.org/##1/}{##1}. My Evince now thinks the URL is is a file link. So something fishy is going on. Colons?

@daleif Yes

@DavidCarlisle Bruno said he had some idea about how to redirect the primitives ...

@JosephWright not your most shocking comment ever:-)

@DavidCarlisle :)

@JosephWright Any idea of a href that still works?

@daleif colon most likely if it's matching for https:// but I haven't checked the code recently

@daleif @UlrikeFischer was I think going to look at this - but she's currently in Napa Valley so might be a while replying :)

\c_colon_str works

@daleif use \string: or as there \c_colon_str (or change the code to do a catcode-ignoring comparison....

@JosephWright too much wine for reliable code?

@DavidCarlisle :)

Can tabularx behave diferently inside expl mode. I have several and all end with the last line also having \\ (as the rows are generated using seq's). I keep getting extra vertical space after the tabularx that I did not see in a normal doc.

Hmm, cannot recreate it in an MWE, so it is comming from somewhere. Will debug later.

@Skillmon @JosephWright The wrapfig 2 package seems to work, but, it has the same limitations as wrapfig and fails horribly :(

@PabloGonzálezL might be, but wrapstuff works, so just use that...

@Skillmon Yes, I think it's the only one that does the job, I used it a while ago but the documentation was written in Chinese (literally), I checked again and now it's in English :D

\documentclass{article}
\usepackage{wrapstuff,lipsum,graphicx}
\begin{document}

\begin{wrapstuff}[r,width=10em] \includegraphics[width=8em]{example-image-b} \end{wrapstuff}
\begin{itemize}
  \item A
  \item \lipsum[1]
  \item \lipsum[2] \begin{wrapstuff}[r, width=10em] \includegraphics[width=8em]{example-image-b} \end{wrapstuff}
  \item D
\end{itemize}
\lipsum[2]

\end{document}

And it works with the rest of the list environments (quote for example):D

@Skillmon When you have time, you could update your answer at (tex.stackexchange.com/a/419275)

@PabloGonzálezL that answer is a bad example, as it was specifically about my insbox code... But I'll see whether I can rework some of them in the not-so-distant future.

@Skillmon It's a good answer (and more comfortable than minipage+wrapfig), unfortunately it didn't exist 10 years ago... Maybe it would be a nice challenge to migrate insbox to a more modern interface :D

@PabloGonzálezL as I already tried to say: Why? There is wrapstuff, I just don't see much to gain from that endeavor.

Found an MWE. Can anyone explain why the space above the second Foo header is larger than the spacing above the corresponding second Bar header?

\documentclass[a4paper]{article}
\usepackage{tabularx,array}

\newcolumntype{K}{@{}p{2cm}}
\newcolumntype{Y}{>{\raggedright\arraybackslash}X@{}}

\ExplSyntaxOn

\cs_new:Npn \_cv_map_dual:nn #1#2 { #1 & #2 \\ }
\seq_clear:N \l_tmpa_seq
\seq_put_right:Nn \l_tmpa_seq { {1}{A} }
\seq_put_right:Nn \l_tmpa_seq { {2}{B} }
\seq_put_right:Nn \l_tmpa_seq { {3}{C} }

\NewDocumentCommand\Foo{}
{
  \subsection*{Foo}
  \noindent
  \begin{tabularx}{\textwidth}{K Y}
    \seq_map_inline:Nn \l_tmpa_seq { \_cv_map_dual:nn ##1 }

Kinda like an inverse missing %

@daleif \seq_map_inline:Nn puts a non-expandable token after the last \\ so that line is infact started. Your \FOO is more akin to a \begin{tabularx}{\textwidth}{K Y}1&A\\\relax\end{tabularx}.

@Skillmon Any good way to get rid of it?

@Skillmon Is is just in this case it adds this non expandable stuff after the last item or is this documented somewhere?

@daleif Sure, use \seq_map_tokens:Nn \l_tmpa_seq { \use_i_ii:nn \__cv_map_dual:nn }, though you'll also need to define \use_i_ii:nn.

@daleif all the inline mapping functions keep a state for their nesting level and reset that after the last item, so they all add unexpandable stuff after your loop.

@Skillmon \cs_new:Npn \use_i_ii:nn #1#2 { #1#2 } to get rid of the brace group

@Skillmon you could have answered this (@daleif)

Thank's better. Now the new and old look identical.

Hmm, my expl version takes 0.3s more to typeset (1.1s vs 1.4s for 50 pages) under pdflatex. Perhaps that use of regex_match in one part of each page.

@daleif That would do it

@daleif We could probably add that: fancy making a PR?

@JosephWright Not quie sure how to explain the need for it.

I'll git it a go

This repro: github.com/latex3/latex3?

@daleif Don't worry, I'll do it :)

@JosephWright thanks.

The regex test does make up ~0.2s of that 0.3s dif. The rest is probably more seq looping and building seqs using _case

@DavidCarlisle yes, but I didn't see it because of dayjob

I knew I'd seen a str test to see if there is a substring, \str_if_in:nnTF, so no regex needed

@JosephWright while it came up before I don't think that there is an issue. Could you add one so that I don't forget it? (But I'm not sure if there is a simple solution).

@JosephWright maybe something changed? I'll try to look later. currently trying to distinguish wheelchairs.

@cfr Could be the hooks changes

@DavidCarlisle @JosephWright ^^^^ we are not yet at Napa valley but in Bodega looking for birds.

@JosephWright there is an l3doc question on the other site which you might want to take a look at (even if it's just a "Not supported; won't happen" response you might be able to help, I have no idea about l3doc's internals)

@JosephWright no, you fixed the bug:

but I failed to update the answer.

@cfr Ah :)

@JosephWright I'm sorry.

@PabloGonzálezL actually, the code works better with enumerate than I expected. (certainly much better than wrapfig.) but I'm not sure this is relevant given wrapstuff's availability?

@cfr which availability problem?

@PabloGonzálezL I think it could be made to work better, but is there any point?

@Skillmon I didn't say anything about an availability problem?

ctan.org/incoming

@cfr then I misunderstood "but I'm not sure this is relevant given wrapstuff's availability"

:66197909 Mmm \begin{itemize}
  \item A
  \item \kant[1]
  \item \kant[2] \putright{\includegraphics[width=8em]{example-image-duck}}
  \item D
\end{itemize}
\kant[2]

@cfr If you try this with your updated code you will see that it does not work as expected.

@Skillmon Having options for the same purpose is sometimes a good idea, and you may also be able to cover a point like in (github.com/latex3/latex2e/issues/1112)

@Skillmon -> means 'because wrapstuff is available, I'm not sure it's relevant whether my answer could be adapted to work with lists'.

@cfr yes, now I understood :) Thanks for clarifying that. Don't know what was on my mind when first reading it and misunderstanding it :)

@PabloGonzálezL I never claimed it worked. I just said it didn't fail as badly as I expected and that it does better than wrapfig. like I say, I think it could work (or, at least, it could work better), but is there actually any point? as @Skillmon and @JosephWright say, wrapstuff now copes with this kind of case out-of-the-box. (i.e. because somebody else has already done the work.) and, unlike my code, it doesn't load a package which is incompatible with almost every other package there is ...

@cfr Yes I understand, but wrapstuff unlike @DavidCarlisle packages is not bug free :D and fails on certain occasions :(

... and never likely to see the light of day. I'm not making any claims for the code in that answer, but improving it seems like an exercise in futility. (I removed the workaround which @JosephWright's bug fix rendered unnecessary because that was only a couple of deletions.) if you think there's a reason to look at fixing it, I will, but, as it is, I don't see any point.

@PabloGonzálezL but my code isn't actually, you know, usable in actual documents. and I'm sure it fails in more cases than wrapstuff. have you reported the problems? (I've never used it.)

@cfr Basically they were already reported (github.com/qinglee/wrapstuff/issues)

@PabloGonzálezL well, it is too late to put it inside the enumerate, I think. does wrapstuff work in this case?

@PabloGonzálezL I guess in one of the reports I can't read.

@cfr Yes, as long as you don't have \footnote

@PabloGonzálezL and it is compatible with latex, which is surely a plus in a latex package.

@cfr I haven't really tried it very much, just today I realized that the documentation is available in English :D

@PabloGonzálezL I can't actually read the documentation, but I would think fixing the problems there is likely to be more productive than pursuing a solution based on code never likely to be generally usable. I don't know if paragraph hooks even existed when I wrote that but, if they did, I'd certainly never heard of them. I mean, I doubt I would try to use xgalley now.

@cfr Yes, I think that is the best approach, but it seems the author doesn't have enough time (it hasn't been updated for two years)

@PabloGonzálezL well, you could fork the code. or you could ask here for workarounds for specific issues. if time is the problem, maybe the author would integrate fixes if supplied. and, er, two years isn't necessarily that long ;).