.code-inline whitspace: pre

[Peter Seibel]

I find the styling of .code-inline with whitespace: pre a bit surprising. That means if I have a <c> element that happens to get broken across a line in my source I end up with a line break in my HTML output. Which is particularly painful when I'm auto-formatting PtX and wrapping paragraphs and end up with something like this:

    significant in Java so <c>x =- 1</c> is just a funny way of writing <c>x =
    -1</c>, i.e. assigning the value <c>-1</c> to <c>x</c>. Thus the compound

Note the where the line break is on the first line. Obviously I could fix that up by joining the lines but then the next time I autowrap it it'll come back.

Can I interest you in a PR where I take out that whitespace clause?

[Rob Beezer]

Dear Peter,

What does your PDF look like when you put a newline inside a #c in your source?

Rob

[Peter Seibel]

Dunno, we never generate PDFs. I just tried but it failed due to 

CRITICAL: PTX:ERROR: cannot locate executable with configuration name `LatexEngine.XELATEX` as command `xelatex`

when I ran:

uv run pretext build pdf

(I used uv to install pretext into my virtual env.)

--
You received this message because you are subscribed to a topic in the Google Groups "PreTeXt development" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/pretext-dev/3sdUN0kJghk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to pretext-dev...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/MTAwMDAxNi5iZWV6ZXI.1748053492%40pnsh.

--

BHS Bell Schedule app: https://gigamonkeys.com/misc/bhs/

[Peter Seibel]

I tried installing MacTeX but that didn't help. The web is surprisingly confusing about what you actually need to install to get xelatex

[Rob Beezer]

Well, maybe you don't even have TeX installed then, or on your path. Thanks for trying.

We make PDF all the time. Producing a variety of output formats is a big part of what we are about. Some people even like *printed* books. ;-)

I'll run an experiment when I am next in front of a keyboard.

Rob

[Andrew Scholer]

I think that change would be a mistake. Trying to guess what the author meant with regards to whitespace instead of producing what was authored is dangerous in elements designed to contain code or code-like content.

Presumably if your tool turns:

    <c>blah blah blah<c>

Into:

    <c>blah blah
          blah<c>

You also would then want the leading spaces removed from before the last blah.

How do we differentiate that from a case where the author wants spaces? There are going to be times when authors want to represent multiple consecutive spaces faithfully inside a <c>. (I am one of them and I am guessing at some point you will find a spot where you need to do so as well Peter.) The ability to do that should trump trying to undo what an auto-formatter might have done to the source.

If the problem is your formatting tool breaks lines within <c>, I think the fix is to tell it not to. Or find an XML aware tool that you can tell not to. There are likely going to be a handful of tags you want to do that for:

<c>
<pf>

<cline>
<program> (and/or its subparts like <code>, <tests>, etc...)
<console> (and/or its subparts <input> and <output>)

Andrew Scholer (he/him/his)

Computer Science Instructor

Chemeketa Community College

503.589.7649 

computerscience.chemeketa.edu/people/andrew-scholer/

You received this message because you are subscribed to the Google Groups "PreTeXt development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pretext-dev...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/MTAwMDAwMC5iZWV6ZXI.1748056364%40pnsh.

[Rob Beezer]

Agreed, and said better than I would have.

#c is meant to be very short pieces of text. Identifiers, keywords, commands,
maybe even (short) user entry. Short enough that LaTeX can right-justify
without spilling into the margin. Not code snippets.

#cd, with or without #cline is meant for bigger stuff (that is not a #program).
And #pre is like a peer of a paragraph.

#c/#cline and #pre will preserve leading space to enable meaningful
indentation. #c is not meant to do that (and is not doing it for LaTeX/PDF).

Rob

> computerscience.chemeketa.edu/people/andrew-scholer/ <http://

