Allow one blank line in list environments
Closed, DuplicatePublic
Actions

Assigned To

None

Authored By

	AzaToth
	Mar 19 2007, 6:19 PM

Description

Especially on talk pages, discussion lists can be rather too compact, and making
it difficult to find the right line in the mess. I suggest to allow one blank
line in a list. Will apply a patch showing how it could be done.

Version: 1.9.x
Severity: enhancement

Details

Reference: bz9342

Related Objects
Search...

		Status	Subtype	Assigned	Task
		Duplicate		None	T11342 Allow one blank line in list environments
		Duplicate		None	T3115 Newline as list item terminator is troublesome

Event Timeline

• bzimport raised the priority of this task from to Low.Nov 21 2014, 9:35 PM

• bzimport added projects: MediaWiki-Parser, Newparser.

• bzimport set Reference to bz9342.

• bzimport added a subscriber: Unknown Object (MLST).

AzaToth created this task.Mar 19 2007, 6:19 PM

the promized patch

attachment Parser.patch ignored as obsolete

robchur wrote:

What does this achieve, and how does it avoid breaking existing markup?
Recommend WONTFIX.

(In reply to comment #2)

What does this achieve, and how does it avoid breaking existing markup?
Recommend WONTFIX.

I though I made it clear. it is for enabling making list more readable. So the
both following lists will render the same list:

Or create mixed lists

and nest them

like this

*#*; definitions

*#*: work:

*#*; apple

*#*; banana

*#*: fruits

Or create mixed lists
- and nest them
  - like this

*#*; definitions
*#*: work:
*#*; apple
*#*; banana
*#*: fruits

minor fix

Attached:

Parser.patch1 KBDownload

One common display of mess, is discussions and vote pages, where it can look
like this (taken from
http://en.wikipedia.org/wiki/Wikipedia:Requests_for_adminship/Phaedriel_2 ):
#'''Enthusiatic Support''' - I've been a [[User:Phaedriel|Phaedriel]] Fan since
before I even registered on WP. Being able to support her for Admin gives me a
warm fuzzy glow. --[[User:Doc Tropics|Doc Tropics]] [[User talk:Doc
Tropics|Message in a bottle]] 04:33, 29 July 2006 (UTC)
#'''I guess support... ;)''' -- I thought I'd leave Phaedriel hang before she
knew if I'd support or not. I'm only supporting anyway cause she's a cop & I
want some "favours"... ;). Plus I want her to get to 200 votes.... [[User:Spawn
Man|Spawn Man]] 04:42, 29 July 2006 (UTC)
#'''Strongest support possible and then some:''' Phaedriel is without a doubt
one of the kindest and most level-headed editors here on wikipedia. We need more
administrators who really care about the editors here, and Phaedriel will be one
of them. I've been waiting for this nomination for a while now. '''The''' [[User:The Ungovernable Force|'''Ungovernable''']] [[User talk:The Ungovernable
Force|'''Force''']] 05:11, 29 July 2006 (UTC)

No question from my mind, support. I need more people like her on the admin

team. [[User:Zscout370]] [[User_talk:Zscout370|(Return
Fire)]] 06:03, 29 July 2006 (UTC)
#'''Incredibly strong support''' - an amazing editor [[User:Mike 7|Michael]]
06:24, 29 July 2006 (UTC)
#'''Strong support'''. While most of what I could say has already been said, I
have to reply to Ligulem's comment. While the technical side of Wikipedia's
administration is clearly important (as I'm beginning to pick up PHP so I can
actually ''code'' some bugs out of existence and not be limited to reporting
them), it is not the only thing that requires attention, and not working on it
should not be something that should be held against a particular nominee.
There's much more to adminship than a few buttons: remember that you're becoming
one of the public faces of a Top-20 website, and your actions may be the
examples new users look upon. Certainly, Phaedriel here is one of the editors
who I would certainly look at as how the ideal comminity user should be, and
adminship would just make her spotless behavior more prominent as the ideal
example I mentioned. Even in this case, she has demonstrated quite good grasp of
the technical side of Wiki, so I can't hold that against her. In a way, she is
precluded from working on the MediaWiki namespace, where her design abilities
would be most beneficial, because she still doesn't have the
[[Wikipedia:Revert|mop]] and the [[Wikipedia:Blocking policy|flamethrower]];
either way, I would trust her with both. Add one to the tally from here.
[[User:Titoxd|Tito]][[Wikipedia:Esperanza|xd]]([[User talk:Titoxd|?!?]]) 06:59,
29 July 2006 (UTC)
#'''Jump on the bandwagon Support''' per the >hundred people above me.
{{unsigned|Daniel.Bryant}}
#'''A jar of iguanas Support''' -- Simply positively stupendous. Greatly
jaw-dropping double-thumbs-up doubleplusgood. Absolutely terrific completely and
totally delicious. --'''[[User:CakeProphet|The Prophet
Wizard of the Cray]][[User
talk:CakeProphet|on Cake]]''' 08:17, 29 July
2006 (UTC)

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

herd wrote:

Isn't this a dupe of bug 1115 ?

smccandlish wrote:

This is definitely a dup of bug 1115 and bug 1584, just from a different perspective. I'd suggest that 1584 is the "best" of the three. Bug 6200 is also half a dup of this (and half about <blockquote>). Someone with the right bits should consolidate these, and maybe something will get done about it.

Punting this to the new parser Brion has under development.

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

sumanah wrote:

+need-review to signal to developers that this patch needs a response

audreyt wrote:

Hi Carl, 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!

(In reply to S. McCandlish from comment #8)

This is definitely a dup of bug 1115 and bug 1584, just from a different
perspective.

But bug 1115 is duped to bug 1584 and this bug is currently marked as depending on a closed bug, what a mess. Merging to bug 1584 so that it's visible there.