Status of textile branch

Status of textile branch

[Bas Bossink]

What is the current status of the textile branch?

Browsing through the code I can see textile writer support which seems
feature complete, but no reader support yet. Can anyone comment on the
current status and the planned release of the textile support?

Regards,

Bas

Re: Status of textile branch

[fiddlosopher]

There's an issue here: http://code.google.com/p/pandoc/issues/detail?id=51

I've got a nearly complete writer written, but I decided not to add it
to the master branch yet.  You can test it out; feedback on how well
it works would be helpful.  I remember getting frustrated with some
aspects of textile syntax, but I can't recall the details.

I think that a textile *reader* would be really useful, as people have
lots of legacy documents in textile. Is anyone out there working on a
textile reader?

John

On Aug 30, 6:44 pm, Bas Bossink <bas.boss...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> What is the current status of the textile branch?
>
> Browsing through the code I can see textile writer support which seems
> feature complete, but no reader support yet. Can anyone comment on the
> current status and the planned release of the textile support?
>
> Regards,
>
> Bas

-- 
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To post to this group, send email to pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to pandoc-discuss+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/pandoc-discuss?hl=en.

Re: Status of textile branch

[Paul R]

Hi,

> I think that a textile *reader* would be really useful, as people have
> lots of legacy documents in textile. Is anyone out there working on a
> textile reader?

A few months ago I started a Textile reader. In spite of my very high interest, I'm 
neither experienced with Haskell nor with Pandoc, so my Textile branch is mainly composed 
on tiny, easy steps. However, I beleive the current code is okay, most inlines are working 
and, IIRC, I was looking for a recursive way to handle nested list items.

I still want to achieve this reader, I just lake time at the moment. Any help would be 
welcome, the branch is here :

   http://github.com/paul-r-ml/pandoc/tree/textile


-- 
Paul

Re: Status of textile branch

[Paul R]

> I think that a textile *reader* would be really useful, as people have
> lots of legacy documents in textile. Is anyone out there working on a
> textile reader?

I have pushed a 'textile-reader' branch on github, based on current jgm/master :

   http://github.com/paul-r-ml/pandoc/tree/textile-reader

In the pandoc spirit, this reader supports structural markup (header, code block, 
citation, strong ...) but not visual markup (red face, right align ...).

Table support is still missing, I hope I will find some time in the coming week to do it.

Feedback much appreciated, I'm neither a haskell nor a parsec regular user, so please feel 
free to comment the code.

John, do you have some plan to merge your textile-writer branch into your master ? You may 
want to merge both the writer and the reader branches so that you can announce 
bidirectionnal textile support.

Regards,


-- 
Paul

Re: Status of textile branch

[paul r]

Hi,

I have just pushed an update on the Textile Reader :

  http://github.com/paul-r-ml/pandoc/tree/textile-reader

It now has table support, and some bug fixes.

Following the previous discussions we had, this branch does not
introduces anymore the "Inserted" inline constructor.

Also, there is no support for meta-information and for footnotes.
I would be happy to add it if someone need it.

You are welcome to try it and report any problem to me.

John, if I can do something to help you to integrate this reader into
your branch, please let me know.

Regards,


On 16 September 2010 12:09, Paul R <paul.r.ml-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
>> I think that a textile *reader* would be really useful, as people have
>> lots of legacy documents in textile. Is anyone out there working on a
>> textile reader?
>
> I have pushed a 'textile-reader' branch on github, based on current
> jgm/master :
>
>  http://github.com/paul-r-ml/pandoc/tree/textile-reader
>
> In the pandoc spirit, this reader supports structural markup (header, code
> block, citation, strong ...) but not visual markup (red face, right align
> ...).
>
> Table support is still missing, I hope I will find some time in the coming
> week to do it.
>
> Feedback much appreciated, I'm neither a haskell nor a parsec regular user,
> so please feel free to comment the code.
>
> John, do you have some plan to merge your textile-writer branch into your
> master ? You may want to merge both the writer and the reader branches so
> that you can announce bidirectionnal textile support.
>
> Regards,
>
>
> --
> Paul
>

