Page MenuHomePhabricator

pre over multiple lines in lists
Closed, DuplicatePublic

Description

Author: c.dittberner

Description:

------- examples start -------

==origin==
<ul><li>line before  <pre>multiple lines
multiple lines
multiple lines</pre> line after
</li></ul>

==example 1==
*line before  <pre>single line</pre> line after
==example 2==
*line before  <pre>multiple lines
multiple lines
multiple lines</pre> line after
==example 3==
*line before  <pre>multiple lines
*:multiple lines
*:multiple lines</pre> line after

------- examples end -------

Example 2 or 3 should be rendered like the origin.


Version: 1.4.x
Severity: enhancement
See Also:

Details

Commits
Unknown Object (Diffusion Commit)
Reference
bz1581

Event Timeline

bzimport raised the priority of this task from to Low.Nov 21 2014, 8:13 PM
bzimport set Reference to bz1581.
bzimport added a subscriber: Unknown Object (MLST).

ian wrote:

Did you try example 2 like so:

example 2

*line before <pre><nowiki>multiple lines
multiple lines
multiple lines</nowiki></pre> line after

I have a problem though with the next bullet, for example:

example 4

#line before <pre><nowiki>multiple lines
multiple lines
multiple lines/</pre> line after
#bullet after

Results in the "bullet after" line not getting the <li></li> and the </ol>
ending after the </pre>

ian wrote:

I should note I'm running MediaWiki 1.4.2 + ENotif+EAuthent v3.09

c.dittberner wrote:

(In reply to comment #1)

Did you try example 2 like so:

example 2

*line before <pre><nowiki>multiple lines
multiple lines
multiple lines</nowiki></pre> line after

No, I tried it like I wrote ;)

IMHO it is a "pre-render-bug in list context". We wanted to use mediawiki as
knowledge database solution. Therefore the usage has to be fast and simple AND
''consistent''.
It mustn't be the solution to include a parser error in nowiki-tags.

ian wrote:

Isn't this a duplicate of bug 785?

brion added a comment.Jun 23 2005, 6:29 PM

Multi-line markup isn't even *expected* to work in lists. This may just be bug 785 and bug 1115.

brion added a comment.Oct 21 2005, 9:13 PM
  • Bug 3768 has been marked as a duplicate of this bug. ***
  • Bug 3989 has been marked as a duplicate of this bug. ***

jiangxin wrote:

#list1
#:<pre>
blah blah blah
</pre>
#list2

My patch on this is here: http://meta.wikimedia.org/wiki/User:Jiangxin/Patch_Indent_Pre

jiangxin wrote:

I have one single solution to fix both this(bug 1581) and another bug (1115).
Please check it:

  • Bug 6333 has been marked as a duplicate of this bug. ***
brion added a comment.Jul 13 2006, 6:29 PM
  • Bug 6668 has been marked as a duplicate of this bug. ***
brion added a comment.Jul 21 2006, 4:47 AM
  • Bug 6764 has been marked as a duplicate of this bug. ***
brion added a comment.Sep 26 2006, 2:43 PM
  • Bug 7417 has been marked as a duplicate of this bug. ***

ayg wrote:

*** Bug 9989 has been marked as a duplicate of this bug. ***

brion added a comment.Sep 26 2007, 6:27 PM
  • Bug 11455 has been marked as a duplicate of this bug. ***

Parser test

Parser test for the following input:

*line before <pre>multiple lines
multiple lines
multiple lines</pre> line after
*line before <pre>multiple lines
*:multiple lines
*:multiple lines</pre> line after

Attached:

ingo.rohloff wrote:

Patch to fix <pre> in lists problem

The PHP code actually looks like this patch implements the INTENDED behaviour.

attachment pre_in_lists.patch ignored as obsolete

ingo.rohloff wrote:

Patch to fix <pre> in lists problem 2nd try

Ok, seems the patch has to do a little bit more.

Some more explanation:
the "mInPre" flag in "Parser.php" already is used to handle the interaction between lists and "<pre>" flags.
For example
<pre>

  1. first line
  2. second line

</pre>
already escapes the interpretation of the "#" signs. So this will NOT generate a list.

From this "mInPre" handling it seems obvious that

  1. first line
  2. second line <pre> some preforamatted text with more than onle line

</pre>

third line

should also work and the code in "Parser->doBlockLevels" already ALMOST allows it. To me it seems the whole "mInPre" stuff already was supposed to handle the above WIKI markup.
I think my patch just fixes the "Parster->doBlockLevels" code in the sense that it provides the INTENDED behaviour.

Attached:

*Bulk BZ Change: +Patch to open bugs with patches attached that are missing the keyword*

audreyt wrote:

Hi Carl & Ingo, thank you for the patch!

As you may already know, MediaWiki is currently revamping its PHP-based parser into a "Parsoid" prototype component, to support the rich-text Visual Editor project:

https://www.mediawiki.org/wiki/Parsoid
https://www.mediawiki.org/wiki/Visual_editor

Folks interested in enhancing the parser's capabilities are very much welcome to join the Parsoid project, and contribute patches as Git branches:

https://www.mediawiki.org/wiki/Git/Tutorial#How_to_submit_a_patch

Compared to .diff attachments in Bugzilla tickets, Git branches are much easier for us to review, refine and merge features together.

Each change set has a distinct URL generated by the "git review" tool, which can be referenced in Bugzilla by pasting its gerrit.wikimedia.org URL as a comment.

If you run into any issues with the patch process, please feel free to ask on irc.freenode.net #wikimedia-dev and the wikitext-l mailing list. Thank you!

scfc added a comment.Oct 7 2012, 3:28 AM
  • Bug 22785 has been marked as a duplicate of this bug. ***
Anomie added a comment.Apr 9 2013, 4:01 PM
  • Bug 25384 has been marked as a duplicate of this bug. ***
Anomie added a comment.Apr 9 2013, 4:02 PM
  • Bug 32365 has been marked as a duplicate of this bug. ***
Diffusion closed this task as Resolved by committing Unknown Object (Diffusion Commit).Mar 4 2015, 8:22 AM
Diffusion added a commit: Unknown Object (Diffusion Commit).
Umherirrender reopened this task as Open.EditedMar 4 2015, 5:14 PM

Do not see why this was closed by Diffusion with the hint to rPHAB3742e0f4f6ef

Update: Found T91488

He7d3r updated the task description. (Show Details)Jun 7 2015, 4:57 PM
He7d3r set Security to None.
Meno25 removed a subscriber: Meno25.Jan 17 2017, 4:25 PM