PiRSquared17 / wikiwym

Automatically exported from code.google.com/p/wikiwym
0 stars 0 forks source link

general-purposes mis-parse issue #11

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago

{{{(/* */)}}}: as of r94 that does not parse out the braces and subsequently 
treats the klees as bold.

Original issue reported on code.google.com by sgbeal@googlemail.com on 22 Apr 2010 at 2:46

GoogleCodeExporter commented 9 years ago
Dammit, {{{(/* */)}}} is not consistently reproducible. This page:

http://code.google.com/p/yapeal/wiki/CodingStandards

demonstrates where it's mis-parsed, but if i edit the wiki with that same text 
(in a 
different location) it works. i hate that type of problem.

Original comment by sgbeal@googlemail.com on 22 Apr 2010 at 2:52

GoogleCodeExporter commented 9 years ago
it turns out that the {{{(/* */)}}} is a v8 incompatibility. Pasting that text 
50x in 
a row works fine on FF, but on v8/Chrome, some of them are mis-parsed.

Works consistently in: FF, Konqueror, Opera

Works incosistently in Chrome, Epiphany, and the errors in those two browsers 
were 
byte-for-byte the same.

Original comment by sgbeal@googlemail.com on 22 Apr 2010 at 4:00

GoogleCodeExporter commented 9 years ago
the weird one above has been fixed (it was caused by a bug in the //g regex 
flag in 
some browsers!).

Now we have exhibit B:

http://code.google.com/p/yapeal/wiki/CodingStandards
------------
All scripts contributed to Yapeal must:
  * Be stored as ASCII text
  * Use UTF-8 character encoding
  * Be Unix formatted
   "Unix formatted" means two things:
   # Lines must end only with a line feed (LF). Line feeds are represented as ordinal 
10, octal 012 and hex 0A. Do not use carriage returns (CR) like Macintosh 
computers 
do or the carriage return/line feed combination (CRLF) like Windows computers 
do.
------------

There is a syntactic ambiguity there which causes the '#' list element to be 
included 
as part of the previous line's blockquote. i understand why it's happening but 
i'm 
not yet clear on how i can solve that generically within the current 
block-parsing 
mechanism. i don't want to special-case that one (it would quickly turn into 50 
special cases).

Original comment by sgbeal@googlemail.com on 22 Apr 2010 at 4:34

GoogleCodeExporter commented 9 years ago
Exhibit C:

  * [http://code.google.com/p/v8-
juice/source/browse/trunk/src/include/v8/juice/forwarding.h 
<v8/juice/forwarding.h>]

The link text gets elided because it looks like raw HTML to the parser.

Original comment by sgbeal@googlemail.com on 26 Apr 2010 at 9:10

GoogleCodeExporter commented 9 years ago
Exhibit C was fixed in r174.

Original comment by sgbeal@googlemail.com on 26 Apr 2010 at 2:55