-- 
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To post to this group, send email to pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to pandoc-discuss+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/pandoc-discuss?hl=en.

Re: Status of textile branch

[John MacFarlane]

Paul,

Glad to hear about the progress!  I haven't had a chance to try
it out yet, but I will try to do so soon.  As I mentioned on the
bug tracker, it will need a test suite. When I have a chance to
look at the branch, I can send you a patch for the "shell" of
the tests, which you can then flesh out.

John

+++ paul r [Oct 04 10 21:00 ]:
> Hi,
> 
> I have just pushed an update on the Textile Reader :
> 
>   http://github.com/paul-r-ml/pandoc/tree/textile-reader
> 
> It now has table support, and some bug fixes.
> 
> Following the previous discussions we had, this branch does not
> introduces anymore the "Inserted" inline constructor.
> 
> Also, there is no support for meta-information and for footnotes.
> I would be happy to add it if someone need it.
> 
> You are welcome to try it and report any problem to me.
> 
> John, if I can do something to help you to integrate this reader into
> your branch, please let me know.
> 
> Regards,
> 
> 
> On 16 September 2010 12:09, Paul R <paul.r.ml-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >
> >> I think that a textile *reader* would be really useful, as people have
> >> lots of legacy documents in textile. Is anyone out there working on a
> >> textile reader?
> >
> > I have pushed a 'textile-reader' branch on github, based on current
> > jgm/master :
> >
> >  http://github.com/paul-r-ml/pandoc/tree/textile-reader
> >
> > In the pandoc spirit, this reader supports structural markup (header, code
> > block, citation, strong ...) but not visual markup (red face, right align
> > ...).
> >
> > Table support is still missing, I hope I will find some time in the coming
> > week to do it.
> >
> > Feedback much appreciated, I'm neither a haskell nor a parsec regular user,
> > so please feel free to comment the code.
> >
> > John, do you have some plan to merge your textile-writer branch into your
> > master ? You may want to merge both the writer and the reader branches so
> > that you can announce bidirectionnal textile support.
> >
> > Regards,
> >
> >
> > --
> > Paul
> >
> 
> -- 
> You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
> To post to this group, send email to pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> To unsubscribe from this group, send email to pandoc-discuss+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/pandoc-discuss?hl=en.
> 

-- 
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To post to this group, send email to pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to pandoc-discuss+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/pandoc-discuss?hl=en.

Re: Status of textile branch

[John MacFarlane]

Paul,

I just checked out your textile reader branch.  It seems to be coming
along well!

I tested it on the sample text at textism.com, and noticed a few things.
First, textile allows you to attach attributes to a lot of the
constructions, e.g.

h2{color:green}
bq[fr]

Pandoc should just ignore these, but they trip up the reader as it
currently stands.

There are a few other things that didn't convert well, like the raw
HTML bits.  Anyway, you can try it yourself -- the sample text is here:
http://www.textism.com/tools/textile/?sample=2

I was pleased to see that you added a test suite, though it still
needs expanding. It should be a rough copy of the other reader test
suites, in the sense that it covers the same constructions, plus
things that are unique to textile (for example, the attributes on
h2 above).

Anyway, getting close!

Best,
John

+++ paul r [Oct 04 10 21:00 ]:
> Hi,
> 
> I have just pushed an update on the Textile Reader :
> 
>   http://github.com/paul-r-ml/pandoc/tree/textile-reader
> 
> It now has table support, and some bug fixes.
> 
> Following the previous discussions we had, this branch does not
> introduces anymore the "Inserted" inline constructor.
> 
> Also, there is no support for meta-information and for footnotes.
> I would be happy to add it if someone need it.
> 
> You are welcome to try it and report any problem to me.
> 
> John, if I can do something to help you to integrate this reader into
> your branch, please let me know.
> 