> computerscience.chemeketa.edu/people/andrew-scholer/>
>
>
> On Fri, May 23, 2025 at 8:12 PM 'Rob Beezer' via PreTeXt development <pretext-
> d...@googlegroups.com <mailto:prete...@googlegroups.com>> wrote:
>
> Well, maybe you don't even have TeX installed then, or on your path.  Thanks
> for trying.
>
> We make PDF all the time.  Producing a variety of output formats is a big
> part of what we are about.  Some people even like *printed* books. ;-)
>
> I'll run an experiment when I am next in front of a keyboard.
>
> Rob
>
>
>
> On May 23, 2025 7:32:58 PM PDT, Peter Seibel <peter...@berkeley.net

> <mailto:peter...@berkeley.net>> wrote:
> >Dunno, we never generate PDFs. I just tried but it failed due to
> >
> >CRITICAL: PTX:ERROR: cannot locate executable with configuration name
> >`LatexEngine.XELATEX` as command `xelatex`
> >
> >when I ran:
> >
> >uv run pretext build pdf
> >
> >
> >(I used uv to install pretext into my virtual env.)
> >
> >On Fri, May 23, 2025 at 7:24 PM 'Rob Beezer' via PreTeXt development <
> >prete...@googlegroups.com <mailto:prete...@googlegroups.com>> wrote:
> >
> >> Dear Peter,
> >>
> >> What does your PDF look like when you put a newline inside a #c in your
> >> source?
> >>
> >> Rob
> >>
> >> On May 23, 2025 4:59:43 PM PDT, Peter Seibel <peter...@berkeley.net

> <mailto:peter...@berkeley.net>>

> >> wrote:
> >> >I find the styling of .code-inline with whitespace: pre a bit surprising.
> >> >That means if I have a <c> element that happens to get broken across a
> >> line
> >> >in my source I end up with a line break in my HTML output. Which is
> >> >particularly painful when I'm auto-formatting PtX and wrapping paragraphs
> >> >and end up with something like this:
> >> >
> >> >    significant in Java so <c>x =- 1</c> is just a funny way of writing
> >> ><c>x =
> >> >    -1</c>, i.e. assigning the value <c>-1</c> to <c>x</c>. Thus the
> >> >compound
> >> >
> >> >Note the where the line break is on the first line. Obviously I could fix
> >> >that up by joining the lines but then the next time I autowrap it it'll
> >> >come back.
> >> >
> >> >Can I interest you in a PR where I take out that whitespace clause?
> >> >
> >>
> >> --
> >> You received this message because you are subscribed to a topic in the
> >> Google Groups "PreTeXt development" group.
> >> To unsubscribe from this topic, visit
> >> https://groups.google.com/d/topic/pretext-dev/3sdUN0kJghk/unsubscribe

> <https://groups.google.com/d/topic/pretext-dev/3sdUN0kJghk/unsubscribe>.

> >> To unsubscribe from this group and all its topics, send an email to

> >> pretext-dev...@googlegroups.com <mailto:pretext-
> dev%2Bunsu...@googlegroups.com>.

> >> To view this discussion visit
> >> https://groups.google.com/d/msgid/pretext-dev/

> MTAwMDAxNi5iZWV6ZXI.1748053492%40pnsh <https://groups.google.com/d/msgid/
> pretext-dev/MTAwMDAxNi5iZWV6ZXI.1748053492%40pnsh>

> >> .
> >>
> >
> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "PreTeXt development" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to pretext-dev...@googlegroups.com <mailto:pretext-
> dev%2Bunsu...@googlegroups.com>.

> To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/

> MTAwMDAwMC5iZWV6ZXI.1748056364%40pnsh <https://groups.google.com/d/msgid/
> pretext-dev/MTAwMDAwMC5iZWV6ZXI.1748056364%40pnsh>.

>
> --
> You received this message because you are subscribed to the Google Groups
> "PreTeXt development" group.
> To unsubscribe from this group and stop receiving emails from it, send an email

> to pretext-dev...@googlegroups.com <mailto:pretext-
> dev+uns...@googlegroups.com>.

> To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/

> CACm44N8j1wV4wAg9S4PXtx3CfkhTSPvK2YfizQ4q5RQX9meAPw%40mail.gmail.com <https://
> groups.google.com/d/msgid/pretext-dev/
> CACm44N8j1wV4wAg9S4PXtx3CfkhTSPvK2YfizQ4q5RQX9meAPw%40mail.gmail.com?
> utm_medium=email&utm_source=footer>.

