Custom pre-processing before pollen does its stuff

[san...@gmail.com]

I want to make some small additions to the syntax available to authors. I'm considering two paths and would like some advice.

1. I could write a custom #lang that turns my pollen+additions into plain pollen. But I'm having a hard time figuring out how this would work. The reader would do a custom parse into an s-exp with my additional syntax handled as tokens, but with everything else just being parsed as individual characters. The expander would write out characters as-is, leaving most of the program untouched, but would turn my additional syntax that was parsed as tokens into pollen tags and content. But then I just get a bunch of pollen code printed out of the expander. What do I do with that?

OR

2. I could to implement this with custom transformations in pollen's decode (like is done with decode-paragraphs).

Suggestions?

[Sorawee Porncharoenwase]

Can you provide an example of what you want to accomplish? 

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/pollenpub/bc6e6b75-1755-4de9-b407-a622ef02c715%40googlegroups.com.

[san...@gmail.com]

A couple specific things that I want to include for authors:

1. Allow them to use a few org-mode text-style annotations like *bold*, _underline_, /italics/.

2. Mark the beginning of what is to be considered a new section using a special character in the author's source text, like ¶.

On Tuesday, July 23, 2019 at 9:41:36 PM UTC-7, Sorawee Porncharoenwase wrote:

Can you provide an example of what you want to accomplish? 

On Tue, Jul 23, 2019 at 8:57 PM <san...@gmail.com> wrote:

I want to make some small additions to the syntax available to authors. I'm considering two paths and would like some advice.

1. I could write a custom #lang that turns my pollen+additions into plain pollen. But I'm having a hard time figuring out how this would work. The reader would do a custom parse into an s-exp with my additional syntax handled as tokens, but with everything else just being parsed as individual characters. The expander would write out characters as-is, leaving most of the program untouched, but would turn my additional syntax that was parsed as tokens into pollen tags and content. But then I just get a bunch of pollen code printed out of the expander. What do I do with that?

OR

2. I could to implement this with custom transformations in pollen's decode (like is done with decode-paragraphs).

Suggestions?

--
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 poll...@googlegroups.com.

[Joel Dueck]

On Tuesday, July 23, 2019 at 10:57:55 PM UTC-5, san...@gmail.com wrote:

But then I just get a bunch of pollen code printed out of the expander. What do I do with that?

You should check out this thread from a year ago: https://groups.google.com/forum/#!topic/pollenpub/HnC3wqVBahg

[Matthew Butterick]

Without deterring any enthusiasm, be aware that this kind of thing (= using ordinary characters like * _ / as formatting delimiters) is trickier to get right than it looks. Usually, formatting codes can be nested recusrively, therefore regular expressions won't work on their own. If you plan on maintaining ordinary Pollen expressionss, the combinations can get really weird:

_*hello* ◊i{Q*bert}_

The other approach would be to make a `pollen/org-mode` dialect that is similar to `pollen/markdown` in that it runs any Pollen expressions and then parses what remains. (This is less flexible, but more compatible with the foreign surface notation)