Re: Status of textile branch

[Paul R]

Hi John !

With great pleasure, I just found some time to hack on the textile
reader.

John> I tested it on the sample text at textism.com, and noticed a few
John> things. First, textile allows you to attach attributes to a lot of
John> the constructions, e.g. h2{color:green} bq[fr] Pandoc should just
John> ignore these, but they trip up the reader as it currently stands.

Ok, I just pushed that feature to github.

John> There are a few other things that didn't convert well, like the
John> raw HTML bits.

How to fix this one is not really clear to my eyes. The reference I use
( http://redcloth.org/hobix.com/textile/ ) says "HTML will only be
escaped if it’s found in a pre or code block". So every others html
constructions are designed to enclose regular textile constructs.
However, Pandoc rawHtml contructs are designed to handle the case of
plain string contents, so they don't fit the textile spec.

We could work around that by:
- treating the html content as string
- adding a new block constructor and a new inline constructor
- dropping the html tags

What do you think ?

John> I was pleased to see that you added a test suite, though it still
John> needs expanding. It should be a rough copy of the other reader
John> test suites, in the sense that it covers the same constructions,
John> plus things that are unique to textile (for example, the
John> attributes on h2 above).

I updated the test suite accordingly to the new feature.


-- 
  Paul

-- 
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To post to this group, send email to pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to pandoc-discuss+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/pandoc-discuss?hl=en.

Re: Status of textile branch

[John MacFarlane]

+++ Paul R [Nov 07 10 20:20 ]:
> Hi John !
> 
> With great pleasure, I just found some time to hack on the textile
> reader.
> 
> John> I tested it on the sample text at textism.com, and noticed a few
> John> things. First, textile allows you to attach attributes to a lot of
> John> the constructions, e.g. h2{color:green} bq[fr] Pandoc should just
> John> ignore these, but they trip up the reader as it currently stands.
> 
> Ok, I just pushed that feature to github.
> 
> John> There are a few other things that didn't convert well, like the
> John> raw HTML bits.
> 
> How to fix this one is not really clear to my eyes. The reference I use
> ( http://redcloth.org/hobix.com/textile/ ) says "HTML will only be
> escaped if it’s found in a pre or code block". So every others html
> constructions are designed to enclose regular textile constructs.
> However, Pandoc rawHtml contructs are designed to handle the case of
> plain string contents, so they don't fit the textile spec.

Not sure what you mean here.  Pandoc's markdown allows raw html around
pandoc constructions:  you can do <span>*emphasized*</span>, for
example.  This would give you a sequence with one raw Html inline,
then an Emph inline, than another raw Html inline. So you should be able to
use the same code, more or less, that the markdown reader uses.

> We could work around that by:
> - treating the html content as string
> - adding a new block constructor and a new inline constructor
> - dropping the html tags
> 
> What do you think ?
> 
> John> I was pleased to see that you added a test suite, though it still
> John> needs expanding. It should be a rough copy of the other reader
> John> test suites, in the sense that it covers the same constructions,
> John> plus things that are unique to textile (for example, the
> John> attributes on h2 above).
> 
> I updated the test suite accordingly to the new feature.

Great!  By the way, have you been using my textile writer at all?
I seem to recall that it was missing a few features, but I can't
remember what they were or why I decided not to release it.

John

-- 
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To post to this group, send email to pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to pandoc-discuss+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/pandoc-discuss?hl=en.

Re: Status of textile branch

[Paul R]

> Not sure what you mean here.  Pandoc's markdown allows raw html around
> pandoc constructions:  you can do<span>*emphasized*</span>, for
> example.  This would give you a sequence with one raw Html inline,
> then an Emph inline, than another raw Html inline. So you should be able to
> use the same code, more or less, that the markdown reader uses.

Ok, I was confused about the Pandoc HTML construction, thinking it had to be recursive. 
After more thoughts, it will fit well textile spec.


> Great!  By the way, have you been using my textile writer at all?

I remember I tried it, but that really was a single very quick test. Do you plan to 
release both the reader and the writer at the same time ?


-- 
Paul

Re: Status of textile branch

[John MacFarlane]

+++ Paul R [Nov 08 10 10:42 ]:
> 
> >Not sure what you mean here.  Pandoc's markdown allows raw html around
> >pandoc constructions:  you can do<span>*emphasized*</span>, for
> >example.  This would give you a sequence with one raw Html inline,
> >then an Emph inline, than another raw Html inline. So you should be able to
> >use the same code, more or less, that the markdown reader uses.
> 
> Ok, I was confused about the Pandoc HTML construction, thinking it
> had to be recursive. After more thoughts, it will fit well textile
> spec.
> 
> 
> >Great!  By the way, have you been using my textile writer at all?
> 
> I remember I tried it, but that really was a single very quick test.
> Do you plan to release both the reader and the writer at the same
> time ?

I think that would make sense, provided both are ready.

John

Re: Status of textile branch

[Paul R]

Hi John,

I just pushed raw html tags handling for the textile reader to github.
The reader will still fail to parse the most complicated structures that
mix tables, css attributes and textile attributes, but I'd like to wait
for user feedback to know how important fixing that would be. Indeed,
this kind of syntax is so convoluted that I'm not sure anybody actually
makes use of it, outside of textile demos.

Let me know what you think of it.

Regards,

John> There are a few other things that didn't convert well, like the
John> raw HTML bits. Anyway, you can try it yourself -- the sample text
John> is here: http://www.textism.com/tools/textile/?sample=2


-- 
  Paul

Re: Status of textile branch

[John MacFarlane]

+++ Paul R [Nov 23 10 12:26 ]:
> Hi John,
> 
> I just pushed raw html tags handling for the textile reader to github.
> The reader will still fail to parse the most complicated structures that
> mix tables, css attributes and textile attributes, but I'd like to wait
> for user feedback to know how important fixing that would be. Indeed,
> this kind of syntax is so convoluted that I'm not sure anybody actually
> makes use of it, outside of textile demos.
> 
> Let me know what you think of it.

I agree, I think it would be okay not to implement that really
convoluted stuff, if it's rarely used.

I started trying out the reader on the examples at
http://redcloth.org/hobix.com/textile/quick.html

Going through these would be a good way to figure out how to
make the parser more complete. There's a lot of low-hanging
fruit -- things that would be easy to implement.  <b>very</b>,
for example (the HTML should pass through, presumably).

Other things don't have pandoc counterparts but could be
treated better:

I'm %{color:red}unaware%

for example.

Smart punctuation is standard in textile.  You could adapt the
smart punctuation parsing from the markdown reader...

Great to see more progress on this!  I need to revisit that
textile writer...

John

Re: Status of textile branch

[John MacFarlane]

+++ Paul R [Nov 23 10 12:26 ]:
> Hi John,
> 
> I just pushed raw html tags handling for the textile reader to github.
> The reader will still fail to parse the most complicated structures that
> mix tables, css attributes and textile attributes, but I'd like to wait
> for user feedback to know how important fixing that would be. Indeed,
> this kind of syntax is so convoluted that I'm not sure anybody actually
> makes use of it, outside of textile demos.
> 
> Let me know what you think of it.

Paul,

I looked again at my textile writer.  I see that the textile it emits
is textile 2 (see textile.thresholdstate.com).  Is that the same version
your reader parses?

John

Re: Status of textile branch

[Paul R]

> Paul,
>
> I looked again at my textile writer.  I see that the textile it emits
> is textile 2 (see textile.thresholdstate.com).  Is that the same version
> your reader parses?
>
> John
>

John,

I based my work on the spec at http://redcloth.org/hobix.com/textile.
But let's decide we want to target textile 2 as described at textile.thresholdstate.com
I will re-check the reader to ensure it complies as much as possible with this spec.


-- 
Paul

Re: Status of textile branch

[John MacFarlane]

+++ Paul R [Nov 24 10 16:42 ]:
> >Paul,
> >
> >I looked again at my textile writer.  I see that the textile it emits
> >is textile 2 (see textile.thresholdstate.com).  Is that the same version
> >your reader parses?
> >
> >John
> >
> 
> John,
> 
> I based my work on the spec at http://redcloth.org/hobix.com/textile.
> But let's decide we want to target textile 2 as described at textile.thresholdstate.com
> I will re-check the reader to ensure it complies as much as possible with this spec.

I actually don't know whether textile 2 is considered the new "official" 
version, or whether it's just a renegade branch.  Which version do you
think it makes most sense to target?

textile2 seems to have better support for many things, which is maybe
why I chose to target it -- but if people don't use it, that's
irrelevant.

John

Re: Status of textile branch

[Paul R]

> I actually don't know whether textile 2 is considered the new "official"
> version, or whether it's just a renegade branch.  Which version do you
> think it makes most sense to target?

> textile2 seems to have better support for many things, which is maybe
> why I chose to target it -- but if people don't use it, that's
> irrelevant.

> John

I don't think there is a single leader for the textile spec, unfortunately.

textile.php parser is bundled to textpattern. In the repos, they just commited a new
revision of textile.php, version 2.2, four years after 2.0. The spec provided is very
terse.

   http://code.google.com/p/textpattern/source/detail?r=3400

It fixes many bugs and introduces some minor syntax enhancements.

In the meantime, ruby on rails project seem to like Textile, and use a library called
RedCloth. It was rewritten recently with proper design, and development seems to be
active. If I have to chose, I clearly prefer to match this implementation rather than the
php-regexp-total-madness one.

There is a comprehensive reference of the Redcloth textile syntax here :

   http://redcloth.org/textile/


-- 
Paul

Re: Status of textile branch

[John MacFarlane]

+++ Paul R [Nov 24 10 17:35 ]:
> 
> >I actually don't know whether textile 2 is considered the new "official"
> >version, or whether it's just a renegade branch.  Which version do you
> >think it makes most sense to target?
> 
> >textile2 seems to have better support for many things, which is maybe
> >why I chose to target it -- but if people don't use it, that's
> >irrelevant.
> 
> >John
> 
> I don't think there is a single leader for the textile spec, unfortunately.
> 
> textile.php parser is bundled to textpattern. In the repos, they just commited a new
> revision of textile.php, version 2.2, four years after 2.0. The spec provided is very
> terse.
> 
>   http://code.google.com/p/textpattern/source/detail?r=3400
> 
> It fixes many bugs and introduces some minor syntax enhancements.
> 
> In the meantime, ruby on rails project seem to like Textile, and use a library called
> RedCloth. It was rewritten recently with proper design, and development seems to be
> active. If I have to chose, I clearly prefer to match this implementation rather than the
> php-regexp-total-madness one.
> 
> There is a comprehensive reference of the Redcloth textile syntax here :
> 
>   http://redcloth.org/textile/

Sounds good to me.

John

Re: Status of textile branch

[John MacFarlane]

+++ John MacFarlane [Nov 24 10 09:31 ]:
> +++ Paul R [Nov 24 10 17:35 ]:
> > 
> > >I actually don't know whether textile 2 is considered the new "official"
> > >version, or whether it's just a renegade branch.  Which version do you
> > >think it makes most sense to target?
> > 
> > >textile2 seems to have better support for many things, which is maybe
> > >why I chose to target it -- but if people don't use it, that's
> > >irrelevant.
> > 
> > >John
> > 
> > I don't think there is a single leader for the textile spec, unfortunately.
> > 
> > textile.php parser is bundled to textpattern. In the repos, they just commited a new
> > revision of textile.php, version 2.2, four years after 2.0. The spec provided is very
> > terse.
> > 
> >   http://code.google.com/p/textpattern/source/detail?r=3400
> > 
> > It fixes many bugs and introduces some minor syntax enhancements.
> > 
> > In the meantime, ruby on rails project seem to like Textile, and use a library called
> > RedCloth. It was rewritten recently with proper design, and development seems to be
> > active. If I have to chose, I clearly prefer to match this implementation rather than the
> > php-regexp-total-madness one.
> > 
> > There is a comprehensive reference of the Redcloth textile syntax here :
> > 
> >   http://redcloth.org/textile/
> 
> Sounds good to me.

I've merged my textile writer into master.  I ran the test suite
through redcloth, and everything seemed to work correctly.

John

Re: Status of textile branch

[Paul R]

> I've merged my textile writer into master.  I ran the test suite
> through redcloth, and everything seemed to work correctly.


I just had a look at the redcloth spec online. It is richer than the spec on which I based
my initial work, but it is also more interesting.

Some features are lacking, I listed them in the header of the reader. I don't think they
are show stoppers for a first release, let me know what is your opinion.

I took the whole smartPunctuation parser from markdown, which required exporting it. Maybe
at some point it will be better to have a module to share common markup parsers.

Finally, The reader has a little problem. Parsing

   My grand-father is super-cool

will strike from father to super, which is not the desired behaviour. However, having
a smarter behaviour seems to require to know what was parsed just before (a blank ?). What
do you think ?

I just pushed my latest changes.


-- 
Paul

Re: Status of textile branch

[John MacFarlane]

+++ Paul R [Dec 03 10 17:27 ]:
> 
> >I've merged my textile writer into master.  I ran the test suite
> >through redcloth, and everything seemed to work correctly.
> 
> 
> I just had a look at the redcloth spec online. It is richer than the spec on which I based
> my initial work, but it is also more interesting.
> 
> Some features are lacking, I listed them in the header of the reader. I don't think they
> are show stoppers for a first release, let me know what is your opinion.

Not show stoppers, but some of them might not be too hard to implement:

> - Pandoc Meta Information (title, author, date)

as far as I can see, there's nothing corresponding to this in textile.
Is that right?  Or is there a metadata format?

> - footnotes

It should be possible to implement these using the same technique as
the markdown reader uses.  One thing that's not clear to me from the
spec is whether a footnote can contain multiple block elements -- also,
relatedly, where does the footnote end?  Probably this needs to be
determined by experimenting with redcloth.


> - dimension sign

This should be fairly easy.

> - registered, trademark, and copyright symbols

Again, easy.

> - acronyms

Nothing corresponding to this in the Pandoc structure, but we could
just discard the part in parens:  i.e., parse
"EPA(Environmental Protection Agency"
as
"EPA"

> - uppercase

Again, there is no "span" in pandoc, so I suppose we can just ignore
this one.  (Actually, we could change the HTML writer to do this for
all Str elements with all caps.  Would this be useful?)

> - definition lists

Wouldn't be too hard, I think.

> - continued blocks (ex bq..)

Also wouldn't be too hard, I suspect.  One just needs a way of
recognizing when the continuation ends.  Then one can treat it like
a markdown block quote.

I could probably implement some of these things, if you find them
tricky.  Again, though, we don't NEED to do them for a first release.

> I took the whole smartPunctuation parser from markdown, which required exporting it. Maybe
> at some point it will be better to have a module to share common markup parsers.

Yes, it should go in Text.Pandoc.Parsing, presumably.

> Finally, The reader has a little problem. Parsing
> 
>   My grand-father is super-cool
> 
> will strike from father to super, which is not the desired behaviour. However, having
> a smarter behaviour seems to require to know what was parsed just before (a blank ?). What
> do you think ?

Unfortunately, the way the parser works, it doesn't know what was parsed
just before.

Maybe you could modify the 'str' parser.  Right now it grabs a bunch of
non-special non-space characters.  You could change it to:  grab a bunch of
non-special characters, then (optionally) a single following hyphen.
Then "grandfather" would be parsed as [Str "grand-", Str "father"].
Does that make sense?

You'd have to make sure it's just a single hyphen, since "--" and
"---" need to be interpreted as smart punctuation.  Also, you might
have to ensure that the hyphen is not between two digits, since
pandoc's smart punctuation makes that into an En-dash.  But something
like this would work, I think...

John

Re: Status of textile branch

[John MacFarlane]

Paul,

I've pulled your textile branch into master, and added some commits
of my own.  From now on, you can send me changes as patches to
the most recent code from master.

My changes:

* I temporarily removed the smart punctuation stuff.
  This needs to be rethought.  For one thing,
  "emphasized text":http://url.com was coming out as
  double quoted rather than a link.  For another thing,
  textile seems to have slightly different smart punctuation
  conventions.

* I added an hrule parser.  This isn't documented on the
  redcloth site, but I see from using redcloth that

  -----

  and

  *****

  become hrules.

* I turn on stateSmart and stateParseRaw by default in the textile
  reader.

* I modified the str parser to (a) throw away acronym explanations
  e.g. "PBS(Public Broadcasting Service)" becomes "PBS", and (b)
  correctly handle hyphens inside words.

* I made textile the default reader for .textile extensions.

* I updated the test suite.

I think the code still needs work before it's releasable, but it's
getting closer.

John

Re: Status of textile branch

[Paul R]

Hi John,

I notice you made a lot of nice improvements to the textile reader,
thank you very much, I have been very busy lately, therefore have not
hacked much in spite of my strong desire to polish the work :)


John> Is that right? Or is there a metadata format?

I don't think there is one, but if you decide to implement an extended
format for meta information such as the YAML discussed recently, I think
it would fit as a nice extention to the standard Textile. But there is
not much to do in the meantime.

>> footnotes
John> It should be possible to implement these using the same technique
John> as the markdown reader uses. One thing that's not clear to me from
John> the spec is whether a footnote can contain multiple block
John> elements -- also, relatedly, where does the footnote end? Probably
John> this needs to be determined by experimenting with redcloth.

I see you just worked on it, that's a big step forward.


>> - registered, trademark, and copyright symbols
John> Again, easy.

Again, you just did it :)