[Peter Seibel]

It's exactly because <c> is meant for short snippets that I want it to treat whitespace as normal not pre. It seems to me it is, in HTML terms, an inline element. And as far as I know there are no HTML elements that are by default styled with display: inline and white-space: pre. When I put a <c> in a <p> I don't care about whitespace because it's an inline element. If I wanted an actual block of code where line breaks and indentation were used I would use <cline> or <pre>.

Andrew, can you give an example of when you want to control whitespace within a paragraph?

To unsubscribe from this topic, visit https://groups.google.com/d/topic/pretext-dev/3sdUN0kJghk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to pretext-dev...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/MTAwMDA0NS5iZWV6ZXI.1748101152%40pnsh.

[Peter Seibel]

Reading this (from https://pretextbook.org/doc/guide/html/overview-verbatim-literal.html):

 

For short bits of such text, as part of a sentence in a paragraph, or in a caption or title, use the <c> tag, which is short for “code.” For much longer blocks of literal text, with line breaks that are to be preserved, use the <cd> element within a paragraph (“code display”).

I'd expect <c> to be the one that would ignore whitespace and <cd> to be the one that preserves it. My understanding was that <c> was basically a way to say, "Set this in a monospace font, appropriate for code". Is that not what it's for?

[David W. Farmer]

I think it is a tall order to make a case that PreTeXt needs to
adapt to idiosyncrasies of how an editing program does line wrapping.

I also think it is a challenge to argue why one tag designed to hold
code should behave one way, and another tag to hold code behaves another.

As was noted, there is a really simple way around this: set the editing
program to not break lines inside a `c`.

Regards,

David

> To view this discussion visithttps://groups.google.com/d/msgid/pretext-dev/CAMiqbm%3Da0m8%3Dz4pVXCQ5aF-HNqSFd0ysByAGMn8DqGWBykS16Q%40mail.gmail.com
> .
>
>

[Peter Seibel]

I'd say don't think of it as about tools; think about it as how the author can express their intent. When I mark up something in <code>, <kbd>, <samp>, or <var> in HTML I'm saying, I want this to be semantically distinguished and likely visually as well. But I don't care about the whitespace in it. (They all default to white-space: normal in HTML.) When writing flowing text such as a paragraph it's weird to have to worry about where the line breaks go because the whole point is I don't care; the typesetter is going to take care of that.

I get why we want <pre> and <cd>. But it seems odd to have an inline element in the middle of a context where whitespace is not preserved, like a paragraph, that suddenly switches to preserving whitespace.

To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/28d2f38c-22e5-e4c1-7439-3bc8b01a5079%40aimath.org.

[Peter Seibel]

After some reflection, I think what I really want (and what I've set in the custom.css for CSAwesome for now) is for .code-inline to be styled as white-space: collapse nowrap. Since white-space: pre (the current styling) is just a synonym for white-space: preserve nowrap, this is maybe closer to how you are thinking about things. The point is if I have some PreText like this:

    <p>
      Compound assignment operators <c>+=</c>, <c>-=</c>, <c>*=</c>, <c>/=</c>,
      and <c>%=</c> are shortcuts that do a math operation and assignment in one
      step. For example, <c>x += 1</c> adds 1 to the current value of <c>x</c>
      and assigns the result back to <c>x</c>. It is the same as <c>x = x +
      1</c>. This pattern is possible with any operator put in front of the
      <c>=</c> sign, as seen below.
    </p>

I don't think I should have to worry about the fact that <c>x = x + 1</c> happens to have been broken across two lines in the source in a context where otherwise newline characters are just treated as equivalent to spaces. But note that thanks to the nowrap it would be rendered so that the whole unit stays together on one line which is consistent with the current PreText styling. That might make for some ugly lines if the <c> element is quite long but, as Rob says, that's not the purpose of <c> and the author could use <cd> instead.

I'm still very curious to see an example where someone uses the fact that newlines are preserved in a <c> element, especially since it also preserves the leading indentation. I.e. with the current default styling that paragraph above renders like this in HTML:

I'm having a hard time imagining when I'd want that. But maybe I lack imagination. If this really is the desired behavior, I guess I'd suggest you make more of a point of it in the PreText Guide. Maybe change the first paragraph of 3.16 to something like:

Typesetting literal text, usually in a monospace font, can sometimes be tricky. For short bits of such text, as part of a sentence in a paragraph, or in a caption or title, use the <c> tag, which is short for “code.” Note, that while  <c>  for the most part functions as an inline element, it does preserve line breaks and other white space so make sure not to wrap your source in the middle of a   <c> element if you do not want a line break and subsequent indentation in your rendered output. For much longer blocks of literal text, also with line breaks preserved, use the <cd> element within a paragraph (“code display”). Outside a paragraph, most anywhere you could place a regular paragraph, use the <pre> tag, which is short for “pre-formatted”.

Cheers!

[David W. Farmer]

I will make a case that the author has to think about the actual
spaces and line breaks in certain parts of the source.
This means that editing programs should be set to not break lines
inside certain tags.

My case will involve the inline math tag `m` because I understand
that use case. And for `m` tags the importance of white space is
not hypothetical, but is already several steps toward implementation.
I hope that this example is persuasive enough to apply to the `c` tag.

One of the last vestiges of LaTeX in PreTeXt is in math markup. That
is a violation of the first principle of PreTeXt, because it fails
to capture the structure of the document. (See the Readme in the
PreTeXt repository for the 11 principles.)

For example, inside `m` tags, currently these are equivalent:

g (x + u)

g(x + u)

In case your email reader doesn't make clear the difference, the first
one has a space after the g.

Now, suppose the author intended "g times the quantity x plus u".
Is that what someone using a screen reader would hear? If so,
then everyone is happy. But what if the author intended "g of
the quantity x plus u". Now nobody is happy, and the reader is
confused because "g" represents a number, so they have to backtrack
and realize that the pronunciation is wrong mathematically.

Pretty soon authors will be able to insert a space, or not,
to express their intent. That will be much better for anyone
using a screen reader. And it supports the 11th (a11y) principle.

Note: the infrastructure of this feature, which I call "Space Math",
already exists. What we have not yet had the time to do is figure
out how to have it selectively turned on and used in PreTeXt.

What happens if the line wrapping inserts a line break inside an `m`,
and that changes the mathematical meaning of the expression?
That would be bad. So, turn off auto wrapping inside `m`.
(To clarify: Space Math is about pronunciation, not meaning.)

As was mentioned previously, changing the behavior of `c` would
prevent the output from having two consecutive spaces. Maybe I
can't think of a use case for that now, but I am not willing to rule
it out. Especially since the issue can be addressed by preventing
wrapping for that inline tag, something that will also have
to be done for the `m` tag.

Regards,

David Farmer

On Sun, 25 May 2025, Peter Seibel wrote:

> After some reflection, I think what I really want (and what I've set in the custom.css for CSAwesome for now) is for
> .code-inline to be styled as white-space: collapse nowrap. Since white-space: pre (the current styling) is just a
> synonym for white-space: preserve nowrap, this is maybe closer to how you are thinking about things. The point is if I
> have some PreText like this:
>     <p>
>       Compound assignment operators <c>+=</c>, <c>-=</c>, <c>*=</c>, <c>/=</c>,
>       and <c>%=</c> are shortcuts that do a math operation and assignment in one
>       step. For example, <c>x += 1</c> adds 1 to the current value of <c>x</c>
>       and assigns the result back to <c>x</c>. It is the same as <c>x = x +
>       1</c>. This pattern is possible with any operator put in front of the
>       <c>=</c> sign, as seen below.
>     </p>
>
> I don't think I should have to worry about the fact that <c>x = x + 1</c> happens to have been broken across two lines
> in the source in a context where otherwise newline characters are just treated as equivalent to spaces. But note that
> thanks to the nowrap it would be rendered so that the whole unit stays together on one line which is consistent with
> the current PreText styling. That might make for some ugly lines if the <c> element is quite long but, as Rob says,
> that's not the purpose of <c> and the author could use <cd> instead.
> I'm still very curious to see an example where someone uses the fact that newlines are preserved in a <c> element,
> especially since it also preserves the leading indentation. I.e. with the current default styling that paragraph above
> renders like this in HTML:
>

> To view this discussion visithttps://groups.google.com/d/msgid/pretext-dev/CAMiqbmm_5HxCM-EV80eRVU1rRhwfb0BkWXMUa%2BrPauUDBW%3DhHA%40mail.gmail.com
> .
>
>

[Peter Seibel]

Okay, one last try speaking as a user, then I'll drop this if you're not convinced:

Seems to me the difference is you're saying that math notation uses significant whitespace, i.e. your example of g (x + u) being different from g(x + u). (Or maybe you're just saying that in PreText you are going to make whitespace significant in some way that will cause screen readers to read it the way you want?) That's fine, math is complicated and notationally complex. But programming languages for the most part don't treat whitespace in expressions as significant beyond its role in separating tokens. Obviously when writing multiline code preserving line breaks and indentation is critical but when using snippets of code inline in a paragraph it is not.

So I can see why you want <m> to be whitespace preserving because whitespace is significant. But while you posit a theoretical need for white space preservation in <c> elements I'm here to tell you, as someone who has written a lot about programming, that I've never wanted that. I just want to mark some snippets semantically and visually as code. I.e. I'd expect <c> to be more akin to <em> than it is to <m>.

But PreText is your baby. I'm just a user telling you that this behavior is counter intuitive and makes PreText harder to use. Not everyone working on a book uses the same tools so requiring everyone to use XML-aware editors that can be taught not to wrap lines inside certain elements is pushing a burden onto your users. I guess if I was using <m> elements I'd have to deal with this since white space is significant there but I'm just trying to write a book about programming.

For now I'm actually okay because we can override the CSS to get the behavior I want; hopefully you won't go out of your way to make that not work. But I hope you will at least consider my proposed change to your documentation because as it stands it is not clear at all what the behavior of <c> actually is since line-break preservation is only mentioned with regards to <cd>.

To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/dd319677-cac8-47c9-7876-76ef7fa53c5f%40aimath.org.

[Peter Seibel]

Dang it, I know I said that was my last but I just read more about SpaceMath and I think I understand better where you're coming from. So here's what I think is the thing; SpaceMath is a mini-language that applies within <m> elements (if I'm understanding correctly). So yes, if you're using that mini language in which whitespace is significant you need to take care to not mess with the significant whitespace. But in <c> elements PreText doesn't actually use whitespace for any semantic meaning. And in fact, again if I'm understanding correctly, by the time PreText has rendered the SpaceMath all the whitespace is gone, replaced (at least in HTML) with MathJax markup. That's very different from the <c> element where the whitespace is just passed through to the HTML to then be displayed one way or another. While using significant whitespace in SpaceMath is a clever way to solve the problem of disambiguating certain mathematical expressions without too much LaTeX style markup gorp it's a bit of an exception exactly because you are trying to build a special-purpose language in that one context of the <m> elements. (Or maybe <m> and some others?) So that leaves me more of the opinion that the proper element to compare <c> to is <em>, not <m>. Cheers!

[Rob Beezer]

Dear Peter, et al.,

<p>From my point-of-view, as the designer of #c, I never imagined an author (or
a tool) putting a newline within it as source. I think I will make that
expectation clearer in the documentation. And perhaps issue a warning? In the
old days, we expected #p to be written like this one you are reading now. A
consequence of not having the expertise to clean up allowing a more liberal
approach to whitespace. Nobody liked that.</p>

Technical details: #c is processed using an "xsl:value-of" instruction. That
presumes no markup, no processing, and no real changes after processing. Just a
copy of the characters present. Intentionally. Which is why you see so much
leading whitespace in your one example. If we switched to the more XSL-centric
"xsl:apply-templates", then the content would get pulled into an elaborate
template that cleans up *every* text node. (Well, it dances around math, as
David F has suggested, and maybe a few other things.) I have not experimented
to see what happens if I temporarily made that switch as an experiment. #em
must go through this clean-up template, too, so that would be a good scenario to
give a fresh look. This process also explains why you can type bare $, %, etc,
and get a LaTeX file that compiles.

Anyway, we were often too permissive in processing in the early days (witness
the mess that is #introduction to a division). Especially for HTML where
authors are just happy if their source makes something that "looks good." We
want your source to be of a quality that it "works" many years from now and
works for new formats we haven't imagined (early on we never imagined braille,
for one). We have made code now that more accurately reflects and enforces the
schema. (And speaking of braille, we don't get to handle this situation with a
dash of CSS).

> hopefully you won't go out of your way to make that not work

I don't think we have every gone out of our way (though I have been tempted!).
But similarly, the only promise we make is that correct source will render so
that it conveys your meaning and intent.

There are several people making progress on the day when authors will not write
in XML. That has always been the intent of this project. Many, many long
discussions over the years have created something that could never be done by
one person in a short time. I didn't think it would take this long, but
available resources mean progress can be slow.

Thank-you for taking the time to make suggestions that might improve PreTeXt.
In this case I would encourage you to make high-quality source, rather than an
HTML-only add-on. In the extreme, someday CSAwesome may have a blind reader,
and we really want to do all we can to keep their frustrations to a minimum.

Thanks,
Rob

[Peter Seibel]

Uh, in that case I think you have a bug in your PDF generation because it generates this:

From this source:

    <p>
      Compound assignment operators <c>+=</c>, <c>-=</c>, <c>*=</c>, <c>/=</c>,
      and <c>%=</c> are shortcuts that do a math operation and assignment in one
      step. For example, <c>x += 1</c> adds 1 to the current value of <c>x</c>
      and assigns the result back to <c>x</c>. It is the same as <c>x = x +
      1</c>. This pattern is possible with any operator put in front of the
      <c>=</c> sign, as seen below.
    </p>

Note how it wraps the <c>x = x + 1</c> rather than preserving the line break that exists in the PtX source.

Now, I'd rather you made the HTML match the PDF rather than the other way around. But certainly it seems they should be consistent.

It really seems like markup languages tend to not treat single newline characters as significant: e.g. HTML only does so in the context of <pre>, TeX only in \obeylines. I feel like exactly because you didn't imagine anyone putting a line break inside a <c> suggests that probably the behavior should be to be like other newlines and be treated as a space character. Human beings who edit text tend to break lines for their convenience other than in contexts where they are explicitly significant (multiline code, poetry, etc.) and prior art in markup languages is to accommodate that outside a few special contexts.

--
You received this message because you are subscribed to a topic in the Google Groups "PreTeXt development" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/pretext-dev/3sdUN0kJghk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to pretext-dev...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/MTAwMDA0OS5iZWV6ZXI.1748197082%40pnsh.

[Andrew Scholer]

Briefly as I'm on my phone and on the road.

I agree that there are inconsistencies between how whitespace in the various elements work. And that the documentation doesn't always clearly explain what is expected and why. 

I'm all in favor of cleaning those up. But still very much of the belief that code related entities need to respect white space as authored.

The article linked below is an interesting read as to why whitespace in HTML (and many other makeup languages) is fundamentally broken by permitting developer whitespace and trying to distinguish that from authored whitespace. 

https://blog.dwac.dev/posts/html-whitespace/

The discussion of the impossible bind tools like CMSs are in is particularly relevant. It  reinforced my belief that inside code related elements the strong default should be to assume that white space is authored content.

Andrew Scholer

You received this message because you are subscribed to the Google Groups "PreTeXt development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pretext-dev...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/CAMiqbm%3DiQcdd5jaO4rhCdCi_4Z0%2BcWiJoFgcGv15iecuNMnL_Q%40mail.gmail.com.

[Rob Beezer]

There was some discussion about this thread at Drop-In a few weeks ago, and I've
not been able to follow-up on that until now. And maybe that is good, since I
think some of my thoughts on this have changed.

I did a bit of refactoring, which has shored things up some. See recent post.

I think there are several things going on with Peter's original posts. At the
risk of mis-representing him, one is the desire to author a newline in the
middle of a #c for the convenience of breaking lines (automatically,
arbitrarily) in the middle of a #c that happens to have spaces, like a very
short code snippet.

I'll venture there is no other reason to have a newline in a #c (we have #cd,
#pre, etc for that) and so we can replace every newline with a space. That will
be easy (and consistent across outputs) with the recent refactoring.

I finally read the (long) post Andrew linked to, which was interesting. To a
point, where eventually I was just skimming. I'd already been thinking of the
above, but the post made me think that an intermediate newline is *meant* to
just be a line break and not a literal character, or a multi-line verbatim hunk,
or anything else. So let's accept it and convert it to the intent. (Which we
already do a lot of.)

