Code tags are described in a footnote within Perl Monks Approved HTML tags as follows:

2<code> and <c>, used for displaying code/data, are not true HTML tags, but are interpreted by the PerlMonks engine. They inhibit the normal interpretation of enclosed HTML special characters like <, >, &, [, and ]. Any newlines in the enclosed code will be rendered such that long lines wrap....

However, this is not always the case. Looking at the recent thread Regex string trimming help, I noticed that the display was significantly wider than my (wide!) monitor, because the first block of code in the OP was not wrapping (whereas the same code in tybalt89’s reply was wrapping as expected). As a janitor I was able to fix this by putting the opening and closing <code> tags in the first code block of the OP onto separate lines. So the description in Perl Monks Approved HTML tags is not true for inline code.

Is this a bug, or the intended behaviour? I suspect it’s the latter. In which case, should the explanation in Perl Monks Approved HTML tags (and perhaps also in Markup in the Monastery) be changed to reflect the fact that line wrapping occurs only when the code tags are separated from the enclosed text by line breaks, but not when they are inlined?

Although the problem of over-wide nodes arising from <code>-tagged lines that don’t wrap is not overly common, I do think it arises often enough to make this an issue worth addressing.

Thanks,

Athanasius <°(((><contra mundum Iustus alius egestas vitae, eros Piratica,

Replies are listed 'Best First'.
Re: Inline code tags don't line-wrap
by kcott (Archbishop) on Dec 19, 2016 at 09:31 UTC

    G'day Athanasius,

    I first came across this a long time ago and decided that it was a feature to allow this sort of markup in paragraph text (without adding any [download] links):

    <p>
    ... wrap in <c><code>...</code></c> or <code><c>...</c></code> tags.
    </p>
    

    which renders as:

    ... wrap in <code>...</code> or <c>...</c> tags.

    Now that you've fixed "Regex string trimming help", I can't see the effect there; however, I have noted it from time to time. I think an update to the doco would be useful. I also think that, if these tags are embedded in paragraph text, they should be subject to the same line-wrapping policy as the rest of the paragraph.

    — Ken

Re: Inline code tags don't line-wrap
by choroba (Cardinal) on Dec 19, 2016 at 09:16 UTC
    I've learned the described behaviour from experience, and I've never thought about whether it's documented. It's definitely worth mentioning somewhere.

    ($q=q:Sq=~/;[c](.)(.)/;chr(-||-|5+lengthSq)`"S|oS2"`map{chr |+ord }map{substrSq`S_+|`|}3E|-|`7**2-3:)=~y+S|`+$1,++print+eval$q,q,a,
Re: Inline code tags don't line-wrap
by LanX (Saint) on Dec 19, 2016 at 11:26 UTC
    Hi Athanasius

    You are implicitly addressing several questions.

    Where

    As so often the documentation is dispersed over several semi redundant pages.

    Markup in the Monastery demonstrates the double DWIM nature of code blocks, ie inline without download link (without mentioning wrapping)

    Why

    Since the intention as stated is to mark ...

    "code and data (which can be cut and pasted direct from your editor)"

    ... and a download link is missing, you can't allow automatic wrapping!

    Automated wrapping means you'd get plus signs breaking the code when copying.

    How

    Personally I hate those cases with overly long lines happening and I think the solution is trivial:

    Feature request: Inline code over 80 characters should be treated like multi line, ie get an additional download link and be wrapped!

    Reasoning: >95% of the cases so far where careless posters, I'd rather prefer to apologize to the remaining <5% and hear their justification, why they don't want a download link.

    Cheers Rolf
    (addicted to the Perl Programming Language and ☆☆☆☆ :)
    Je suis Charlie!

Re: Inline code tags don't line-wrap
by ww (Archbishop) on Dec 19, 2016 at 13:23 UTC

    First case: in this case, the code-tag-enclosed items are purely inline; no preceeding newlines:

    This is a test of a short  code segment where the code tag occurs in line -- that is, without a preceeding newline -- and this  is a far more verbose example of nothing in particular except that it is much longer; in fact, so long that it this second clause exceeds the width of the text entry box into which this is being typed. This part of the para follows a space after the closing code tag.

    Note that the neither placeholder above displays a download link, and the second is rendered without a + continuation symbol.

    Second Case -- in which the code tag stands after closing the paragraph tag and at the beginning of the second new line following the close_para_tag:

    Simulated Error:  use of &lt;c> tags beginning on new lines, (but still inside para tags) to enclose content which is mostly non-sense except for its value as a long, verbose example of code-tag enclosed text which could have begun on its own line.

    We still have no line break because (??) none exists inside the code tags. Note that despite the tags, we may not be rendering as desired.

    In our third case, we post the with the same markup & essentially the same text as immediately above...except that there is a newline after ' example of' in the text inside <c> </c> tag pair:

    Simulated Error: use of &lt;c> tags beginning on new lines, (but stil +l inside para tags) to enclose content which is mostly non-sense except for its + value as a long, verbose example of code-tag enclosed text which cou +ld have begun on its own line.

    Note that despite the length, we may not be rendering as desired (i.e., no download link), for reasons obscure to my caffeine-deprived brain Duh, because the download link appears (exists) only AFTER the post is actually created.


    Quis custodiet ipsos custodes. Juvenal, Satires