>> - acronyms
John> Nothing corresponding to this in the Pandoc structure, but we
John> could just discard the part in parens: i.e., parse
John> "EPA(Environmental Protection Agency" as "EPA"

As a user, I would prefer to have pandoc just leave the info as it is
instead of striping the expanded form.


>> - definition lists
John> Wouldn't be too hard, I think.

I plan to work on it soon.

>> - continued blocks (ex bq..)
John> Also wouldn't be too hard, I suspect. One just needs a way of
John> recognizing when the continuation ends. Then one can treat it like
John> a markdown block quote.

I might work on it, but reading the spect, I suspect it is not widely
used.

Also, I will try to get smart punctuation working with as little code
duplication as possible, also this week.

regards,


-- 
  Paul

Re: Status of textile branch

[John MacFarlane]

+++ Paul R [Dec 08 10 22:17 ]:
> Hi John,
> 
> I notice you made a lot of nice improvements to the textile reader,
> thank you very much, I have been very busy lately, therefore have not
> hacked much in spite of my strong desire to polish the work :)
> 
> 
> John> Is that right? Or is there a metadata format?
> 
> I don't think there is one, but if you decide to implement an extended
> format for meta information such as the YAML discussed recently, I think
> it would fit as a nice extention to the standard Textile. But there is
> not much to do in the meantime.
> 
> >> footnotes
> John> It should be possible to implement these using the same technique
> John> as the markdown reader uses. One thing that's not clear to me from
> John> the spec is whether a footnote can contain multiple block
> John> elements -- also, relatedly, where does the footnote end? Probably
> John> this needs to be determined by experimenting with redcloth.
> 
> I see you just worked on it, that's a big step forward.
> 
> 
> >> - registered, trademark, and copyright symbols
> John> Again, easy.
> 
> Again, you just did it :)
> 
> 
> >> - acronyms
> John> Nothing corresponding to this in the Pandoc structure, but we
> John> could just discard the part in parens: i.e., parse
> John> "EPA(Environmental Protection Agency" as "EPA"
> 
> As a user, I would prefer to have pandoc just leave the info as it is
> instead of striping the expanded form.

