Re: [pollen] Question about Pollen markup
That is incredibly helpful. Thanks so much for the tip. I was trying to do
this very thing earlier.
Many thanks, for the help and the patience.
Cheers, B
On Wednesday, March 13, 2019 at 3:56:53 PM UTC-5, Matthew Butterick wrote:
>
> Here's how I debug Pollen functions. I have the `debug` package installed,
> and then I change my #lang line to
>
> #lang debug racket/base
>
> (or `#lang debug racket` etc)
>
> And then when I put #R in front of any expression, it prints to the Pollen
> console when a page is rendered.
>
> In this case, you could use `#R elements` to see exactly what's getting
> passed to your function. Or you could use `#R e #R (equal? e "\n")` to
> print `e` and the result of the predicate.
>
>
>
>
> On Mar 13, 2019, at 1:33 PM, Brendan Stromberger > wrote:
>
> Huh, I don't understand at all why, but for some reason, the code I just
> posted above is now working. Maybe I inadvertently fixed some issue in the
> template?
>
> *shrug*
>
> Anyway, thanks for the help, I think I understand working with xexprs a
> lile bit more now.
>
> On Wednesday, March 13, 2019 at 3:18:03 PM UTC-5, Brendan Stromberger
> wrote:
>>
>> Is there a reason the curly-brace syntax is preferable? I've tried for
>> the past 2 hours but using filter-split on "\n" seems to have no effect on
>> my output. It seems more explicit to me to just use the ◊(ul[…]) form and
>> not have to do any mangling of xexprs.
>>
>> I think this is what you were suggesting?
>>
>> (define (ul . elements)
>> (case (current-poly-target)
>> [(txt) elements]
>> [else (txexpr 'ul empty
>> (map (lambda (e) (txexpr 'li empty e)) (filter-split elements (λ (e) (
>> equal? e "\n")]))
>>
>> On Sunday, March 10, 2019 at 8:22:40 PM UTC-5, Matthew Butterick wrote:
>>>
>>> The curly-brace syntax is almost always preferable. Keep in mind that
>>> the linebreaks are separated into their own elements (For more on this
>>> behavior see [1].) So this markup:
>>>
>>> ◊ol{The remaining forty-nine stalks ◊(comment "" ",") two piles.
>>> another item
>>> another item
>>> }
>>>
>>> Produces this list of five (not three) elements:
>>>
>>> '("The remaining forty-nine stalks "
>>> (comment "" ",")
>>> " two piles."
>>> "\n"
>>> "another item"
>>> "\n"
>>> "another item")
>>>
>>> Probably what you want is to preprocess `elements` into bigger chunks
>>> representing list items before passing each to your 'li tag lambda. For
>>> instance this:
>>>
>>> (require sugar/list)
>>> (filter-split '("The remaining forty-nine stalks "
>>> (comment "" ",")
>>> " two piles."
>>> "\n"
>>> "another item"
>>> "\n"
>>> "another item")
>>>(λ (e) (equal? e "\n")))
>>>
>>>
>>> Produces these sublists:
>>>
>>> '(("The remaining forty-nine stalks " (comment "" ",") " two piles.")
>>> ("another item")
>>> ("another item"))
>>>
>>> For a more elaborate example of list-item detection, see the
>>> `detect-list-items` function [2] in the pollen-tfl sample project.
>>>
>>> [1]
>>> https://docs.racket-lang.org/pollen/pollen-command-syntax.html#%28part._the-text-body%29
>>>
>>> [2]
>>> https://docs.racket-lang.org/pollen-tfl/_pollen_rkt_.html#%28def._%28%28lib._pollen-tfl%2Fpollen..rkt%29._detect-list-items%29%29
>>>
>>> On Mar 10, 2019, at 4:08 PM, Brendan Stromberger
>>> wrote:
>>>
>>> Hey there, still plugging away on my book project. I have a function for
>>> an ordered list:
>>>
>>> (define (ol . elements)
>>> (case (current-poly-target)
>>> [(txt) elements]
>>> [else (txexpr 'ol empty
>>> (map (lambda (e) (txexpr 'li empty (list e))) elements))]))
>>>
>>> And I am using it like so:
>>>
>>> ◊ol[
>>> "The remaining forty-nine stalks are laid down and, aiming at the middle
>>> of the pile with the right thumb◊(comment "" ",") two piles are
>>> separated."
>>> "another item"
>>> "another item"
>>> ]
>>>
>>> I want to use it this way because if I use the ◊ol{} syntax, my
>>> ◊comment{} tag in the first item gets treated as its own , and
>>> generally the generated markup is a bit weird – at each newline, a blank
>>> is generated:
>>>
>>>
>>>
> --
> You received this message because you are subscribed to the Google Groups
> "Pollen" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to pollenpub+...@googlegroups.com .
> For more options, visit https://groups.google.com/d/optout.
>
>
>
--
You received this message because you are subscribed to the Google Groups
"Pollen" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to pollenpub+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [pollen] Question about Pollen markup
Here's how I debug Pollen functions. I have the `debug` package installed, and
then I change my #lang line to
#lang debug racket/base
(or `#lang debug racket` etc)
And then when I put #R in front of any expression, it prints to the Pollen
console when a page is rendered.
In this case, you could use `#R elements` to see exactly what's getting passed
to your function. Or you could use `#R e #R (equal? e "\n")` to print `e` and
the result of the predicate.
> On Mar 13, 2019, at 1:33 PM, Brendan Stromberger
> wrote:
>
> Huh, I don't understand at all why, but for some reason, the code I just
> posted above is now working. Maybe I inadvertently fixed some issue in the
> template?
>
> *shrug*
>
> Anyway, thanks for the help, I think I understand working with xexprs a
> lile bit more now.
>
> On Wednesday, March 13, 2019 at 3:18:03 PM UTC-5, Brendan Stromberger wrote:
> Is there a reason the curly-brace syntax is preferable? I've tried for the
> past 2 hours but using filter-split on "\n" seems to have no effect on my
> output. It seems more explicit to me to just use the ◊(ul[…]) form and not
> have to do any mangling of xexprs.
>
> I think this is what you were suggesting?
>
> (define (ul . elements)
> (case (current-poly-target)
> [(txt) elements]
> [else (txexpr 'ul empty
> (map (lambda (e) (txexpr 'li empty e)) (filter-split elements (λ (e)
> (equal? e "\n")]))
>
> On Sunday, March 10, 2019 at 8:22:40 PM UTC-5, Matthew Butterick wrote:
> The curly-brace syntax is almost always preferable. Keep in mind that the
> linebreaks are separated into their own elements (For more on this behavior
> see [1].) So this markup:
>
> ◊ol{The remaining forty-nine stalks ◊(comment "" ",") two piles.
> another item
> another item
> }
>
> Produces this list of five (not three) elements:
>
> '("The remaining forty-nine stalks "
> (comment "" ",")
> " two piles."
> "\n"
> "another item"
> "\n"
> "another item")
>
> Probably what you want is to preprocess `elements` into bigger chunks
> representing list items before passing each to your 'li tag lambda. For
> instance this:
>
> (require sugar/list)
> (filter-split '("The remaining forty-nine stalks "
> (comment "" ",")
> " two piles."
> "\n"
> "another item"
> "\n"
> "another item")
>(λ (e) (equal? e "\n")))
>
>
> Produces these sublists:
>
> '(("The remaining forty-nine stalks " (comment "" ",") " two piles.")
> ("another item")
> ("another item"))
>
> For a more elaborate example of list-item detection, see the
> `detect-list-items` function [2] in the pollen-tfl sample project.
>
> [1]
> https://docs.racket-lang.org/pollen/pollen-command-syntax.html#%28part._the-text-body%29
>
>
>
> [2]
> https://docs.racket-lang.org/pollen-tfl/_pollen_rkt_.html#%28def._%28%28lib._pollen-tfl%2Fpollen..rkt%29._detect-list-items%29%29
>
>
>> On Mar 10, 2019, at 4:08 PM, Brendan Stromberger >
>> wrote:
>>
>> Hey there, still plugging away on my book project. I have a function for an
>> ordered list:
>>
>> (define (ol . elements)
>> (case (current-poly-target)
>> [(txt) elements]
>> [else (txexpr 'ol empty
>> (map (lambda (e) (txexpr 'li empty (list e))) elements))]))
>>
>> And I am using it like so:
>>
>> ◊ol[
>> "The remaining forty-nine stalks are laid down and, aiming at the
>> middle of the pile with the right thumb◊(comment "" ",") two piles are
>> separated."
>> "another item"
>> "another item"
>> ]
>>
>> I want to use it this way because if I use the ◊ol{} syntax, my ◊comment{}
>> tag in the first item gets treated as its own , and generally the
>> generated markup is a bit weird – at each newline, a blank is generated:
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Pollen" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to pollenpub+unsubscr...@googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout
> .
--
You received this message because you are subscribed to the Google Groups
"Pollen" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to pollenpub+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [pollen] Question about Pollen markup
Ah, my ◊comment's won't evaluate inside a ◊ol[…], so I guess there's that.
On Wednesday, March 13, 2019 at 3:18:03 PM UTC-5, Brendan Stromberger wrote:
>
> Is there a reason the curly-brace syntax is preferable? I've tried for the
> past 2 hours but using filter-split on "\n" seems to have no effect on my
> output. It seems more explicit to me to just use the ◊(ul[…]) form and not
> have to do any mangling of xexprs.
>
> I think this is what you were suggesting?
>
> (define (ul . elements)
> (case (current-poly-target)
> [(txt) elements]
> [else (txexpr 'ul empty
> (map (lambda (e) (txexpr 'li empty e)) (filter-split elements (λ (e) (
> equal? e "\n")]))
>
> On Sunday, March 10, 2019 at 8:22:40 PM UTC-5, Matthew Butterick wrote:
>>
>> The curly-brace syntax is almost always preferable. Keep in mind that the
>> linebreaks are separated into their own elements (For more on this behavior
>> see [1].) So this markup:
>>
>> ◊ol{The remaining forty-nine stalks ◊(comment "" ",") two piles.
>> another item
>> another item
>> }
>>
>> Produces this list of five (not three) elements:
>>
>> '("The remaining forty-nine stalks "
>> (comment "" ",")
>> " two piles."
>> "\n"
>> "another item"
>> "\n"
>> "another item")
>>
>> Probably what you want is to preprocess `elements` into bigger chunks
>> representing list items before passing each to your 'li tag lambda. For
>> instance this:
>>
>> (require sugar/list)
>> (filter-split '("The remaining forty-nine stalks "
>> (comment "" ",")
>> " two piles."
>> "\n"
>> "another item"
>> "\n"
>> "another item")
>>(λ (e) (equal? e "\n")))
>>
>>
>> Produces these sublists:
>>
>> '(("The remaining forty-nine stalks " (comment "" ",") " two piles.")
>> ("another item")
>> ("another item"))
>>
>> For a more elaborate example of list-item detection, see the
>> `detect-list-items` function [2] in the pollen-tfl sample project.
>>
>> [1]
>> https://docs.racket-lang.org/pollen/pollen-command-syntax.html#%28part._the-text-body%29
>>
>> [2]
>> https://docs.racket-lang.org/pollen-tfl/_pollen_rkt_.html#%28def._%28%28lib._pollen-tfl%2Fpollen..rkt%29._detect-list-items%29%29
>>
>> On Mar 10, 2019, at 4:08 PM, Brendan Stromberger
>> wrote:
>>
>> Hey there, still plugging away on my book project. I have a function for
>> an ordered list:
>>
>> (define (ol . elements)
>> (case (current-poly-target)
>> [(txt) elements]
>> [else (txexpr 'ol empty
>> (map (lambda (e) (txexpr 'li empty (list e))) elements))]))
>>
>> And I am using it like so:
>>
>> ◊ol[
>> "The remaining forty-nine stalks are laid down and, aiming at the middle
>> of the pile with the right thumb◊(comment "" ",") two piles are
>> separated."
>> "another item"
>> "another item"
>> ]
>>
>> I want to use it this way because if I use the ◊ol{} syntax, my
>> ◊comment{} tag in the first item gets treated as its own , and
>> generally the generated markup is a bit weird – at each newline, a blank
>> is generated:
>>
>>
>>
--
You received this message because you are subscribed to the Google Groups
"Pollen" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to pollenpub+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [pollen] Question about Pollen markup
Is there a reason the curly-brace syntax is preferable? I've tried for the
past 2 hours but using filter-split on "\n" seems to have no effect on my
output. It seems more explicit to me to just use the ◊(ul[…]) form and not
have to do any mangling of xexprs.
I think this is what you were suggesting?
(define (ul . elements)
(case (current-poly-target)
[(txt) elements]
[else (txexpr 'ul empty
(map (lambda (e) (txexpr 'li empty e)) (filter-split elements (λ (e) (equal?
e "\n")]))
On Sunday, March 10, 2019 at 8:22:40 PM UTC-5, Matthew Butterick wrote:
>
> The curly-brace syntax is almost always preferable. Keep in mind that the
> linebreaks are separated into their own elements (For more on this behavior
> see [1].) So this markup:
>
> ◊ol{The remaining forty-nine stalks ◊(comment "" ",") two piles.
> another item
> another item
> }
>
> Produces this list of five (not three) elements:
>
> '("The remaining forty-nine stalks "
> (comment "" ",")
> " two piles."
> "\n"
> "another item"
> "\n"
> "another item")
>
> Probably what you want is to preprocess `elements` into bigger chunks
> representing list items before passing each to your 'li tag lambda. For
> instance this:
>
> (require sugar/list)
> (filter-split '("The remaining forty-nine stalks "
> (comment "" ",")
> " two piles."
> "\n"
> "another item"
> "\n"
> "another item")
>(λ (e) (equal? e "\n")))
>
>
> Produces these sublists:
>
> '(("The remaining forty-nine stalks " (comment "" ",") " two piles.")
> ("another item")
> ("another item"))
>
> For a more elaborate example of list-item detection, see the
> `detect-list-items` function [2] in the pollen-tfl sample project.
>
> [1]
> https://docs.racket-lang.org/pollen/pollen-command-syntax.html#%28part._the-text-body%29
>
> [2]
> https://docs.racket-lang.org/pollen-tfl/_pollen_rkt_.html#%28def._%28%28lib._pollen-tfl%2Fpollen..rkt%29._detect-list-items%29%29
>
> On Mar 10, 2019, at 4:08 PM, Brendan Stromberger > wrote:
>
> Hey there, still plugging away on my book project. I have a function for
> an ordered list:
>
> (define (ol . elements)
> (case (current-poly-target)
> [(txt) elements]
> [else (txexpr 'ol empty
> (map (lambda (e) (txexpr 'li empty (list e))) elements))]))
>
> And I am using it like so:
>
> ◊ol[
> "The remaining forty-nine stalks are laid down and, aiming at the middle
> of the pile with the right thumb◊(comment "" ",") two piles are
> separated."
> "another item"
> "another item"
> ]
>
> I want to use it this way because if I use the ◊ol{} syntax, my
> ◊comment{} tag in the first item gets treated as its own , and
> generally the generated markup is a bit weird – at each newline, a blank
> is generated:
>
>
>
--
You received this message because you are subscribed to the Google Groups
"Pollen" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to pollenpub+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [pollen] Question about Pollen markup
The curly-brace syntax is almost always preferable. Keep in mind that the
linebreaks are separated into their own elements (For more on this behavior see
[1].) So this markup:
◊ol{The remaining forty-nine stalks ◊(comment "" ",") two piles.
another item
another item
}
Produces this list of five (not three) elements:
'("The remaining forty-nine stalks "
(comment "" ",")
" two piles."
"\n"
"another item"
"\n"
"another item")
Probably what you want is to preprocess `elements` into bigger chunks
representing list items before passing each to your 'li tag lambda. For
instance this:
(require sugar/list)
(filter-split '("The remaining forty-nine stalks "
(comment "" ",")
" two piles."
"\n"
"another item"
"\n"
"another item")
(λ (e) (equal? e "\n")))
Produces these sublists:
'(("The remaining forty-nine stalks " (comment "" ",") " two piles.")
("another item")
("another item"))
For a more elaborate example of list-item detection, see the
`detect-list-items` function [2] in the pollen-tfl sample project.
[1]
https://docs.racket-lang.org/pollen/pollen-command-syntax.html#%28part._the-text-body%29
[2]
https://docs.racket-lang.org/pollen-tfl/_pollen_rkt_.html#%28def._%28%28lib._pollen-tfl%2Fpollen..rkt%29._detect-list-items%29%29
> On Mar 10, 2019, at 4:08 PM, Brendan Stromberger
> wrote:
>
> Hey there, still plugging away on my book project. I have a function for an
> ordered list:
>
> (define (ol . elements)
> (case (current-poly-target)
> [(txt) elements]
> [else (txexpr 'ol empty
> (map (lambda (e) (txexpr 'li empty (list e))) elements))]))
>
> And I am using it like so:
>
> ◊ol[
> "The remaining forty-nine stalks are laid down and, aiming at the
> middle of the pile with the right thumb◊(comment "" ",") two piles are
> separated."
> "another item"
> "another item"
> ]
>
> I want to use it this way because if I use the ◊ol{} syntax, my ◊comment{}
> tag in the first item gets treated as its own , and generally the
> generated markup is a bit weird – at each newline, a blank is generated:
--
You received this message because you are subscribed to the Google Groups
"Pollen" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to pollenpub+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[pollen] Question about Pollen markup
Hey there, still plugging away on my book project. I have a function for an
ordered list:
(define (ol . elements)
(case (current-poly-target)
[(txt) elements]
[else (txexpr 'ol empty
(map (lambda (e) (txexpr 'li empty (list e))) elements))]))
And I am using it like so:
◊ol[
"The remaining forty-nine stalks are laid down and, aiming at the middle of
the pile with the right thumb◊(comment "" ",") two piles are separated."
"another item"
"another item"
]
I want to use it this way because if I use the ◊ol{} syntax, my ◊comment{}
tag in the first item gets treated as its own , and generally the
generated markup is a bit weird – at each newline, a blank is
generated:
[image: Screen Shot 2019-03-10 at 6.06.02 PM.png]
I'm not sure about the best way to write this. If I were to define an li
tag and nest those inside my ol tag, that'd probably be fine, but then that
begins to mirror the structure of the DOM rather than my document, which
will eventually have definitions for Latex… any thoughts?
Thanks!
Brendan
--
You received this message because you are subscribed to the Google Groups
"Pollen" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to pollenpub+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
