I have two filters, originally written in Perl, which I more recently have
tried to port to MoonScript/Lua, with mixed results due to the limitations
of Lua patterns.
One takes a configuration mapping in the metadata mapping short identifiers
to full URLs,

``````yaml
url_placeholders:
  foo: http://example.com/foo
  wp:
    url: https://en.wikipedia.org/wiki/
    case: u
    ws: '_'
``````

 such that an inline link like `[foo](-)` is "expanded" so that the `-`
pseudo-"URL" is replaced by `[foo](http://example.com/foo)`, `[bar](-foo)`
becomes `[bar](http://example.com/foo)` and `[gargoyle](+wp)` becomes
`[gargoyle](https://en.wikipedia.org/wiki/Gargoyle)` and `[grotesque water
sprout](+wp:Gargoyle)` becomes `[grotesque water sprout](
https://en.wikipedia.org/wiki/Gargoyle)` and
`[grotesque](+wp:|_(architecture))` into `[grotesque](
https://en.wikipedia.org/wiki/Grotesque_(architecture))`. I originally
wrote that filter as a workaround for the fact that regular reference links
may get broken when reformatting (part of) a file by running Pandoc
markdown→markdown if the link definition isn't inside the part being
reformatted, with a bit of extra typing-reducing shorthand thrown in, but I
soon found that it can be used to fudge variable relative URLs too, like
`![gargoyle](+images:|.jpg)` and then a suitable definition:

``````yaml
url_placeholders-local:
  images:
    url: ../../images/
    case: L
    ws: '-'
``````

Note how the top level key matches the regular expression/pattern
`^url_placeholders.*$` which is how I can define several such sets in
different places, sort them by the full key and then do a shallow
right-precedence merge.

The other filter takes an internal link of the form `[Some
Text](url#prefix#suffix)` into `[Some Text](url#prefix-some-textsuffix)`,
where each of the url, prefix and suffix, but not the hash characters
between them, are optional. So I can type `[function](##s)` and get
`[function](#function)` or `[vara](verbs.EXT#irregular#)` →
`[vara](verbs.html#irregular-vara)` (where yet another filter replaces the
dummy extension `.EXT` with `.html` or `.pdf` as the case may be). The
second filter has no bearing on relative URLs but the filters can be
combined giving me a pretty comprehensive solution for URL "shorthands"
like `[gargoyle](-ch-monsters#gallery#s)` expanding into
`chapter/030-monsters.html#gallery-gargoyles`. I'm planning to add a
feature which was in the Perl version whereby the URL may contain a form of
variable expansion so that e.g. the "tail" after the colon in a
`+<id>:<tail>` placeholder need not correspond literally to what goes into
the final URL. Then you could do really freaky things like

``````yaml
url_placeholders:
  ch:
    url: $(chapters)/$((chapnum.$(TAIL)))-$(TAIL).$(extension)
vars-url_placeholders-global:
  chapnum:
    intro: 001
    humans: 002
    monsters: 003
    hidden: 004
vars-url_placeholders-local:
  chapters: '../chapters'
  extension: '.html'
``````

where the three top keys are actually in different files and the "URL" in
the text may look like `+ch:monsters#dragons` and expand to
`../chapters/003-monsters#dragons`.

If the CSS paths are declared in the metadata (already supported) modifying
them using the same mechanisms will be an easy addition.

Things like these are clearly too complicated to build into core, but are
good game for filters.

Den tis 1 juni 2021 23:43Joseph Reagle <joseph.2011-T1oY19WcHSwdnm+yROfE0A@public.gmane.org> skrev:

> Thinking about this a bit more, `rebase_relative_paths` doesn't affect the
> `-c` parameter. Should it? Right now it's limited to links/images appearing
> within the markdown files themselves, but if I were to use something like:
>
>         pandoc chap*/*.md -f markdown+rebase_relative_paths
>         -c ../styles/base.css
>
> It might be useful -- or I might expect -- the resulting link tags to be
>
>         <link rel="stylesheet" href="../../style/base.css" />
>
> *If* that were the case, and then pandoc was willing to interpret `~` in
> file parameters as a relative link and rebase them, then my issue would be
> solved.
>
> I'm not convinced that's a great idea, only that it is an idea. 😉
> Otherwise, what I should do is modify my python build scripts to create a
> custom `-c` parameter for each markdown file built using the working
> directory `relative_to` the location of the markdown file [1].
>
> [1]:
> https://docs.python.org/3/library/pathlib.html#pathlib.PurePath.relative_to
>
> --
> 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/f35add93-e541-094c-6c13-feaa5410115e%40reagle.org
> .
>

-- 
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/CADAJKhAg8V4_%2B%2B1oeJvja%3DRQgZfbk3nOX--vwKxRbw0%2BemYctw%40mail.gmail.com.