The reason I stripped it is that the expansion won't appear in
the HTML unless you hover over the acronym.  So by stripping it,
we get HTML that looks just the same (except for the hovering
behavior).

If we kept it in, it seems you'd at least want a space to be
inserted before the parens.

Your call.

> >> - definition lists
> John> Wouldn't be too hard, I think.
> 
> I plan to work on it soon.

Great.

> >> - continued blocks (ex bq..)
> John> Also wouldn't be too hard, I suspect. One just needs a way of
> John> recognizing when the continuation ends. Then one can treat it like
> John> a markdown block quote.
> 
> I might work on it, but reading the spect, I suspect it is not widely
> used.
> 
> Also, I will try to get smart punctuation working with as little code
> duplication as possible, also this week.

I've already wired the smart punctuation in!  (And in rst and html
readers.)  So no need to work further on that.

The only thing I haven't dealt with is the "dimension sign", which
seems minor.

John

Re: Status of textile branch

[Paul R]

> If we kept it in, it seems you'd at least want a space to be
> inserted before the parens.

This looks like the best behaviour we can provide indeed.

>>>> - definition lists
>> I plan to work on it soon.

> Great.

Done and pushed.

> I've already wired the smart punctuation in! (And in rst and html readers.) So no need
> to work further on that.

Great.

