public inbox archive for pandoc-discuss@googlegroups.com
 help / color / mirror / Atom feed
From: BPJ <bpj-J3H7GcXPSITLoDKTGw+V6w@public.gmane.org>
To: pandoc-discuss <pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>
Subject: Re: pandoc adds awkward HTML newlines inside inline verbatim backticks
Date: Tue, 20 Sep 2022 21:00:32 +0200	[thread overview]
Message-ID: <CADAJKhAt93qO8f3yDk8irfr6k05s+K_W+CbkK3tUcBUDa8U2ZQ@mail.gmail.com> (raw)
In-Reply-To: <509c8bfc-034d-4bfa-8227-87e253d9ca80n-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>

[-- Attachment #1: Type: text/plain, Size: 6832 bytes --]

Den tis 20 sep. 2022 02:41Ian Allen <idallen-4AaKEnNpRjew5LPnMra/2Q@public.gmane.org> skrev:

> Oh I am so sorry not to have checked the latest version of pandoc, which
> indeed does not have the bug.
> I guess I figured that since the last time I ran into problems with
> verbatim elements was in 2013 that nothing had changed since then.
> So sorry to waste your time.  The new pandoc works just fine.
>
> I still wish that there were a clean way to write inline verbatim elements
> that could distinguish between `pre-wrap` and `pre` without having to tag
> them all with `{.mycode}`.  I have teaching materials full of inline
> verbatim example shell command lines (such as `ls -l /usr/bin`) and I
> don't want them to wrap on output, but other verbatim elements I *do* want
> to wrap.
>

Well classes are meant to be used to mark such distinctions and others. You
can always use a less intrusive one-letter class like `{.w}` for "wrap".


> On Monday, September 19, 2022 at 12:23:59 p.m. UTC-4 fiddlosopher wrote:
>
>> I think you'll find this is fixed in recent versions of pandoc. It's
>> always helpful if you say which version you're running when reporting an
>> issue, but I infer it's an older version, because with the current version
>> I get breaks in the right places. See:
>>
>>
>> https://pandoc.org/try/?params=%7B%22text%22%3A%22%25+Test+file+one%5Cn%5Cn%60unbroken+line+of+code%60+and%5Cn%60unbroken+line+of+code%60+and%5Cn%60unbroken+line+of+code%60+and%5Cn%60unbroken+line+of+code%60+and%5Cn%60unbroken+line+of+code%60+and%5Cn%60unbroken+line+of+code%60+and%5Cn%60unbroken+line+of+code%60+and%5Cn%60unbroken+line+of+code%60+and%5Cn%22%2C%22to%22%3A%22html5%22%2C%22from%22%3A%22markdown%22%2C%22standalone%22%3Afalse%2C%22embed-resources%22%3Afalse%2C%22table-of-contents%22%3Afalse%2C%22number-sections%22%3Afalse%2C%22citeproc%22%3Afalse%2C%22html-math-method%22%3A%22plain%22%2C%22wrap%22%3A%22auto%22%2C%22highlight-style%22%3Anull%2C%22files%22%3A%7B%7D%2C%22template%22%3Anull%7D
>>
>> If you don't want to upgrade, there's a simple solution for you:
>>
>> --wrap=preserve
>>
>> This will preserve the line breaks in the source markdown instead of
>> automatically rewrapping.
>>
>>
>>
>> > On Sep 19, 2022, at 2:21 AM, Ian Allen <ida...-4AaKEnNpRjew5LPnMra/2Q@public.gmane.org> wrote:
>> >
>> > This is my input using inline verbatim backticks:
>> > ~~~~~
>> > % Test file one
>> >
>> > `unbroken line of code` and
>> > `unbroken line of code` and
>> > `unbroken line of code` and
>> > `unbroken line of code` and
>> > `unbroken line of code` and
>> > `unbroken line of code` and
>> > `unbroken line of code` and
>> > `unbroken line of code` and
>> > ~~~~~
>> > Command line: `pandoc -s i.md -o i.html`
>> >
>> > In the HTML output, pandoc inserts unhelpful newlines in the middle of
>> the code elements (excerpt from `i.html` output file):
>> > ~~~~~
>> > <p><code>unbroken line of code</code> and <code>unbroken line of
>> > code</code> and <code>unbroken line of code</code> and <code>unbroken
>> > line of code</code> and <code>unbroken line of code</code> and
>> > <code>unbroken line of code</code> and <code>unbroken line of
>> > code</code> and <code>unbroken line of code</code> and</p>
>> > ~~~~~
>> > Pandoc uses `code{white-space: pre-wrap;}` to format code, and so my
>> browser [preserves the newlines](
>> https://developer.mozilla.org/en-US/docs/Web/CSS/white-space) that
>> pandoc unhelpfully added:
>> > ~~~~~
>> > unbroken line of code and unbroken line of
>> > code and unbroken line of code and unbroken
>> > line of code and unbroken line of code and unbroken line of code and
>> unbroken line of
>> > code and unbroken line of code and
>> > ~~~~~
>> > This is not pretty and I can't imagine anyone would want this output
>> with the added newlines placed there randomly by pandoc. I did not add
>> those newlines. (I can't protect the spaces by with backslashes inside a
>> verbatim element; the backslashes are treated literally.)
>> >
>> > What I want is pandoc HTML output that does not add extra newlines in
>> the middle of code elements. For example, this would work as HTML output:
>> > ~~~~~
>> > <p><code>unbroken line of code</code> and <code>unbroken line of
>> code</code>
>> > and <code>unbroken line of code</code> and <code>unbroken line of
>> code</code>
>> > and <code>unbroken line of code</code> and <code>unbroken line of
>> code</code>
>> > and <code>unbroken line of code</code> and <code>unbroken line of
>> code</code>
>> > and</p>
>> > ~~~~~
>> > Then I would be able to choose between `code{white-space: pre-wrap;}`
>> and `code{white-space: pre;}` to format the code elements:
>> > ~~~~~
>> > `this is a standard pandoc verbatim element that wraps on output` but
>> > `this is one that I can tag and use my own CSS not to wrap`{.mycode}
>> > ~~~~~
>> > For the wish list: I wish that there were a clean way to write inline
>> verbatim elements that could distinguish between `pre-wrap` and `pre`
>> without having to tag them all with `{.mycode}`. I have teaching materials
>> full of inline verbatim example shell command lines (such as `ls -l
>> /usr/bin`) and I don't want newlines inserted into the middle of those
>> examples, and I don't want them to wrap on output, either.
>> >
>> > --
>> > 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/18a76e36-b390-4dff-8ee7-68623df03ad0n%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/509c8bfc-034d-4bfa-8227-87e253d9ca80n%40googlegroups.com
> <https://groups.google.com/d/msgid/pandoc-discuss/509c8bfc-034d-4bfa-8227-87e253d9ca80n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>

-- 
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/CADAJKhAt93qO8f3yDk8irfr6k05s%2BK_W%2BCbkK3tUcBUDa8U2ZQ%40mail.gmail.com.

[-- Attachment #2: Type: text/html, Size: 9623 bytes --]

  parent reply	other threads:[~2022-09-20 19:00 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-19  9:21 Ian Allen
     [not found] ` <18a76e36-b390-4dff-8ee7-68623df03ad0n-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>
2022-09-19 16:23   ` John MacFarlane
     [not found]     ` <65F8BFF6-B443-4A24-836F-5D0706159EFB-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2022-09-20  0:40       ` Ian Allen
     [not found]         ` <509c8bfc-034d-4bfa-8227-87e253d9ca80n-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>
2022-09-20 19:00           ` BPJ [this message]
     [not found]             ` <CADAJKhAt93qO8f3yDk8irfr6k05s+K_W+CbkK3tUcBUDa8U2ZQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2022-09-20 19:10               ` wanting a clean way to write inline verbatim elements with/without wrap Ian Allen
     [not found]                 ` <2c037fb7-c3d3-42bf-8ac8-8a9f0ffe650bn-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>
2022-09-20 19:16                   ` Albert Krewinkel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CADAJKhAt93qO8f3yDk8irfr6k05s+K_W+CbkK3tUcBUDa8U2ZQ@mail.gmail.com \
    --to=bpj-j3h7gcxpsitlodktgw+v6w@public.gmane.org \
    --cc=pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).