There's more to discuss, but does anyone see any problems with this? And Peter,
is the above accurate? (So far, anyway.)

Rob

[Peter Seibel]

I think you've got what I was asking for in my original posts correct. Though Andrew gave me some good examples where whitespace is significant in <c> elements, e.g. if you want to show short snippets like in the following:

Note that <c>"  "</c> with two spaces is different than <c>" "</c> with just one space.

So I think there in fact three reasonable modes for whitespace in <c> elements: collapsing where all runs of whitespace, including line breaks, are turned into or rendered as a single space (as in HTML), preserving, where all whitespace is preserved exactly, and show which is like preserving except space characters are displayed with some visible character, such as in TeX with the ␣ character.

I usually want collapsing but I can see cases, like the example above, where preserving would be called for. And if you're going to talk about whitespace a lot show would also be useful.

--
You received this message because you are subscribed to a topic in the Google Groups "PreTeXt development" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/pretext-dev/3sdUN0kJghk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to pretext-dev...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/MTAwMDAwMC5iZWV6ZXI.1750180137%40pnsh.

[Rob Beezer]

> so we can replace every newline with a space. That will be easy (and
consistent across outputs) with the recent refactoring.

Nothing is ever as easy as you think. Place a newline in the middle of a #c (or
let your editor do it for you). In my editor, the line after the newline is
indented (to match surroundings), introducing a run of spaces.

