* Verbatim text in headers
@ 2020-08-05 14:00 Anton Shepelev
2020-08-06 20:17 ` Anton Shepelev
0 siblings, 1 reply; 15+ messages in thread
From: Anton Shepelev @ 2020-08-05 14:00 UTC (permalink / raw)
To: pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw
Hello, all
As distinct from other Markdown processors and other output
formats, while rendering DOCX output with Pandoc, inline
`verbatim` text in headers does not work so well, because it
inherits not only the font, but also the font size from the
`Verbatim Char' style. I do realise that it is the right
thing to do for running text because most monospace fonts
look better at a slightly decreased size (e.g. 12pt Times
New Roman and 11pt Courier New), but I still should like to
see nice typewriter text in headers:
## The `switch` keyword
The only solution that I can now propose without introducing
new settings and otherwise compicating the DOCX rendered, is
smartly to infer the size for verbatim text for headers from
the `Verbatim char' style based on the size of the main
header font, using the proportion:
verb_hdr = verb_base * hdr_size / base_size
where verb_hdr is font size to use for verbatim text in the
header, verb_base the base verbatim font size as specified
in the `Verbatim char' style, hdr_size the main font size in
the header as specified in the `Heading' style of the
corresponding level, and base_size the base font size as
specified in the `Body text' style. That way, Pandoc will
preserve the ratio between the size of the "typewriter" font
and of the font of the surrounding text.
I use this approach in my GNU Troff macros, and it works
well.
--
Please, do not forward replies to the list to my e-mail.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Verbatim text in headers
2020-08-05 14:00 Verbatim text in headers Anton Shepelev
@ 2020-08-06 20:17 ` Anton Shepelev
[not found] ` <20200806231710.dd08c7f61a90ea23c708d507-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
0 siblings, 1 reply; 15+ messages in thread
From: Anton Shepelev @ 2020-08-06 20:17 UTC (permalink / raw)
To: pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw
I asked:
> As distinct from other Markdown processors and
> other output formats, while rendering DOCX output
> with Pandoc, inline `verbatim` text in headers
> does not work so well, because it inherits not on-
> ly the font, but also the font size from the
> `Verbatim Char' style. I do realise that it is the
> right thing to do for running text because most
> monospace fonts look better at a slightly de-
> creased size (e.g. 12pt Times New Roman and 11pt
> Courier New), but I still should like to see nice
> typewriter text in headers:
>
> ## The `switch` keyword
I wonder who nobody replied. What is your method of
typsetting such headers:
# The `switch` keyword
# The `ref` and `out` keywords
# The `far` and `near` modifiers
# The `printf()` function
Do you fix them in your Lua filters? Is it better
to have this functionality in a Lua filters on in
Pandoc itself?
--
Please, do not forward replies to my e-mail.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Verbatim text in headers
[not found] ` <20200806231710.dd08c7f61a90ea23c708d507-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
@ 2020-08-06 20:38 ` Leonard Rosenthol
2020-08-06 20:57 ` Anton Shepelev
2020-08-07 9:09 ` BPJ
1 sibling, 1 reply; 15+ messages in thread
From: Leonard Rosenthol @ 2020-08-06 20:38 UTC (permalink / raw)
To: pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw
[-- Attachment #1: Type: text/plain, Size: 2549 bytes --]
Anton - interesting problem.
I haven't run into this one myself, though I fully understand the situation.
I would think that a separate character style, say "Verbatim Header" that
is based on the Header style would be the best option - perhaps using the
formula that you defined.
Currently, I end up writing such things in Lua filters (as I am more
comfortable in Lua and I don't have to wait for updates to pandoc) - but I
think that if you agree with the suggestion above, we'd want that in pandoc
including in the standard reference.docx.
Leonard
On Thu, Aug 6, 2020 at 4:17 PM Anton Shepelev <anton.txt-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> I asked:
>
> > As distinct from other Markdown processors and
> > other output formats, while rendering DOCX output
> > with Pandoc, inline `verbatim` text in headers
> > does not work so well, because it inherits not on-
> > ly the font, but also the font size from the
> > `Verbatim Char' style. I do realise that it is the
> > right thing to do for running text because most
> > monospace fonts look better at a slightly de-
> > creased size (e.g. 12pt Times New Roman and 11pt
> > Courier New), but I still should like to see nice
> > typewriter text in headers:
> >
> > ## The `switch` keyword
>
> I wonder who nobody replied. What is your method of
> typsetting such headers:
>
> # The `switch` keyword
> # The `ref` and `out` keywords
> # The `far` and `near` modifiers
> # The `printf()` function
>
> Do you fix them in your Lua filters? Is it better
> to have this functionality in a Lua filters on in
> Pandoc itself?
>
> --
> Please, do not forward replies to my e-mail.
>
> --
> 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/20200806231710.dd08c7f61a90ea23c708d507%40gmail.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/CALu%3Dv3JVngmSBL23Lmckh89FT0ivtxnd2%2Bo%2B%3DUchr1ZF%2BVdGeg%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 3724 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Verbatim text in headers
2020-08-06 20:38 ` Leonard Rosenthol
@ 2020-08-06 20:57 ` Anton Shepelev
[not found] ` <20200806235733.6c944e913ef52f26b00c2f09-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
0 siblings, 1 reply; 15+ messages in thread
From: Anton Shepelev @ 2020-08-06 20:57 UTC (permalink / raw)
To: pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw
Leonard Rosenthol to Anton Shepelev:
> > What is your method of typsetting such headers:
> >
> > # The `switch` keyword
> > # The `ref` and `out` keywords
> > # The `far` and `near` modifiers
> > # The `printf()` function
> >
> > Do you fix them in your Lua filters? Is it bet-
> > ter to have this functionality in a Lua filters
> > on in Pandoc itself?
>
> I would think that a separate character style, say
> "Verbatim Header" that is based on the Header
> style would be the best option -- perhaps using
> the formula that you defined.
Do you propose that the reference document store as
many "Verbatim Header" styles as there are "Header
styles" -- one per each level? -- with a hard-coded
font size precalcualted using the formula? In my
opinion, that would be rather clumsy! Or do you
mean that Pandoc should generate those styles on-
the-fly?
> Currently, I end up writing such things in Lua
> filters (as I am more comfortable in Lua and I
> don't have to wait for updates to pandoc)
Are Lua filters so omnipotent? How do you debug them?
> but I think that if you agree with the suggestion
> above, we'd want that in pandoc including in the
> standard reference.docx.
It depends on whether your propose to hard-code nine
levels of "Verbatim Header" styles. If you do, then
I don't agree. Pandoc should be smarter than that or
avoid the logic altogether and delegate it to Lua
filters -- loth though am I to write them.
--
Please, do not forward replies to my e-mail.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Verbatim text in headers
[not found] ` <20200806235733.6c944e913ef52f26b00c2f09-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
@ 2020-08-06 21:04 ` Dmitriy Krasilnikov
2020-08-06 21:17 ` Leonard Rosenthol
1 sibling, 0 replies; 15+ messages in thread
From: Dmitriy Krasilnikov @ 2020-08-06 21:04 UTC (permalink / raw)
To: Finn Mathisen
[-- Attachment #1: Type: text/plain, Size: 2924 bytes --]
If you dont want a char style you should replace the monospaced text with
an xml code, wrapping the monospaced text. The xml can be parametrized with
font sizes, but pandoc does not know and should not know anything about
font sizes of your headings in reference docx file, its none of its concern.
чт, 6 авг. 2020 г., 23:57 Anton Shepelev <anton.txt-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
> Leonard Rosenthol to Anton Shepelev:
>
> > > What is your method of typsetting such headers:
> > >
> > > # The `switch` keyword
> > > # The `ref` and `out` keywords
> > > # The `far` and `near` modifiers
> > > # The `printf()` function
> > >
> > > Do you fix them in your Lua filters? Is it bet-
> > > ter to have this functionality in a Lua filters
> > > on in Pandoc itself?
> >
> > I would think that a separate character style, say
> > "Verbatim Header" that is based on the Header
> > style would be the best option -- perhaps using
> > the formula that you defined.
>
> Do you propose that the reference document store as
> many "Verbatim Header" styles as there are "Header
> styles" -- one per each level? -- with a hard-coded
> font size precalcualted using the formula? In my
> opinion, that would be rather clumsy! Or do you
> mean that Pandoc should generate those styles on-
> the-fly?
>
> > Currently, I end up writing such things in Lua
> > filters (as I am more comfortable in Lua and I
> > don't have to wait for updates to pandoc)
>
> Are Lua filters so omnipotent? How do you debug them?
>
> > but I think that if you agree with the suggestion
> > above, we'd want that in pandoc including in the
> > standard reference.docx.
>
> It depends on whether your propose to hard-code nine
> levels of "Verbatim Header" styles. If you do, then
> I don't agree. Pandoc should be smarter than that or
> avoid the logic altogether and delegate it to Lua
> filters -- loth though am I to write them.
>
> --
> Please, do not forward replies to my e-mail.
>
> --
> 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/20200806235733.6c944e913ef52f26b00c2f09%40gmail.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/CALZUCcD7E0jkOcUUwyQ6KW8%3DLk8%2Boj7oJpjxcHpcXkSO8hF70g%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 4041 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Verbatim text in headers
[not found] ` <20200806235733.6c944e913ef52f26b00c2f09-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2020-08-06 21:04 ` Dmitriy Krasilnikov
@ 2020-08-06 21:17 ` Leonard Rosenthol
2020-08-06 21:38 ` Anton Shepelev
1 sibling, 1 reply; 15+ messages in thread
From: Leonard Rosenthol @ 2020-08-06 21:17 UTC (permalink / raw)
To: pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw
[-- Attachment #1: Type: text/plain, Size: 3569 bytes --]
>Do you propose that the reference document store as many "Verbatim
Header" styles as there are "Header styles" -- one per each level? -- with
a hard-coded font size precalcualted using the formula?
>Or do you mean that Pandoc should generate those styles on- the-fly?
I would think they *must* be pre-calculated and live in the reference.docx,
since the header styles themselves are stored there (and pandoc) has no
information about how I have customized them. So if you tried to create
them itself, it would well end up doing the wrong thing.
>Are Lua filters so omnipotent? How do you debug them?
>
I don't know about "omnipotent", as there are definitely things you can't
do with them...but they *could* do this particular use case. They could
walk the header block, find any included spans with an attribute of
verbatim (or whatever it is), and then add the new named-style for it. (OR
if you wanted to be very low level, you could put "raw" openxml to just
adjust the font size).
On Thu, Aug 6, 2020 at 4:57 PM Anton Shepelev <anton.txt-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Leonard Rosenthol to Anton Shepelev:
>
> > > What is your method of typsetting such headers:
> > >
> > > # The `switch` keyword
> > > # The `ref` and `out` keywords
> > > # The `far` and `near` modifiers
> > > # The `printf()` function
> > >
> > > Do you fix them in your Lua filters? Is it bet-
> > > ter to have this functionality in a Lua filters
> > > on in Pandoc itself?
> >
> > I would think that a separate character style, say
> > "Verbatim Header" that is based on the Header
> > style would be the best option -- perhaps using
> > the formula that you defined.
>
> Do you propose that the reference document store as
> many "Verbatim Header" styles as there are "Header
> styles" -- one per each level? -- with a hard-coded
> font size precalcualted using the formula? In my
> opinion, that would be rather clumsy! Or do you
> mean that Pandoc should generate those styles on-
> the-fly?
>
> > Currently, I end up writing such things in Lua
> > filters (as I am more comfortable in Lua and I
> > don't have to wait for updates to pandoc)
>
> Are Lua filters so omnipotent? How do you debug them?
>
> > but I think that if you agree with the suggestion
> > above, we'd want that in pandoc including in the
> > standard reference.docx.
>
> It depends on whether your propose to hard-code nine
> levels of "Verbatim Header" styles. If you do, then
> I don't agree. Pandoc should be smarter than that or
> avoid the logic altogether and delegate it to Lua
> filters -- loth though am I to write them.
>
> --
> Please, do not forward replies to my e-mail.
>
> --
> 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/20200806235733.6c944e913ef52f26b00c2f09%40gmail.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/CALu%3Dv3JMMSPb6ezfA1tDjaZubJbT-ebbw7wmHBzScsEb2-t9xw%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 4956 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Verbatim text in headers
2020-08-06 21:17 ` Leonard Rosenthol
@ 2020-08-06 21:38 ` Anton Shepelev
0 siblings, 0 replies; 15+ messages in thread
From: Anton Shepelev @ 2020-08-06 21:38 UTC (permalink / raw)
To: pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw
Leonard Rosenthol to Anton Shepelev:
> > Do you propose that the reference document store
> > as many "Verbatim Header" styles as there are
> > "Header styles" -- one per each level? -- with a
> > hard-coded font size precalcualted using the
> > formula? [...] Or do you mean that Pandoc should
> > generate those styles on-the-fly?
>
> I would think they *must* be pre-calculated and
> live in the reference.docx, since the header
> styles themselves are stored there (and pandoc)
> has no information about how I have customized
> them. So if you tried to create them itself, it
> would well end up doing the wrong thing.
That means a lot of duplicate work. Cannot Pandoc,
or rather its DOCX renderer, calculate and set the
correct font size for any `verbatim` text in a head-
er, depending of the font size of the corresponding
Header style? In other words, does the DOCX render-
er have access to the reference document? If it
does not, then of course I have to agree you...
On the other hand, why not let the renderer access
the reference document? It would solve this and
other problems, including the one I posted earlier
about the indetnation of nested lists, which is cur-
rently and deplorably hard-coded.
Another example that comes to mind is the formatting
of defintion lists in Word. A small left indent in
the `Defintion' style gives them professional look,
almost like man-pages. But things go bad if one in-
serts a code block into a definition, because its
left indent is used absolute, i.e. not added to the
indent of the containing defintion.
In my opinion, the ability to analyse the reference
document will do more good than harm and will obvi-
ate some of Word's flaws. Word is very "special" in
that good WYSWYM systems need now such hackery. Of
course, it may be contrary to the design philosophy
of Pandoc, but I have to learn it better to under-
stand why...
--
Please, do not forward replies to my e-mail.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Verbatim text in headers
[not found] ` <20200806231710.dd08c7f61a90ea23c708d507-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2020-08-06 20:38 ` Leonard Rosenthol
@ 2020-08-07 9:09 ` BPJ
[not found] ` <14a2d64c-3044-5d89-0412-fc06c7f40a7c-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2020-08-08 12:18 ` Anton Shepelev
1 sibling, 2 replies; 15+ messages in thread
From: BPJ @ 2020-08-07 9:09 UTC (permalink / raw)
To: pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw
[-- Attachment #1: Type: text/plain, Size: 3127 bytes --]
Assuming you don't need the verbatim to be highlighted you could use a
span with a custom style instead of a Code element, and define that
custom style however you want (search for "custom-style" in the manual!):
``````markdown
# The [switch]{custom-style=H1-verb} keyword
``````
Since that custom style attribute is a lot to type I would probably use
a combination of a class and a Lua filter, especially since the heading
text in Markdown has to fit on a single physical line, and so that it
doesn't break if I change the level of a heading:
``````markdown
# The [switch]{.hv} keyword
## The [ref]{.hv} and [out]{.hv} keywords
### The [far]{.hv} and [near]{.hv} modifiers
#### The [printf()]{.hv} function
``````
and then in "header-verb.lua":
``````lua
-- Template for custom style, where %d will be filled in with
-- the heading's level number
local style_template = 'Heading %d Verbatim'
-- Filter generator for walking a header and fix spans
local function mk_span_filter (level)
style_name = style_template:format(level)
return { Span = function (span)
if not span.classes:includes('hv') then return nil end
span.attributes['custom-style'] = style_name
return span
end
}
end
function Header (head)
local filter = mk_span_filter(head.level)
return pandoc.walk_block(head, filter)
end
``````
Then in your reference DOCX define the "Heading 1 Verbatim" "Heading 2
Verbatim" etc. styles, presumably as inheriting from "Verbatim Char" as
you wish and you are good to go.
An irritation is that you apparently can't override bold/italic set in
the paragraph style, at least in LibreOffice.
Files attached. Tested with pandoc 2.9.2 and LibreOffice 6.0.7.3
On 2020-08-06 22:17, Anton Shepelev wrote:
> I asked:
>
>> As distinct from other Markdown processors and
>> other output formats, while rendering DOCX output
>> with Pandoc, inline `verbatim` text in headers
>> does not work so well, because it inherits not on-
>> ly the font, but also the font size from the
>> `Verbatim Char' style. I do realise that it is the
>> right thing to do for running text because most
>> monospace fonts look better at a slightly de-
>> creased size (e.g. 12pt Times New Roman and 11pt
>> Courier New), but I still should like to see nice
>> typewriter text in headers:
>>
>> ## The `switch` keyword
>
> I wonder who nobody replied. What is your method of
> typsetting such headers:
>
> # The `switch` keyword
> # The `ref` and `out` keywords
> # The `far` and `near` modifiers
> # The `printf()` function
>
> Do you fix them in your Lua filters? Is it better
> to have this functionality in a Lua filters on in
> Pandoc itself?
>
--
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/14a2d64c-3044-5d89-0412-fc06c7f40a7c%40gmail.com.
[-- Attachment #2: heading-verb.lua --]
[-- Type: text/x-lua, Size: 548 bytes --]
-- Template for custom style, where %d will be filled in with the heading's level
local style_template = 'Heading %d Verbatim'
-- Filter generator for walking a header and fix spans
local function mk_span_filter (level)
style_name = style_template:format(level)
return { Span = function (span)
if not span.classes:includes('hv') then return nil end
span.attributes['custom-style'] = style_name
return span
end
}
end
function Header (head)
local filter = mk_span_filter(head.level)
return pandoc.walk_block(head, filter)
end
[-- Attachment #3: test.md --]
[-- Type: text/markdown, Size: 154 bytes --]
# The [switch]{.hv} keyword
## The [ref]{.hv} and [out]{.hv} keywords
### The [far]{.hv} and [near]{.hv} modifiers
#### The [printf()]{.hv} function
[-- Attachment #4: ref.docx --]
[-- Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document, Size: 8298 bytes --]
[-- Attachment #5: test.docx --]
[-- Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document, Size: 10163 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Verbatim text in headers
[not found] ` <14a2d64c-3044-5d89-0412-fc06c7f40a7c-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
@ 2020-08-07 9:35 ` Benct Philip Jonsson
[not found] ` <389fb88b-aadf-9cfc-3061-9c2dde74bccd-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
0 siblings, 1 reply; 15+ messages in thread
From: Benct Philip Jonsson @ 2020-08-07 9:35 UTC (permalink / raw)
To: pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw
[-- Attachment #1: Type: text/plain, Size: 4680 bytes --]
just after I hit "send" I realized that with just a bit more Lua
trickery you can convert a Code element with or without a class into a
Span element with a custom-style attribute. Updated filter and md file
below and attached. Currently the class check is commented out in the
filter to show that it is not strictly needed. Sorry for the lapse!
``````markdown
# The `switch`{.hv} keyword
## The `ref`{.hv} and `out`{.hv} keywords
### The `far`{.hv} and `near`{.hv} modifiers
#### The `printf()`{.hv} function
``````
``````lua
-- Template for custom style, where %d will be filled in with
-- the heading's level number
local style_template = 'Heading %d Verbatim'
-- Filter generator for walking a header and fix spans
local function mk_code_filter (level)
style_name = style_template:format(level)
return { Code = function (code)
-- if not code.classes:includes('hv') then return nil end
local span = pandoc.Span{ pandoc.Str(code.text) }
span.attributes['custom-style'] = style_name
return span
end
}
end
function Header (head)
local filter = mk_code_filter(head.level)
return pandoc.walk_block(head, filter)
end
``````
On 2020-08-07 11:09, BPJ wrote:
> Assuming you don't need the verbatim to be highlighted you could use a
> span with a custom style instead of a Code element, and define that
> custom style however you want (search for "custom-style" in the manual!):
>
> ``````markdown
> # The [switch]{custom-style=H1-verb} keyword
> ``````
>
> Since that custom style attribute is a lot to type I would probably use
> a combination of a class and a Lua filter, especially since the heading
> text in Markdown has to fit on a single physical line, and so that it
> doesn't break if I change the level of a heading:
>
> ``````markdown
> # The [switch]{.hv} keyword
>
> ## The [ref]{.hv} and [out]{.hv} keywords
>
> ### The [far]{.hv} and [near]{.hv} modifiers
>
> #### The [printf()]{.hv} function
> ``````
>
> and then in "header-verb.lua":
>
> ``````lua
> -- Template for custom style, where %d will be filled in with
> -- the heading's level number
> local style_template = 'Heading %d Verbatim'
>
> -- Filter generator for walking a header and fix spans
> local function mk_span_filter (level)
> style_name = style_template:format(level)
> return { Span = function (span)
> if not span.classes:includes('hv') then return nil end
> span.attributes['custom-style'] = style_name
> return span
> end
> }
> end
>
> function Header (head)
> local filter = mk_span_filter(head.level)
> return pandoc.walk_block(head, filter)
> end
> ``````
>
> Then in your reference DOCX define the "Heading 1 Verbatim" "Heading 2
> Verbatim" etc. styles, presumably as inheriting from "Verbatim Char" as
> you wish and you are good to go.
>
> An irritation is that you apparently can't override bold/italic set in
> the paragraph style, at least in LibreOffice.
>
> Files attached. Tested with pandoc 2.9.2 and LibreOffice 6.0.7.3
>
>
>
> On 2020-08-06 22:17, Anton Shepelev wrote:
>> I asked:
>>
>>> As distinct from other Markdown processors and
>>> other output formats, while rendering DOCX output
>>> with Pandoc, inline `verbatim` text in headers
>>> does not work so well, because it inherits not on-
>>> ly the font, but also the font size from the
>>> `Verbatim Char' style. I do realise that it is the
>>> right thing to do for running text because most
>>> monospace fonts look better at a slightly de-
>>> creased size (e.g. 12pt Times New Roman and 11pt
>>> Courier New), but I still should like to see nice
>>> typewriter text in headers:
>>>
>>> ## The `switch` keyword
>>
>> I wonder who nobody replied. What is your method of
>> typsetting such headers:
>>
>> # The `switch` keyword
>> # The `ref` and `out` keywords
>> # The `far` and `near` modifiers
>> # The `printf()` function
>>
>> Do you fix them in your Lua filters? Is it better
>> to have this functionality in a Lua filters on in
>> Pandoc itself?
>>
--
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/389fb88b-aadf-9cfc-3061-9c2dde74bccd%40gmail.com.
[-- Attachment #2: test-2.md --]
[-- Type: text/markdown, Size: 154 bytes --]
# The `switch`{.hv} keyword
## The `ref`{.hv} and `out`{.hv} keywords
### The `far`{.hv} and `near`{.hv} modifiers
#### The `printf()`{.hv} function
[-- Attachment #3: test-2.docx --]
[-- Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document, Size: 10163 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Verbatim text in headers
[not found] ` <389fb88b-aadf-9cfc-3061-9c2dde74bccd-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
@ 2020-08-07 9:38 ` Benct Philip Jonsson
0 siblings, 0 replies; 15+ messages in thread
From: Benct Philip Jonsson @ 2020-08-07 9:38 UTC (permalink / raw)
To: pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw
[-- Attachment #1: Type: text/plain, Size: 4966 bytes --]
Forgot to attach the new filter...
On 2020-08-07 11:35, Benct Philip Jonsson wrote:
> just after I hit "send" I realized that with just a bit more Lua
> trickery you can convert a Code element with or without a class into a
> Span element with a custom-style attribute. Updated filter and md file
> below and attached. Currently the class check is commented out in the
> filter to show that it is not strictly needed. Sorry for the lapse!
>
> ``````markdown
> # The `switch`{.hv} keyword
>
> ## The `ref`{.hv} and `out`{.hv} keywords
>
> ### The `far`{.hv} and `near`{.hv} modifiers
>
> #### The `printf()`{.hv} function
> ``````
>
> ``````lua
> -- Template for custom style, where %d will be filled in with
> -- the heading's level number
> local style_template = 'Heading %d Verbatim'
>
> -- Filter generator for walking a header and fix spans
> local function mk_code_filter (level)
> style_name = style_template:format(level)
> return { Code = function (code)
> -- if not code.classes:includes('hv') then return nil end
> local span = pandoc.Span{ pandoc.Str(code.text) }
> span.attributes['custom-style'] = style_name
> return span
> end
> }
> end
>
> function Header (head)
> local filter = mk_code_filter(head.level)
> return pandoc.walk_block(head, filter)
> end
> ``````
>
>
>
> On 2020-08-07 11:09, BPJ wrote:
>> Assuming you don't need the verbatim to be highlighted you could use a
>> span with a custom style instead of a Code element, and define that
>> custom style however you want (search for "custom-style" in the manual!):
>>
>> ``````markdown
>> # The [switch]{custom-style=H1-verb} keyword
>> ``````
>>
>> Since that custom style attribute is a lot to type I would probably
>> use a combination of a class and a Lua filter, especially since the
>> heading text in Markdown has to fit on a single physical line, and so
>> that it doesn't break if I change the level of a heading:
>>
>> ``````markdown
>> # The [switch]{.hv} keyword
>>
>> ## The [ref]{.hv} and [out]{.hv} keywords
>>
>> ### The [far]{.hv} and [near]{.hv} modifiers
>>
>> #### The [printf()]{.hv} function
>> ``````
>>
>> and then in "header-verb.lua":
>>
>> ``````lua
>> -- Template for custom style, where %d will be filled in with
>> -- the heading's level number
>> local style_template = 'Heading %d Verbatim'
>>
>> -- Filter generator for walking a header and fix spans
>> local function mk_span_filter (level)
>> style_name = style_template:format(level)
>> return { Span = function (span)
>> if not span.classes:includes('hv') then return nil end
>> span.attributes['custom-style'] = style_name
>> return span
>> end
>> }
>> end
>>
>> function Header (head)
>> local filter = mk_span_filter(head.level)
>> return pandoc.walk_block(head, filter)
>> end
>> ``````
>>
>> Then in your reference DOCX define the "Heading 1 Verbatim" "Heading 2
>> Verbatim" etc. styles, presumably as inheriting from "Verbatim Char"
>> as you wish and you are good to go.
>>
>> An irritation is that you apparently can't override bold/italic set in
>> the paragraph style, at least in LibreOffice.
>>
>> Files attached. Tested with pandoc 2.9.2 and LibreOffice 6.0.7.3
>>
>>
>>
>> On 2020-08-06 22:17, Anton Shepelev wrote:
>>> I asked:
>>>
>>>> As distinct from other Markdown processors and
>>>> other output formats, while rendering DOCX output
>>>> with Pandoc, inline `verbatim` text in headers
>>>> does not work so well, because it inherits not on-
>>>> ly the font, but also the font size from the
>>>> `Verbatim Char' style. I do realise that it is the
>>>> right thing to do for running text because most
>>>> monospace fonts look better at a slightly de-
>>>> creased size (e.g. 12pt Times New Roman and 11pt
>>>> Courier New), but I still should like to see nice
>>>> typewriter text in headers:
>>>>
>>>> ## The `switch` keyword
>>>
>>> I wonder who nobody replied. What is your method of
>>> typsetting such headers:
>>>
>>> # The `switch` keyword
>>> # The `ref` and `out` keywords
>>> # The `far` and `near` modifiers
>>> # The `printf()` function
>>>
>>> Do you fix them in your Lua filters? Is it better
>>> to have this functionality in a Lua filters on in
>>> Pandoc itself?
>>>
>
--
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/b37cad64-6606-3200-aaf1-2afe6f393711%40gmail.com.
[-- Attachment #2: heading-verb2span.lua --]
[-- Type: text/x-lua, Size: 627 bytes --]
-- Template for custom style, where %d will be filled in with
-- the heading's level number
local style_template = 'Heading %d Verbatim'
-- Filter generator for walking a header and fix spans
local function mk_code_filter (level)
style_name = style_template:format(level)
return { Code = function (code)
-- if not code.classes:includes('hv') then return nil end
local span = pandoc.Span{ pandoc.Str(code.text) }
span.attributes['custom-style'] = style_name
return span
end
}
end
function Header (head)
local filter = mk_code_filter(head.level)
return pandoc.walk_block(head, filter)
end
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Verbatim text in headers
2020-08-07 9:09 ` BPJ
[not found] ` <14a2d64c-3044-5d89-0412-fc06c7f40a7c-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
@ 2020-08-08 12:18 ` Anton Shepelev
[not found] ` <20200808151809.d2878d07de78b0b3f6606673-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
1 sibling, 1 reply; 15+ messages in thread
From: Anton Shepelev @ 2020-08-08 12:18 UTC (permalink / raw)
To: pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw
Benct Philip Jonsson:
> Assuming you don't need the verbatim to be high-
> lighted->
No, I don't. I shall be happy if I can make my Word
documents, which I am forced to produce at work,
look professional on paper. And for paper, I accept
only black on white.
> -> you could use a span with a custom style in-
> stead of a Code element, and define that custom
> style however you want (search for "custom-style"
> in the manual!):
>
> ``````markdown
> # The [switch]{custom-style=H1-verb} keyword
> ``````
Thank you. It is the easiest (and clumsiest) solu-
tion. It is also badly redundant in that the writer
has manually to sepcify the correct heading level.
Futhermore, it is fragile as any program with dupli-
cate implicit dependencies: the writer must take
care to change the style specification every time
the heading level changes, which is a code smell.
> Since that custom style attribute is a lot to type
> I would probably use a combination of a class and
> a Lua filter, especially since the heading text in
> Markdown has to fit on a single physical line, and
> so that it doesn't break if I change the level of
> a heading:
Hmmm, no way to split long headings over several
lines? Does that mean I cannot have an 90-character
heading and keep the source at 72 characters per
line? Maybe Markdown should provide a facility to
specify long on on several source lines based either
on the prefix or on the indent, e.g.:
## This is a long long long long long long long
long long long long long lonesome heading
split into three lines using list-like syntax
## This is a long long long long long long long
## long long long long long lonesome heading
## split into three lines using list-like syntax
Considering the niceties of indent processing in
Markdown, the second version would be the more reli-
able, if harder to set up in Vim...
> ``````markdown
> # The [switch]{.hv} keyword
>
> ## The [ref]{.hv} and [out]{.hv} keywords
>
> ### The [far]{.hv} and [near]{.hv} modifiers
>
> #### The [printf()]{.hv} function
> ``````
This is much better indeed, for the redundancy is
gone: this syntax takes care of the heading level
instead of having the writer worry about it.
> and then in "header-verb.lua":
> ``````lua
> -- Template for custom style, where %d will be filled in with
> -- the heading's level number
> local style_template = 'Heading %d Verbatim'
>
> -- Filter generator for walking a header and fix spans
> local function mk_span_filter (level)
> style_name = style_template:format(level)
> return { Span = function (span)
> if not span.classes:includes('hv') then return nil end
> span.attributes['custom-style'] = style_name
> return span
> end
> }
> end
>
> function Header (head)
> local filter = mk_span_filter(head.level)
> return pandoc.walk_block(head, filter)
> end
> ``````
`mk_span_filter()' has misaligned curly braces, but
I think I understand what it does: it constructs a
processing funciton based the heading level. Was it
a deliberate decision in the Pandoc Lua interface to
rely on such functional trickery as closures instead
of passing information in parameters? Of course,
the additinal parameter would have to be untyped,
what is a an untyped parameter in a dynamic lan-
guage? In C, one has to pass void*, as in
qsort_r(): http://man.he.net/man3/qsort .
As far as I understand, it is simply impossible to
pass additional data to a filter function in any
other way than inside a closure. Oh, perhaps one
could do it via a global variable, but that is not
good either. Yet it would work an single-threaded
environment.
> Then in your reference DOCX define the "Heading 1
> Verbatim" "Heading 2 Verbatim" etc. styles, pre-
> sumably as inheriting from "Verbatim Char" as you
> wish and you are good to go.
That would be redundant manual work, for a WYSWYM
system should automatically infer the font size and
style for a verbatim block depending on context. Can
Lua filter do it? Can it read the font size from the
heading style and automatically calculate the font
size of the code block based on that?
> An irritation is that you apparently can't over-
> ride bold/italic set in the paragraph style, at
> least in LibreOffice.
In MS Word it is the same with your filter, but I
can live with that.
> Files attached. Tested with pandoc 2.9.2 and
> LibreOffice 6.0.7.3
Thanks a lot, Benct!
> just after I hit "send" I realized that with just
> a bit more Lua trickery you can convert a Code el-
> ement with or without a class into a Span element
> with a custom-style attribute.
It is a great impovement that makes Pandoc treat
verbatime elements in headers in the true WYSWYM
manner.
> Updated filter and md file below and attached.
> Currently the class check is commented out in the
> filter to show that it is not strictly needed.
> Sorry for the lapse!
Come on! You have solved my problem in three ways,
every next better than the previous :-)
--
Please, do not forward replies to my e-mail.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Verbatim text in headers
[not found] ` <20200808151809.d2878d07de78b0b3f6606673-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
@ 2020-08-08 15:33 ` BPJ
2020-08-08 17:16 ` John MacFarlane
1 sibling, 0 replies; 15+ messages in thread
From: BPJ @ 2020-08-08 15:33 UTC (permalink / raw)
To: pandoc-discuss
[-- Attachment #1: Type: text/plain, Size: 2576 bytes --]
> > Then in your reference DOCX define the "Heading 1
> > Verbatim" "Heading 2 Verbatim" etc. styles, pre-
>
> > sumably as inheriting from "Verbatim Char" as you
> > wish and you are good to go.
>
> That would be redundant manual work, for a WYSWYM
> system should automatically infer the font size and
> style for a verbatim block depending on context. Can
> Lua filter do it? Can it read the font size from the
> heading style and automatically calculate the font
> size of the code block based on that?
There is no way to *define* a DOCX style in Markdown or Lua, but if you use
a custom-style attribute for which there is no style defined in the
reference document Pandoc creates a stub style inheriting from the default
style without modifications. It is quite easy to create a stub Markdown
file with only headings at as many levels you need with some code in them,
then create a file using the filter and your existing reference doc. Open
that file and modify each stub style to inherit from "Verbatim Char" and to
have the font size you want, and from then on use that file as reference
doc. It's *some* repetitive manual work but not very much.
Sorry about the misindented curly brackets. Lua doesn't actually care
about indentation, only about a balanced count of opening and closing
brackets or balanced `end` keywords for each `function`/`then`/`do`
keyword, so I didn't notice at first.
A Lua filter is a table mapping element type names (plus some generics like
Inline) to functions. My generator function takes the level of the
heading, creates a custom-style name from it, then returns a filter with a
closure which will take a Code element and "convert" it into a "normal"
span with a custom-style attribute with the generated style name. By
calling `pandoc.walk_block` within the Header handling function with the
Header element and the generated filter as argument the filter is applied
to Code elements within the Header element only. Note that the element
passed to `pandoc.walk_block` or `pandoc.walk_inline` is not changed
in-place; you have to use the return value of the function, which is a
different object.
--
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/CADAJKhC8GAockGYu6sWNZ1_MhpxuVNy-3AUjeJzBPCtUZxDM_w%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 3450 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Verbatim text in headers
[not found] ` <20200808151809.d2878d07de78b0b3f6606673-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2020-08-08 15:33 ` BPJ
@ 2020-08-08 17:16 ` John MacFarlane
[not found] ` <m2sgcxjbxo.fsf-pgq/RBwaQ+zq8tPRBa0AtqxOck334EZe@public.gmane.org>
1 sibling, 1 reply; 15+ messages in thread
From: John MacFarlane @ 2020-08-08 17:16 UTC (permalink / raw)
To: Anton Shepelev, pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw
Anton Shepelev <anton.txt-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
> Hmmm, no way to split long headings over several
> lines? Does that mean I cannot have an 90-character
> heading and keep the source at 72 characters per
> line? Maybe Markdown should provide a facility to
> specify long on on several source lines based either
> on the prefix or on the indent, e.g.:
>
> ## This is a long long long long long long long
> long long long long long lonesome heading
> split into three lines using list-like syntax
Actually, commonmark allows multiline setext-style
headings, like this:
This is a long long long long long long long
long long long long long lonesome heading
split into three lines using list-like syntax
---------------------------------------------
But not axt-style (##).
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Verbatim text in headers
[not found] ` <m2sgcxjbxo.fsf-pgq/RBwaQ+zq8tPRBa0AtqxOck334EZe@public.gmane.org>
@ 2020-08-09 8:22 ` BPJ
2020-08-10 21:00 ` Anton Shepelev
0 siblings, 1 reply; 15+ messages in thread
From: BPJ @ 2020-08-09 8:22 UTC (permalink / raw)
To: pandoc-discuss
[-- Attachment #1: Type: text/plain, Size: 2265 bytes --]
The limitation doesn't seem necessary in either case. Either everything
from the preceding blank line to the line of dashes is a setext heading, or
everything between two blank lines which starts with one or more hashes is
an atx heading.
That said it's probably good style in a modern text in any language not to
have very long headings, so IMO the limitation isn't a big problem.
--
Better --help|less than helpless
Den lör 8 aug. 2020 19:17John MacFarlane <jgm-TVLZxgkOlNX2fBVCVOL8/A@public.gmane.org> skrev:
> Anton Shepelev <anton.txt-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>
> > Hmmm, no way to split long headings over several
> > lines? Does that mean I cannot have an 90-character
> > heading and keep the source at 72 characters per
> > line? Maybe Markdown should provide a facility to
> > specify long on on several source lines based either
> > on the prefix or on the indent, e.g.:
> >
> > ## This is a long long long long long long long
> > long long long long long lonesome heading
> > split into three lines using list-like syntax
>
> Actually, commonmark allows multiline setext-style
> headings, like this:
>
> This is a long long long long long long long
> long long long long long lonesome heading
> split into three lines using list-like syntax
> ---------------------------------------------
>
> But not axt-style (##).
>
> --
> 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/m2sgcxjbxo.fsf%40johnmacfarlane.net
> .
>
--
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/CADAJKhAZHP%2Bu7h5QUXpXXb2tmemVLDbeeGoFWYOd13EX8OhAYA%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 3410 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Verbatim text in headers
2020-08-09 8:22 ` BPJ
@ 2020-08-10 21:00 ` Anton Shepelev
0 siblings, 0 replies; 15+ messages in thread
From: Anton Shepelev @ 2020-08-10 21:00 UTC (permalink / raw)
To: pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw
John MacFarlane:
> Actually, commonmark allows multiline setext-style
> headings, like this:
>
> This is a long long long long long long long
> long long long long long lonesome heading
> split into three lines using list-like syntax
> ---------------------------------------------
>
> But not axt-style (##).
Thanks. I did not know it and thought both syntaxes
equal in power. It is shame they are not, because I
much prefer ATX style.
PBJ:
> The limitation doesn't seem necessary in either
> case. Either everything from the preceding blank
> line to the line of dashes is a setext heading, or
> everything between two blank lines which starts
> with one or more hashes is an atx heading.
ATX headings do not need a blank line, to begin
with, which is why I proposed another rule for mul-
tiline ATX headings.
> That said it's probably good style in a modern
> text in any language not to have very long head-
> ings, so IMO the limitation isn't a big problem.
You are correct, and that applies to computer pro-
grams too, but for reasons of generality all good
WYSWYM systems and programming languages have provi-
sions for breaking up of *any* text into shorter
lines, for exceptions will occur. I can find myself
in need of writing a 73-character heading any day
now, and I don't what to dread that moment :-)
--
Please, do not forward replies to my e-mail.
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2020-08-10 21:00 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-08-05 14:00 Verbatim text in headers Anton Shepelev
2020-08-06 20:17 ` Anton Shepelev
[not found] ` <20200806231710.dd08c7f61a90ea23c708d507-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2020-08-06 20:38 ` Leonard Rosenthol
2020-08-06 20:57 ` Anton Shepelev
[not found] ` <20200806235733.6c944e913ef52f26b00c2f09-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2020-08-06 21:04 ` Dmitriy Krasilnikov
2020-08-06 21:17 ` Leonard Rosenthol
2020-08-06 21:38 ` Anton Shepelev
2020-08-07 9:09 ` BPJ
[not found] ` <14a2d64c-3044-5d89-0412-fc06c7f40a7c-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2020-08-07 9:35 ` Benct Philip Jonsson
[not found] ` <389fb88b-aadf-9cfc-3061-9c2dde74bccd-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2020-08-07 9:38 ` Benct Philip Jonsson
2020-08-08 12:18 ` Anton Shepelev
[not found] ` <20200808151809.d2878d07de78b0b3f6606673-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2020-08-08 15:33 ` BPJ
2020-08-08 17:16 ` John MacFarlane
[not found] ` <m2sgcxjbxo.fsf-pgq/RBwaQ+zq8tPRBa0AtqxOck334EZe@public.gmane.org>
2020-08-09 8:22 ` BPJ
2020-08-10 21:00 ` Anton Shepelev
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).