https://bugzilla.wikimedia.org/show_bug.cgi?id=56809
ssas...@wikimedia.org changed:
What|Removed |Added
Status|PATCH_TO_REVIEW |RESOLVED
https://bugzilla.wikimedia.org/show_bug.cgi?id=56809
--- Comment #30 from Gerrit Notification Bot gerritad...@wikimedia.org ---
Change 94443 abandoned by Cscott:
Revert Have list items occupy their own line.
Reason:
Abandoned in favor of Ib7aa9449bbd994cb23b83b3f23cff944b1cddadf
https://bugzilla.wikimedia.org/show_bug.cgi?id=56809
--- Comment #29 from Gerrit Notification Bot gerritad...@wikimedia.org ---
Change 134380 merged by jenkins-bot:
Update list item newline handling to follow Parsoid's model
https://gerrit.wikimedia.org/r/134380
--
You are receiving this mail
https://bugzilla.wikimedia.org/show_bug.cgi?id=56809
--- Comment #27 from Gerrit Notification Bot gerritad...@wikimedia.org ---
Change 134380 had a related patch set uploaded by GWicke:
Update list item newline handling to follow Parsoid's model
https://gerrit.wikimedia.org/r/134380
--
You are
https://bugzilla.wikimedia.org/show_bug.cgi?id=56809
--- Comment #28 from Gabriel Wicke gwi...@wikimedia.org ---
(In reply to Bartosz Dziewoński from comment #26)
(In reply to Gabriel Wicke from comment #25)
PHP + tidy inserts newlines in the first case too, which is broken.
I'm pretty sure
https://bugzilla.wikimedia.org/show_bug.cgi?id=56809
--- Comment #24 from Erwin Dokter er...@darcoury.nl ---
Sorry, but it isn't. The *old* PHP parser output is:
ullia
/lilib
/lilic
/li/ul
No linebreak *between* list items. Parsoid goes (if I understand above
correctly):
ullia/li
lib/li
https://bugzilla.wikimedia.org/show_bug.cgi?id=56809
--- Comment #25 from Gabriel Wicke gwi...@wikimedia.org ---
Parsoid does not insert newlines where there are none:
ullifoo/lilibar/li/ul
in wikitext becomes
ullifoo/lilibar/li/ul
It does preserve newlines from wikitext though:
* foo
*
https://bugzilla.wikimedia.org/show_bug.cgi?id=56809
--- Comment #26 from Bartosz Dziewoński matma@gmail.com ---
(In reply to Gabriel Wicke from comment #25)
PHP + tidy inserts newlines in the first case too, which is broken.
I'm pretty sure that this is the case only if Tidy is enabled,
https://bugzilla.wikimedia.org/show_bug.cgi?id=56809
--- Comment #15 from Erwin Dokter er...@darcoury.nl ---
I also have a problem understanding 'dirty diffs'. Where does parsoid get its
HTML from? I thought it converted wikitext to HTML and then back. So how does
the parser even come into play?
https://bugzilla.wikimedia.org/show_bug.cgi?id=56809
--- Comment #16 from ssas...@wikimedia.org ---
Parsoid converts wikitext to HTML and back. Tidy does not enter the picture at
all in the Parsoid pipeline.
There are two separate issues:
1. Parsoid uses the same set of PHP parser tests to make
https://bugzilla.wikimedia.org/show_bug.cgi?id=56809
--- Comment #17 from ssas...@wikimedia.org ---
(In reply to Erwin Dokter from comment #15)
I can't help but feel that this issue is a major blocker for any parser
improvement in the future, so I want to understand exactly where the problem
https://bugzilla.wikimedia.org/show_bug.cgi?id=56809
--- Comment #18 from Erwin Dokter er...@darcoury.nl ---
Re: a\n\n*b
I don't understand where the extra newline comes from, as the parser outputs
only one. Regardless... perhaps we need to go about this another way.
There should be a simple
https://bugzilla.wikimedia.org/show_bug.cgi?id=56809
--- Comment #19 from Gabriel Wicke gwi...@wikimedia.org ---
(In reply to Erwin Dokter from comment #18)
* block level elements (including list itema) must be terminated with e
newline
* all other (inline) elements should not
Would that
https://bugzilla.wikimedia.org/show_bug.cgi?id=56809
--- Comment #20 from Erwin Dokter er...@darcoury.nl ---
OK, this discussion is not going to end in the next couple of hundred years,
partly because I will never understand what is really going on. I still don't
know where parsoid is getting its
https://bugzilla.wikimedia.org/show_bug.cgi?id=56809
--- Comment #21 from ssas...@wikimedia.org ---
(In reply to Erwin Dokter from comment #20)
OK, this discussion is not going to end in the next couple of hundred years,
partly because I will never understand what is really going on.
Do you
https://bugzilla.wikimedia.org/show_bug.cgi?id=56809
--- Comment #22 from Erwin Dokter er...@darcoury.nl ---
Ah, so it is only the *tests* that are affected. I think I understand now.
Still my question remains: can I make the parser make a clean break *only*
between /li and li (as that is the
https://bugzilla.wikimedia.org/show_bug.cgi?id=56809
--- Comment #23 from ssas...@wikimedia.org ---
(In reply to Erwin Dokter from comment #22)
Ah, so it is only the *tests* that are affected. I think I understand now.
Not just tests. See part (2) in Comment 16.
Still my question remains: can
https://bugzilla.wikimedia.org/show_bug.cgi?id=56809
Gabriel Wicke gwi...@wikimedia.org changed:
What|Removed |Added
Priority|Unprioritized |High
--
You are
https://bugzilla.wikimedia.org/show_bug.cgi?id=56809
Erwin Dokter er...@darcoury.nl changed:
What|Removed |Added
CC||er...@darcoury.nl
---
https://bugzilla.wikimedia.org/show_bug.cgi?id=56809
--- Comment #9 from Bartosz Dziewoński matma@gmail.com ---
(In reply to comment #8)
Unless you come up with a working CSS solution (which I doubt you will), I
insist my patch be reinstated and Parsoid be fixed instead.
(Just a note that
https://bugzilla.wikimedia.org/show_bug.cgi?id=56809
Bartosz Dziewoński matma@gmail.com changed:
What|Removed |Added
See Also|
https://bugzilla.wikimedia.org/show_bug.cgi?id=56809
--- Comment #10 from Erwin Dokter er...@darcoury.nl ---
https://test.wikipedia.org/wiki/MediaWiki:Common.css contain current CSS for
hlist.
https://test.wikipedia.org/wiki/User:Edokter/sandbox contains the test cases.
Any suggested changes
https://bugzilla.wikimedia.org/show_bug.cgi?id=56809
--- Comment #11 from Erwin Dokter er...@darcoury.nl ---
(In reply to comment bug:39617#27)
The Tidy bug is what caused hlists to work in the first place, according to
what you're saying :)
Why is that even considered a bug? list items are
https://bugzilla.wikimedia.org/show_bug.cgi?id=56809
--- Comment #12 from Bartosz Dziewoński matma@gmail.com ---
(In reply to comment #11)
(In reply to bug 39617 comment #27)
The Tidy bug is what caused hlists to work in the first place, according to
what you're saying :)
Why is that
https://bugzilla.wikimedia.org/show_bug.cgi?id=56809
--- Comment #13 from C. Scott Ananian canan...@wikimedia.org ---
Just to guide the discussion, let's try to keep this bug concentrated on the
parsertest regressions in Parsoid and other extensions, and possible fixes for
that. Discussion of
https://bugzilla.wikimedia.org/show_bug.cgi?id=56809
--- Comment #14 from Erwin Dokter er...@darcoury.nl ---
That is a scoping problem; Tidy should simply not touch anything that comes out
of GeSHi (pre code). This is simply two external extentions clashing.
--
You are receiving this mail
https://bugzilla.wikimedia.org/show_bug.cgi?id=56809
Gerrit Notification Bot gerritad...@wikimedia.org changed:
What|Removed |Added
Status|NEW
https://bugzilla.wikimedia.org/show_bug.cgi?id=56809
--- Comment #1 from Gerrit Notification Bot gerritad...@wikimedia.org ---
Change 94443 had a related patch set uploaded by Cscott:
Revert Have list items occupy their own line
https://gerrit.wikimedia.org/r/94443
--
You are receiving this
https://bugzilla.wikimedia.org/show_bug.cgi?id=56809
ssas...@wikimedia.org changed:
What|Removed |Added
CC||ssas...@wikimedia.org
---
https://bugzilla.wikimedia.org/show_bug.cgi?id=56809
Bartosz Dziewoński matma@gmail.com changed:
What|Removed |Added
Component|Parser |General
https://bugzilla.wikimedia.org/show_bug.cgi?id=56809
Bartosz Dziewoński matma@gmail.com changed:
What|Removed |Added
CC|
https://bugzilla.wikimedia.org/show_bug.cgi?id=56809
--- Comment #4 from ssas...@wikimedia.org ---
Matma(In reply to comment #3)
Why does this cause dirty diffs? Can I get a link to such diff?
See the gerrit patch cscott linked to in the bug description
https://bugzilla.wikimedia.org/show_bug.cgi?id=56809
--- Comment #5 from Bartosz Dziewoński matma@gmail.com ---
I've already seen the patch and sadly it is not telling me anything. What does
a dirty diff mean here? A dirty diff during after editing a page with
VisualEditor? Because that's the
https://bugzilla.wikimedia.org/show_bug.cgi?id=56809
--- Comment #6 from ssas...@wikimedia.org ---
Also, see https://gerrit.wikimedia.org/r/#/c/93626/ where I started messing
with Parsoid to prevent these dirty diffs, but it seems a lot more pain than
worth it currently -- it is mostly a
https://bugzilla.wikimedia.org/show_bug.cgi?id=56809
--- Comment #7 from ssas...@wikimedia.org ---
(In reply to comment #5)
I've already seen the patch and sadly it is not telling me anything. What
does
a dirty diff mean here? A dirty diff during after editing a page with
VisualEditor?
35 matches
Mail list logo