We have an uber-template that sanitizes (almost) every text node, cleaning up
"stray" whitespace, so authors can be liberal in how they format their source.
The #c element quite rightly avoids employing this template. So I had to write
an ad-hoc template to pare-down all these extra spaces. THEN the newline can
become a space. Phew.

Pushed, just now. Please report any oddities.

Rob

[Rob Beezer]

> Andrew gave me some good examples where whitespace is significant in <c>
> elements, e.g. if you want to show short snippets like in the following:

Yes, this is exactly the way #c is conceived to work.

> So I think there in fact three reasonable modes for whitespace in <c> elements:

> *collapsing* where all runs of whitespace, including line breaks, are turned
> into or rendered as a single space (as in HTML), *preserving*, where all
> whitespace is preserved exactly, and *show *which is like preserving except

> space characters are displayed with some visible character, such as in TeX with
> the ␣ character.

And "collapsing" is not all the intent. Write what you want to see and that is
what you will get, that's the idea (and always has been). Now with the
exception of a newline, which we will assume is organizational formatting of
your source, not a literal character (or literal newline).

We already have a "show" option for #cd via a @showspaces attribute. Since
we make an effort there to preserve indentaion. See it in action at

Paragraph
https://pretextbook.org/examples/sample-article/html/section-pre-formatted.html#section-pre-formatted-12

