use formatted chunk i.e. say "join-lines" etc.

[goyalyashpal]

hi again! as always, thank for such a wonderful tool.

just today i stumbled upon a use case where it might make sense to be able to use a chunk i.e. @< ... @> but in a single line form, i.e. such that all the newlines in the chunk's definition are removed.

this can be given name of:

• --as-single-line: direct, obvious, understandable
• --super-trimmed: as it's just trimming the terminal spaces: leading, trailing, and newlines
• --minify: might be a bit misleading, as minify involves removing spaces within lines too, which is NOT the scope of this issue

example use case:

These chunks contain filters in human-readable (i.e. pretty printed) form

@d filter1 @{
reduce(
  .packages[]
  | select (.id | test("^Microsoft\\.VisualStudio\\.Component\\.Windows1[01]SDK\\..*") )
  | {
      ( .id 
        | split(".")[-1] 
        | select(tonumber?) 
      ): .id
    }
) as $item ({}; . + $item)
@}

@d filter2 @{ ... @}
@d filter3 @{ ... @}

----

Save filters to ``.jq`` files for standalone use with ``jq`` CLI application

@o filter1.jq @{< filter1 @>@}
@o filter2.jq @{< filter2 @>@}
@o filter3.jq @{< filter3 @>@}

-----

Use the filter in a ``.jqpg`` (jq playground) file for quick interactive use

@o my_jq_based_application.jqpg @{

jq @< --as-single-line filter1 @>
> output1.json
$ cat input.json

jq @< --as-single-line filter2 @>
> output2.json
$ cat output1.json

jq @< --as-single-line filter3 @>
> final_output.json
$ cat output2.json

@}

[slott56]

Fascinating. While the bash convention is optional arguments BEFORE positional arguments, it seems that we have space for more flexibility here. Also. This seems to suggest there's a more general "-format=some rule" as opposed to a lot of individual "--some-rule" options.

@< -format=single-line chunk @> or @< chunk -format=single-line @>

1. For options, order should not matter. I don't recall any places with multiple positional parameters
2. I get the idea of reformatting a chunk prior to insertion. Other choices include doing substitutions or conditional insertions. Perhaps some explicit boundaries are needed? Or is the idea of unlimited text preprocessing sensible?

[goyalyashpal]

2. Other choices include doing substitutions or conditional insertions.
Perhaps some explicit boundaries are needed?
Or is the idea of unlimited text preprocessing sensible?

umh, i am a bit afraid that substitutions / conditionals etc would derail it from literate or say literature programming into the realms of templating or preprocessing language (like c's # preprocessors or the m4) and it would become super hard to follow and understand the weaved output as a literature.

and even if templating is required, anyone can use a dedicated language like jinja for that rather than py-web-lp reinventing yet another markup syntax for variables.

maybe even accomplishing this original suggestion should be handed over to some other application?

@< -format=single-line

yes, that's good :)

[goyalyashpal]

• also, do you stumbled across any other cases where such formatting is needed?
• as this was just one off case i hit upon. and at least 3-5 different use cases would be required to illustrate the generalisable requirements properly and justify any such undertaking or addition to the pyweb language i think.

[slott56]

Let me revise my comment after some thought.

One. Line joining is a "transformation" not really formatting. Further, it's lambda txt: " ".join(txt.splitlines()). Something that's configurable and can be defined within the source document.

Two. Chunk names have very few restrictions. Co-opting "--" becomes an arbitrary restriction.
Some syntax using @t as a meta character pair is preferable.

This leads me to the following. Something like @t(some lambda) @< chunk @> permits writing proper documentation in RST or LaTeX around the transformation applied to a chunk.

Or. @< chunk @t transformation @>. This is, perhaps, a clearer binding between source chunk and transformation.

I don't have any other examples. Left strip and right strip have occurred to me to pop the leading newline off a chunk.

Also. The indentation NOT based on context has occurred to me. But. I really don't like that. The @< @> markers MUST be indented properly so the resulting tangled code is indented properly seems more clear than applying transformations to do indentation.

One alternative to this use case is weaving documentation with line breaks but tangling without.

This example, however, seems to be weaving with line breaks and having two separate tangling modes: with and without line breaks.

These cases do not seem to apply to the definition of the chunk. They only apply to tangling the chunk. Which suggests there's no alternative syntax that puts the transformer into the definition. It must be part of the reference.

[goyalyashpal]

Some syntax using @t as a meta character pair is preferable.

This leads me to the following. Something like @t(some lambda) @< chunk @> permits writing proper documentation in RST or LaTeX around the transformation applied to a chunk.

Or. @< chunk @t transformation @>. This is, perhaps, a clearer binding between source chunk and transformation.

these are good ideas 😃

The indentation NOT based on context has occurred to me.

i used to think for indentation too, but i have not faced any difficulties in indentation other that tab indentation not respected in case i need to add a multi line chunk.