Confusing issue with rendering code blocks #102

Closed
opened 3 years ago by leemeichin · 2 comments
leemeichin commented 3 years ago (Migrated from github.com)

I've been migrating a bunch of old Markdown files into Pollen Markup syntax. It's been a fairly uneventful process so far, which is great!

I'm seeing some unintuitive behaviour when trying to render a block of code, however. This behaves the same using a plain old pre tag, no syntax highlighting involved.

Take this snippet, for example:

#lang pollen

◊pre{
buf[0] = 0x00; // the register to be written to
buf[1] = 0x??; // the value to assign to that register
}

I'd expect the output to be a pre tag with no indentation, just this:

<pre>
buf[0] = 0x00; // the register to be written to
buf[1] = 0x??; // the value to assign to that register
</pre>

For reasons I don't understand, I'm instead getting an extra 6 characters of indentation on the second line.

<pre>
buf[0] = 0x00; // the register to be written to
      buf[1] = 0x??; // the value to assign to that register
</pre>

image

Inspecting the generated txexpr shows nothing untoward:

'(pre
  "buf[0] = 0x00; // the register to be written to"
  "\n"
  "buf[1] = 0x??; // the value to assign to that register")

The HTML when using view source is suspicious though:

image

It's as if the overall indentation of the generated HTML is being pulled into the content of the pre tag, which I'd want to be leftmosted aligned due to the sensitivity of the whitespace. This happens without using any of the provided decoding functions, so I'm at a loss here. This happens pretty consistently for every pre tag, no matter where it is in the document.

(Example post/repo in question here: https://git.sr.ht/~mrlee/pollen-experiment/tree/master/item/posts/gettin-ziggy-with-it-pi-zero.poly.pm)

Any thoughts?

I've been migrating a bunch of old Markdown files into Pollen Markup syntax. It's been a fairly uneventful process so far, which is great! I'm seeing some unintuitive behaviour when trying to render a block of code, however. This behaves the same using a plain old `pre` tag, no syntax highlighting involved. Take this snippet, for example: ```pollen #lang pollen ◊pre{ buf[0] = 0x00; // the register to be written to buf[1] = 0x??; // the value to assign to that register } ``` I'd expect the output to be a `pre` tag with no indentation, just this: ```html <pre> buf[0] = 0x00; // the register to be written to buf[1] = 0x??; // the value to assign to that register </pre> ``` For reasons I don't understand, I'm instead getting an extra 6 characters of indentation on the second line. ```html <pre> buf[0] = 0x00; // the register to be written to buf[1] = 0x??; // the value to assign to that register </pre> ``` ![image](https://user-images.githubusercontent.com/736291/120928704-adbf4e80-c6dd-11eb-873e-1625d70031e1.png) Inspecting the generated `txexpr` shows nothing untoward: ```racket '(pre "buf[0] = 0x00; // the register to be written to" "\n" "buf[1] = 0x??; // the value to assign to that register") ``` The HTML when using `view source` is suspicious though: ![image](https://user-images.githubusercontent.com/736291/120929556-68048500-c6e1-11eb-8574-7d1502b697ce.png) It's as if the overall indentation of the generated HTML is being pulled into the content of the `pre` tag, which I'd want to be leftmosted aligned due to the sensitivity of the whitespace. This happens without using any of the provided decoding functions, so I'm at a loss here. This happens pretty consistently for every `pre` tag, no matter where it is in the document. (Example post/repo in question here: https://git.sr.ht/~mrlee/pollen-experiment/tree/master/item/posts/gettin-ziggy-with-it-pi-zero.poly.pm) Any thoughts?
mbutterick commented 3 years ago (Migrated from github.com)

The file you linked to doesn’t contain any pre tags. Though the example below suggests the default behavior is correct.

#lang pollen/mode racket
(require pollen/tag pollen/template/html net/sendurl)

(define pre (default-tag-function 'pre))

(define doc
◊pre{
buf[0] = 0x00; // the register to be written to
buf[1] = 0x??; // the value to assign to that register
})

(define f (make-temporary-file "~a.html"))
(display-to-file (->html `(html ,doc)) f #:exists 'append)

(send-url (path->string f))
The file you linked to doesn’t contain any `pre` tags. Though the example below suggests the default behavior is correct. ```racket #lang pollen/mode racket (require pollen/tag pollen/template/html net/sendurl) (define pre (default-tag-function 'pre)) (define doc ◊pre{ buf[0] = 0x00; // the register to be written to buf[1] = 0x??; // the value to assign to that register }) (define f (make-temporary-file "~a.html")) (display-to-file (->html `(html ,doc)) f #:exists 'append) (send-url (path->string f)) ```
leemeichin commented 3 years ago (Migrated from github.com)

Oh, my mistake. I didn't commit that change 😅

I realise that I had indented ◊when/splice in the default template, which then found its way into the rendered output (where the chlidren of main maintained some level of indentation relative to the parent element):

<main class="container">
    ◊when/splice[(equal? 'posts (parent here))]{
      ...
          ◊(->html doc)
      ...
    }
</main>

Removing this indentation solved the problem (and it was only the when/splice indentation that mattered). Basically just an edge-case that I've seen others solve by running tidy on the output, or similar.

Oh, my mistake. I didn't commit that change 😅 I realise that I had indented `◊when/splice` in the default template, which then found its way into the rendered output (where the chlidren of `main` maintained some level of indentation relative to the parent element): ``` <main class="container"> ◊when/splice[(equal? 'posts (parent here))]{ ... ◊(->html doc) ... } </main> ``` Removing this indentation solved the problem (and it was only the `when/splice` indentation that mattered). Basically just an edge-case that I've seen others solve by running `tidy` on the output, or similar.
This repo is archived. You cannot comment on issues.
No Milestone
No project
No Assignees
1 Participants
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: mbutterick/pollen-users#102
Loading…
There is no content yet.