I'd entertain a PR to add the same attribute to #c if it used similar/identical
techniques and tools.

Rob

On 6/17/25 10:54, Peter Seibel wrote:
> I think you've got what I was asking for in my original posts correct. Though
> Andrew gave me some good examples where whitespace is significant in <c>
> elements, e.g. if you want to show short snippets like in the following:
>
> Note that <c>"  "</c> with two spaces is different than <c>" "</c> with just
> one space.
>
>
> So I think there in fact three reasonable modes for whitespace in <c> elements:

> *collapsing* where all runs of whitespace, including line breaks, are turned
> into or rendered as a single space (as in HTML), *preserving*, where all
> whitespace is preserved exactly, and *show *which is like preserving except

> space characters are displayed with some visible character, such as in TeX with
> the ␣ character.
>
> I usually want collapsing but I can see cases, like the example above, where
> preserving would be called for. And if you're going to talk about whitespace a
> lot show would also be useful.
>

> pretext-dev/3sdUN0kJghk/unsubscribe <https://groups.google.com/d/topic/
> pretext-dev/3sdUN0kJghk/unsubscribe>.

> To unsubscribe from this group and all its topics, send an email to pretext-

> dev+uns...@googlegroups.com <mailto:pretext-
> dev%2Bunsu...@googlegroups.com>.