> The only thing I haven't dealt with is the "dimension sign", which seems minor.

Indeed it is minor. This is very local to redcloth and I'm not sure if it is worth the
complexity added to the str parser.


-- 
Paul

Re: Status of textile branch

[John MacFarlane]

+++ Paul R [Dec 09 10 13:46 ]:
> >If we kept it in, it seems you'd at least want a space to be
> >inserted before the parens.
> 
> This looks like the best behaviour we can provide indeed.

I'll make this change.

> >>>>- definition lists
> >>I plan to work on it soon.
> 
> >Great.
> 
> Done and pushed.

I wonder if your parser is quite right, for the multi-block list items.
Try it with this:

~~~
- milk := hi
- cow := animal

found on farms.

Here's some text.

Another def list:

- cat := animal

has claws. =:
~~~~

I haven't tried it yet, just looked at the code, but it seems to me that your
parser will find one definition list here, instead of two...

John

Re: Status of textile branch

[Paul R]

> - milk := hi
> - cow := animal
>
> found on farms.
>
> Here's some text.
>
> Another def list:
>
> - cat := animal
>
> has claws. =:


> I haven't tried it yet, just looked at the code, but it seems to me that your
> parser will find one definition list here, instead of two...


Indeed, it will, and purposely. That's how I understand the "spec".

To be sure I just checked the redcloth implementation, and it seems to have the same 
behaviour, so I guess the implementation is correct.

-- 
Paul

Re: Status of textile branch

[John MacFarlane]

+++ Paul R [Dec 09 10 17:54 ]:
> 
> >- milk := hi
> >- cow := animal
> >
> >found on farms.
> >
> >Here's some text.
> >
> >Another def list:
> >
> >- cat := animal
> >
> >has claws. =:
> 
> 
> >I haven't tried it yet, just looked at the code, but it seems to me that your
> >parser will find one definition list here, instead of two...
> 
> 
> Indeed, it will, and purposely. That's how I understand the "spec".
> 
> To be sure I just checked the redcloth implementation, and it seems
> to have the same behaviour, so I guess the implementation is
> correct.

OK!  Will merge.

John