18 Jul
2011
18 Jul
'11
4:36 p.m.
Hi,
I added code to the Wysiwyg editor to escape markup within text nodes. To
illustrate here is an example from the (javascript) test-suite:
it("should escaped text containing link markup", function() {
expect("To create a link, put it between
<code>*</code>").shouldParseInto("To create a link, put it between
==\\*==");
});
This works fine, the problem arises with:
it("should escaped text containing code markup", function() {
expect("To make something <code>monospaced</code>, surround it with
<code>==</code>").shouldParseInto("To make something
==monospaced==,
surround it with ==\\=\\===");
});
Should text containing '==' translate into '\==' OR '\=\='.
rendering ' ==\==== ' into html [1] results in:
'<p> <code>=</code>= </p>'
whereas rendering '==\=\=== ' into html results in:
'<p> <code>==</code> </p>'
The html reflects the PRDocument structure. It seems that PRDocumentParser
doesn't parse ' ==\==== ' as expected.
Worse the sequence: wiki text-> PRDocument -> wiki text fails:
PRWikiWriter write: (PRDocumentParser parse: ' ==\=\=== ') => '
==\==== '
However I have a fix. I've locally modified PRDocumentParser
class>>#escape:using: so that any multi-character markup is multiply
escaped:
'@@' -> '\@\@'
'--' => '\-\-'
This seems to solve the ambiguous parsing problem and the round-trip
problem. Great. However many tests will need rewriting to reflect that any
multi-character markup is escaped with multiple slashes. Before fixing the
tests, I wanted to check that people thought it made sense.
Thanks
Nick
[1] | document renderer |
document := PRDocumentParser parse: ' ==\==== '.
renderer := PRViewRenderer new.
^ WAHtmlCanvas builder
fullDocument: false;
render: [ :r | renderer withinContentDo: [ renderer start: document in:
self on: r ] ].
18 Jul
18 Jul
9:53 p.m.
Hi Nick,
I don't have a computer in the coming week to teat out, so bear with
me if I missinderstand something.
The reason == is escaped as \== is that only in this case this is
problematic, if all markup characters were escaped we would beed to
escape also a single occurrnce of = to \=. No?
Lukas
On Monday, 18 July 2011, Nick Ager <nick.ager(a)gmail.com> wrote:
Hi,
I added code to the Wysiwyg editor to escape markup within text nodes. To illustrate here
is an example from the (javascript) test-suite:
it("should escaped text containing link markup", function() {
expect("To create a link, put it between
<code>*</code>").shouldParseInto("To create a link, put it between
==\\*==");
});
This works fine, the problem arises with:
it("should escaped text containing code markup", function() {
expect("To make something <code>monospaced</code>, surround it with
<code>==</code>").shouldParseInto("To make something ==monospaced==,
surround it with ==\\=\\===");
});
Should text containing '==' translate into '\==' OR '\=\='.
rendering ' ==\==== ' into html [1] results in:
'<p> <code>=</code>= </p>'
whereas rendering '==\=\=== ' into html results in: '<p>
<code>==</code> </p>'
The html reflects the PRDocument structure. It seems that PRDocumentParser doesn't
parse ' ==\==== ' as expected.Worse the sequence: wiki text-> PRDocument ->
wiki text fails:
PRWikiWriter write: (PRDocumentParser parse: ' ==\=\=== ') => '
==\==== '
However I have a fix. I've locally modified PRDocumentParser
class>>#escape:using: so that any multi-character markup is multiply escaped:
'@@' -> '\@\@' '--' => '\-\-'
This seems to solve the ambiguous parsing problem and the round-trip problem. Great.
However many tests will need rewriting to reflect that any multi-character markup is
escaped with multiple slashes. Before fixing the tests, I wanted to check that people
thought it made sense.
Thanks
Nick
[1] | document renderer |
document := PRDocumentParser parse: ' ==\==== '. renderer := PRViewRenderer
new.
^ WAHtmlCanvas builder fullDocument: false;
render: [ :r | renderer withinContentDo: [ renderer start: document in: self on: r ]
].
--
Lukas Renggli
www.lukas-renggli.ch
10:46 p.m.
Hi Lukas,
Thanks for getting back to me,
The reason == is escaped as \== is that only in this case this is
problematic, if all markup characters were escaped we
would beed to
escape also a single occurrnce of = to \=. No?
I don't see any problem parsing \=\= or any multi-character markup (eg \@\@)
to plain text - I don't think it matters if \= and \=\= is ambiguous as all
you're only interested in producing the '=' character, free from
interpretation as any markup.
How about I fix the failing tests and in the process make sure it all works
as intended and if so check in the changes. We can always roll-back if I've
missed something.
Nick
11:50 p.m.
I've checked in the changes. There were only a couple of tests that needed
modifying, they acted as base tests for derived classes and made the number
of test failures seem large. If I've missed something I'm happy to
roll-back:
Name: Pier-Model-NickAger.411
Author: NickAger
Time: 18 July 2011, 10:47:33 pm
UUID: d23e8ad0-6e18-4f69-a7fc-7399a8493379
Ancestors: Pier-Model-NickAger.410
modified the way markup is escaped, so that:
'@@' is now escaped as: '\@\@' rather than as previously: '\@@'
Name: Pier-Tests-Model-NickAger.23
Author: NickAger
Time: 18 July 2011, 10:44:42 pm
UUID: d6cb4015-84c6-45c1-8daa-6f3357f63d92
Ancestors: Pier-Tests-Model-NickAger.22, Pier-Tests-Model-lr.21
modified tests to reflect changes in escaped markup:
'@@' => '\@\@'
19 Jul
19 Jul
9:36 a.m.
Thank, I will look at it when I am back home. My only worry was that
if you had a single = or @ in the text, it would be escaped.
Lukas
On Tuesday, 19 July 2011, Nick Ager <nick.ager(a)gmail.com> wrote:
I've checked in the changes. There were only a
couple of tests that needed modifying, they acted as base tests for derived classes and
made the number of test failures seem large. If I've missed something I'm happy to
roll-back:
Name: Pier-Model-NickAger.411Author: NickAgerTime: 18 July 2011, 10:47:33 pmUUID:
d23e8ad0-6e18-4f69-a7fc-7399a8493379Ancestors: Pier-Model-NickAger.410
modified the way markup is escaped, so that:
'@@' is now escaped as: '\@\@' rather than as previously: '\@@'
Name: Pier-Tests-Model-NickAger.23
Author: NickAgerTime: 18 July 2011, 10:44:42 pmUUID:
d6cb4015-84c6-45c1-8daa-6f3357f63d92Ancestors: Pier-Tests-Model-NickAger.22,
Pier-Tests-Model-lr.21
modified tests to reflect changes in escaped markup:
'@@' => '\@\@'
--
Lukas Renggli
www.lukas-renggli.ch
11:28 a.m.
Hi,
Thank, I will look at it when I am back home. My only worry was that
if you had a single = or @ in the text, it would be
escaped.
No that shouldn't happen as the only text to be escaped are:
PRDocumentParser buildTextMatcher keys => #('__'
'''''' '==' '*' '{{{' '--'
'^^' '@@' '+'
'""')
PRWikiWriter write: (PRDocumentParser parse: ' my address is
nick.ager(a)gmail.com ') => ' my address is
nick.ager(a)gmail.com '
All it means is that if you want to escape '@@' you can escape it as '\@\@\
or '\@@', but it escaper will now escape it as '\@\@' so:
PRWikiWriter write: (PRDocumentParser parse: ' annotations start with: \@@
') => ' annotations start with: \@\@ '
and:
PRWikiWriter write: (PRDocumentParser parse: ' annotations start with: \@\@
') => ' annotations start with: \@\@ '
Nick
11:42 a.m.
Ok, sounds cool.
On Tuesday, 19 July 2011, Nick Ager <nick.ager(a)gmail.com> wrote:
Hi,
Thank, I will look at it when I am back home. My only worry was that
if you had a single = or @ in the text, it would be escaped.
No that shouldn't happen as the only text to be escaped are:
PRDocumentParser buildTextMatcher keys => #('__'
'''''' '==' '*' '{{{' '--'
'^^' '@@' '+' '""')
PRWikiWriter write: (PRDocumentParser parse: ' my address is nick.ager(a)gmail.com
') => ' my address is nick.ager(a)gmail.com '
All it means is that if you want to escape '@@' you can escape it as '\@\@\
or '\@@', but it escaper will now escape it as '\@\@' so:
PRWikiWriter write: (PRDocumentParser parse: ' annotations start with: \@@ ')
=> ' annotations start with: \@\@ '
and:
PRWikiWriter write: (PRDocumentParser parse: ' annotations start with: \@\@ ')
=> ' annotations start with: \@\@ '
Nick
--
Lukas Renggli
www.lukas-renggli.ch
4675
days inactive
4676
days old
6 comments
2 participants
participants (2)
-
Lukas Renggli -
Nick Ager