Skip to content

Add all inline elements to avoid wrong space breaking#76

Open
sorawee wants to merge 2 commits into
greghendershott:masterfrom
sorawee:master
Open

Add all inline elements to avoid wrong space breaking#76
sorawee wants to merge 2 commits into
greghendershott:masterfrom
sorawee:master

Conversation

@sorawee

@sorawee sorawee commented Nov 8, 2018

Copy link
Copy Markdown

Fix #75

@sorawee

sorawee commented Nov 8, 2018

Copy link
Copy Markdown
Author

Note: the failure in travis-ci is due to nondeterminism of the setup. It's not related to my PR. You can request for a rebuild (I don't have a permission to do so), and it probably will now pass.

@greghendershott

greghendershott commented May 1, 2019

Copy link
Copy Markdown
Owner

I've been swamped and only recently was able to dig in and think about this.

  • I like the idea of using the updated HTML5 inline elements.

  • I'm unsure about changing the behavior so that there isn't a leading newline, anymore.

Many years ago when I was new to Racket, I found it strange that this writes a leading newline:

(require xml)
(display-xml/content
 (document-element
  (read-xml (open-input-string
             "<html></html>"))))

=>


<html>
</html>

And then in the Racket web-server I saw it wrote a doctype, but not a newline, followed by display-xml. The leading newline from the latter, seemed to be an intentional feature.

So when I did this markdown package for use in frog, I emulated this in display-xexpr.

That was what was nagging at me, about this PR. I knew there was something, but I couldn't find time to focus and recall that.


Fast forward some years, and frog doesn't even use display-xexpr anymore to write the page. It switched to using webserver/templates. So the change would be N/A for Frog.

However I wonder if it would break anything else. e.g. Pollen uses this package.


TL;DR I think the PR is good, except we should keep the leading newline. If that really bugs you, then we should add an optional keyword argument for it, which defaults to true for backward compatibility.

@greghendershott

Copy link
Copy Markdown
Owner

@sorawee If you're reading this in email, the previous comment is better read here on GitHub -- I made a few edits to clarify. I don't think GitHub re-sends edits as emails.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

xexpr->string screws up whitespace

2 participants