Firstly, I disagree with you about what users will expect. Behaviour in most visual editors, notably including Google Docs and Microsoft Word, is that you cannot prepend to a list other than by splitting the first item (i.e., by placing the cursor between the first bullet or enumerator and the start of the content on the first list item, and pressing 'Return').

If you follow your instructions, you're creating a second, separate list before the original list, and then wanting the software to magically know that you want them merged, which is somewhat complex behaviour that we don't currently support well, so we should create a bug for that. However, I'm inclined to close this as a WONTFIX. Thoughts?

(In reply to comment #1)

Firstly, I disagree with you about what users will expect. Behaviour in most
visual editors, notably including Google Docs and Microsoft Word, is that you
cannot prepend to a list other than by splitting the first item

I believe going to a preceding paragraph and clicking the "make list" button also prepends to a list in Word. Google Doc's list handling is different, admittedly. I'm having trouble reminding myself of what annoyed me about the VE's current response ("Error loading data from server: Invalid response from server") though -- so it could have been something relatively minor that just bugged me for a while.

s/a preceding paragraph/the preceding paragraph (line)/

(In reply to comment #2)

(In reply to comment #1)

Firstly, I disagree with you about what users will expect. Behaviour in most
visual editors, notably including Google Docs and Microsoft Word, is that you
cannot prepend to a list other than by splitting the first item

I believe going to a preceding paragraph and clicking the "make list" button
also prepends to a list in Word.

Yeah; we may want to ape this, but it's a lot of work for relatively little benefit and I think we can punt it to a later date - see bug 42115.

Google Doc's list handling is different,
admittedly. I'm having trouble reminding myself of what annoyed me about the
VE's current response ("Error loading data from server: Invalid response from
server") though -- so it could have been something relatively minor that just
bugged me for a while.

Yes, sorry, we're midst-deploy right now, hence errors. Give us five minutes. :-)

Okay, right, figured it out. It's the randomly inserted blank paragraph that's annoying me. Even GDocs doesn't do that (it assumes you've got two lists next to each other); moreover, it's not the same behaviour as when you've got a paragraph next.

Any thoughts James on preventing the creation of that weird blank paragraph?

The "weird blank paragraph" is what a "slug" - a place in the editing interface where the user can insert some content. It needs to be there so that users can successfully place content between blocks, but it isn't an entire line (depending on your User Agent) - once you start entering content, it expands to be the same size as a "real" paragraph, however.

An example of this is nested lists - in MediaWiki you can jump straight down to a second level of lists, but in HTML editing you still need to give the user some way to edit the list they're not in. This is why this wikitext:

Hello

• There

... produces this in the VisualEditor:

Hello

• • There

... the middle "line" is a "slug" that will disappear once you save, but if you need to insert text that's where you can go.

We're considering coming up with a little icon, perhaps a little like the cursor character, to make it clear that it's an insertion point rather than an actual blank line, but we're at early days yet.

Hmm, yes. I can certainly understand the case with (pre-existing) lists. But witness that neither of the two other editors mentioned put a slug (or indeed anything else) between the two adjoining lists created when one inserts a paragraph before a list and then presses the listify icon.

(For Word, it would make no sense for them to because it's not two adjoining lists, just two adjoining list items; for GDoCs they just don't.)