Thanks. I implemented a similar idea in Python in 
https://github.com/ickc/pandoc-amsthm/commit/8f806f5c33c220a3c1007343dbd193a285a378cc

Reproduced below.

Expressing that idea in Python (and panflute) seems quite verbose. May be 
there’s smarter way, below is quite procedural:

from __future__ import annotationsimport panflute as pffrom panflute.elements import Element, Doc
def merge_emph(elem: Element, doc: Doc) -> list[Element] | None:
    """Merge neighboring Emph with optionally Space between them."""
    if isinstance(elem, pf.Block):
        content = elem.content
        n = len(content)

        mutated = False
        # walk in reverse direction to avoid mutating current location i
        # also start with the 2nd last entry because we're matching 2 or more elements
        for i in range(n - 2, -1, -1):
            elem_cur = content[i]
            # remember that we are mutated content and therefore len(content) changes too
            elem_next = None if i + 1 >= len(content) else content[i + 1]
            elem_next_next = None if i + 2 >= len(content) else content[i + 2]
            if isinstance(elem_cur, pf.Emph):
                if isinstance(elem_next, pf.Emph):
                    merged = list(elem_cur.content) + list(elem_next.content)
                    content = list(content[:i]) + [pf.Emph(*merged)] + list(content[i + 2 :])
                    mutated = True
                elif isinstance(elem_next, pf.Space):
                    if isinstance(elem_next_next, pf.Emph):
                        merged = list(elem_cur.content) + [pf.Space] + list(elem_next_next.content)
                        content = list(content[:i]) + [pf.Emph(*merged)] + list(content[i + 3 :])
                        mutated = True
        if mutated:
            elem.content = content
    return None

​
On Thursday, December 16, 2021 at 6:49:52 PM UTC-8 John MacFarlane wrote:

>
> Yes, normalization is handled automatically -- but what we
> mean by normalization doesn't include your case, where the
> Space is *outside* the Emph and would be brought inside it.
>
> You could write a filter that does this sort of normalization.
> It would look in [Inline] lists for the pattern
>
> Emph xs , Space , Emph ys
>
> and convert this to
>
> Emph (xs ++ Space:ys)
>
>
> "christi...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org" <christi...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>
> > Hi,
> >
> > I recently have a situation that I want to have adjacent Emph separated 
> by 
> > Space to be “normalized”, combined to a single Emph. (And variants like 
> > this.)
> >
> > --normalize is removed in 
> > 
> https://github.com/jgm/pandoc/commit/8165014df679338d5bf228d84efc742c5ac39d2 
> > and I’m not sure if it is related.
> >
> > Example:
> >
> > $ echo "*text* *abc*" | pandoc -f markdown -t native
> > [ Para [ Emph [ Str "text" ] , Space , Emph [ Str "abc" ] ]
> > ]
> >
> > Is there someway to make it
> >
> > [ Para [ Emph [ Str "text" , Space , Str "abc" ] ] ]
> > ]
> >
> > Instead?
> >
> > Another example is (perhaps generated in a filter)
> >
> > [ Para [ Emph [ Str "text " ] , Emph [ Str "abc" ] ]]
> >
> > Is there some way to normalize it to
> >
> > [ Para [ Emph [ Str "text" ] , Space, Emph [ Str "abc" ] ]]
> >
> > When I say “some way”, preferably it is some pandoc flags (for example 
> > native to markdown then markdown to native is not reliable for the space 
> > problem above and won’t work to merge adjacent Emph), but even if we’re 
> > talking about doing it in filter, how to do things like this reliably?
> >
> > Thanks.
> >
> > P.S.
> >
> > Even for
> >
> > [ Para [ Emph [ Str "text" ] , Emph [ Str "abc" ] ]]
> >
> > won’t be normalized:
> >
> > $ echo '[ Para [ Emph [ Str "text" ] , Emph [ Str "abc" ] ]]' | pandoc 
> -f native -t native
> > [ Para [ Emph [ Str "text" ] , Emph [ Str "abc" ] ] ]
> >
> > But the text in the commit message seems to suggest it should:
> >
> > normalization is handled automatically by the Builder monoid instance.
> >
> > (But the commit is old so may be there’s more to it in the later 
> commits.)
> > ​
> >
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups "pandoc-discuss" group.
> > To unsubscribe from this group and stop receiving emails from it, send 
> an email to pandoc-discus...-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/pandoc-discuss/c887615c-9a1e-40a5-b6b0-a7bf22c87350n%40googlegroups.com
> .
>

-- 
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/73a470ac-2da5-445c-ac89-f423310206ccn%40googlegroups.com.