> To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/

> MTAwMDAwMC5iZWV6ZXI.1750180137%40pnsh <https://groups.google.com/d/msgid/
> pretext-dev/MTAwMDAwMC5iZWV6ZXI.1750180137%40pnsh>.
>
>
>
> --
> BHS Bell Schedule app: https://gigamonkeys.com/misc/bhs/ <https://
> gigamonkeys.com/misc/bhs/>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "PreTeXt development" group.

> To unsubscribe from this group and stop receiving emails from it, send an email

> to pretext-dev...@googlegroups.com <mailto:pretext-
> dev+uns...@googlegroups.com>.

> To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/

> CAMiqbmmVSJQhnUJL6YTPOMzX6zAnSn14_L1WWS%3DYR_NdoDWPJw%40mail.gmail.com <https://
> groups.google.com/d/msgid/pretext-dev/
> CAMiqbmmVSJQhnUJL6YTPOMzX6zAnSn14_L1WWS%3DYR_NdoDWPJw%40mail.gmail.com?
> utm_medium=email&utm_source=footer>.

[Rob Beezer]

OK, now we are back to the original question, I think. How does the content of
a #c element get marked up in the different output formats. LaTeX basically
uses the "\texttt" macro, which I think allows line-breaking, but maybe not
hyphenation? I'd have to check. And now to the subject line of this thread.
HTML markup via ".code-inline whitspace: pre" I think "whitespace: pre" is
exactly how I conceive of #c being rendered?

[Andrew Scholer]

I believe the recent posts  have not covered what should happen when a #c overlaps a natural line break location in the output typesetting. Should it wrap across two lines? Should the entire element be shifted to the next line (no-wrap)?

Assuming the desired behavior is no-wrap, then yes I think whitespace: pre is what you are picturing. 

I am strongly in the no-wrap camp. I think it looks bizarre if "int x = 1;" becomes "int x
= 1;"

Andrew Scholer (he/him/his)

Computer Science Instructor

Chemeketa Community College

503.589.7649 

computerscience.chemeketa.edu/people/andrew-scholer/

--
You received this message because you are subscribed to the Google Groups "PreTeXt development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pretext-dev...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/MTAwMDAxNy5iZWV6ZXI.1750283914%40pnsh.

[Rob Beezer]

On 6/19/25 00:17, Andrew Scholer wrote:
> I believe the recent posts  have not covered what should happen when a #c
> overlaps a natural line break location in the output typesetting.

Right. That's what I meant by the following. ;-)

>How does the content of a #c element get marked up in the different output
formats.

> Should it wrap
> across two lines? Should the entire element be shifted to the next line (no-wrap)?

Yes, I'm in the no-wrap camp, too. And if that ends up looking ugly, it means
your #c is too long and you should move to a #cd instead.

> Assuming the desired behavior is no-wrap, then yes I think whitespace: pre is
> what you are picturing.

OK.

At the moment, at first-blush, I'm thinking for LaTeX of converting regular
spaces into non-breaking spaces (<c>~</c>) which might be a sledge-hammer, but
it'll get the job done. TeXnicians with a better idea are invited to weigh-in.

Rob