(In reply to comment #0)

a user has suggested

This was me. Here's my comment from [[Wikipedia:VisualEditor/Feedback]]:

If you look through many of the comments on this page (in some cases you
need to read between the lines), you will see that people are trying to
create a wikilink in VisualEditor using [[ ]] wikitext syntax. I am
suggesting that, to accommodate these users, a sort of autocorrect be
implemented, so that when [[ ]] links are entered, they are automagically
converted into proper VE-style links

As well as a helpful "transition" feature from wikitext to VE, it might also be useful in the long run as a shortcut for power users, since keystrokes are generally faster than mouse interaction.

Probably a lower priority enhancement though :)

Sorry, just clarifying, this wasn't intended to happen "on save". This should probably happen as soon as (e.g.) the ]] is typed after a link, à la AutoCorrect.

Another possibility I mentioned in bug 49820 is to display a warning of some sorts to remind people that wikicode isn't supported (similar to how LiquidThreads reminds users who insert ~~~~ that their signature will be automatically inserted). Automagical conversion might be better, but a warning could be a good first step.

I'm ambivalent about whether we would ever let this go live, given how complicated it would make editing for people that don't know wikitext - consequently, marking as lowest priority for now.

(In reply to comment #4)

I'm ambivalent about whether we would ever let this go live, given how
complicated it would make editing for people that don't know wikitext -
consequently, marking as lowest priority for now.

You and I discussed this idea at some point (thanks for filing this as a bug, Oliver). The current issues I'm seeing with VisualEditor are that:

(1) it's much more time-consuming to add a link (i.e., typing "[[]]" is quick while finding and using the link dialog box is slow, especially multiple times); and

(2) it requires the use of a mouse to add a link. :-(

Adjusting VisualEditor to interpret [[]] as a link would be a nice enhancement, though I see the danger in heading down this road.

Perhaps we need a "I'm old school" checkbox somewhere in VisualEditor. ;-)

(In reply to comment #5)

(In reply to comment #4)

I'm ambivalent about whether we would ever let this go live, given how
complicated it would make editing for people that don't know wikitext -
consequently, marking as lowest priority for now.

You and I discussed this idea at some point (thanks for filing this as a bug,
Oliver). The current issues I'm seeing with VisualEditor are that:

(1) it's much more time-consuming to add a link (i.e., typing "[[]]" is quick
while finding and using the link dialog box is slow, especially multiple
times); and

(2) it requires the use of a mouse to add a link. :-(

Not true, as discussed; I don't use the mouse to add links with VE (Ctrl+K plus keyboard-based selection, as in other editors).

Perhaps we need a "I'm old school" checkbox somewhere in VisualEditor. ;-)

If users are sufficiently new-school that they can't remember Ctrl+K I don't think there's much hope for them. :-)

(In reply to comment #6)

(2) it requires the use of a mouse to add a link. :-(

Not true, as discussed; I don't use the mouse to add links with VE (Ctrl+K
plus keyboard-based selection, as in other editors).

Ah, right. I vaguely remember that cmd-K controls the hyperlink functionality in Microsoft Office products. I have no idea how anyone would glean this from VisualEditor.

(In reply to comment #7)

(In reply to comment #6)

(2) it requires the use of a mouse to add a link. :-(

Not true, as discussed; I don't use the mouse to add links with VE (Ctrl+K
plus keyboard-based selection, as in other editors).

Ah, right. I vaguely remember that cmd-K controls the hyperlink functionality
in Microsoft Office products. I have no idea how anyone would glean this from
VisualEditor.

Hover over the button; the tooltip tells you the keyboard shortcut. :-)

Indeed, I think we should close this as WONTFIX. We should improve any efficiency or discoverability issues in VisualEditor, and help give users experienced with wikitext clues to not accidentally insert it in VisualEditor. See bug 50601 for one potential approach to the latter problem.

Wiki markup was an awesome in invention in 1995, helping users not have to type HTML in order to format documents. But that doesn't mean the most efficient conceivable user experience in 2013 ought to be bound to the same design principles. (Nor should we blindly copy existing point and click interfaces -- for navigating the complexity of templates and such, we may have to come with some truly novel interfaces.)

Marking as WONTFIX per my earlier comments and Erik's.

nrp wrote:

WTG guys, piss off the user base even more with a WONTFIX on a no-brainer...

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

based on:

bug 51554
bug 51944
bug 51462
bug 50527

and a dozen or so more (as seen here:
https://bugzilla.wikimedia.org/buglist.cgi?query_format=specific&order=relevance%20desc&bug_status=__open__&product=VisualEditor&content=nowiki&list_id=219956

i changed this one to "reopen" and marked it "high".

peace.

turingt wrote:

For what it's worth, I find that "[[" is a very good accelerator key - mainly because it's already known and remembered by a huge portion of your user base, myself included.

And Erik, wikitext is still awesome today - it's the only known way to allow users to create semantic-enhanced content. The VisualEditor is good for laying out formatted text on a page, but the relations between concepts placed at different pages are better created by adding tags (links, categories, templates...) to the content. The current VE interface mostly hides those tags and requires handling complex dialogs to introduce or edit them, which makes it less convenient for introducing semantics than wikitext. That's why people is requesting smoother and seamless ways to switch between the VE and the source editor.

If you want an "accelerator key" for making links, use the standard one: Ctrl + K (or Cmd + K if you're on a Mac). This is the same shortcut as in Microsoft Word, OpenOffice, Google Docs, Apple Pages and more.

(In reply to comment #15)

If you want an "accelerator key" for making links, use the standard one:
Ctrl +
K (or Cmd + K if you're on a Mac). This is the same shortcut as in Microsoft
Word, OpenOffice, Google Docs, Apple Pages and more.

and "[[" is the same one as used by tens of thousands of wikipedia editors.
it's not even "a thing of the past" - source editor remains the only editor in many name spaces, and is still available in _all_ of them.

pissing on your user base is not a good way to handle software projects.

peace.

So, let's calm down here.

We're not "pissing on" anyone; we're choosing to prioritise. Right now the devs have got a lot of open bugs for the VisualEditor - things that actively /don't work/. They've got a lot of features still to build, and a lot of expectations about the project. Personally, I'm incredibly impressed with the speed of change and the patches that have been submitted so far - it's a fantastic workrate. But that doesn't change the fact that there's still a lot to do.

Now: we /can/ have wikitext converted to VE-compatible elements. But there are a few costs. First: from my conversations with the developers, I understand that doing it on the fly would slow the VE down very substantially. You'd have to automatically parse and re-render the page. Second: if they work on this, there's a lot of stuff that is going to get pushed back.

We have a VisualEditor. It's great, it's miles better than anything else produced to do this job in MediaWiki, but it still needs a lot of work and still has a lot of active bugs - problems parsing content, problems rendering content. If enhancements such as this (which would certainly be nice) are worked on, active breakage will take a back seat: those areas where it simply doesn't have features will take a back seat. I'm not comfortable with saying that we rate "being able to type markup into the VisualEditor" higher than "being able to manipulate tables".

As you note, the source editor is still available in all namespaces. Users who are actively prioritising familiarity with syntax, and their muscle memory, are welcome to use it. It's not going away. In the meantime, the VE development process should be focused on making it work full stop, not making it work for the users who are highly comfortable with source editing. That's nice, and it's something I'd love to see, but it's not going to happen if actual bugs aren't fixed first.

Sorry, but this is not something we'll ever do, as I explained in comment 9. It's not simply a matter of prioritization - it's a matter of ensuring we can provide a user experience that's not modeled on markup, but on best user experience practices. As James said, we provide keyboard shortcuts, and will provide other user interfaces optimized for markup. But parsing markup within the visual editing context is completely off the table.

"other user interfaces optimized for markup" -> "other user interfaces optimized for completing actions quickly in VisualEditor that are fast to do in markup"

Thank you very much for the clarification, Erik. I was just about to ask, following comment 17, whether this was truly a wontfix (i.e., patches will not be accepted) or whether it was simply a very low priority. :-)

(In reply to comment #17)

So, let's calm down here.

We're not "pissing on" anyone;

yes you are.
if you look at the different wikis, and if you search here with "product=visualeditor" and "search word=nowiki", you will find that one of the main complaints of editors in many projects (specifically enwiki and nlwiki), is the fact that users type "[[something something]]", and VE wraps it with "nowiki". this is clearly not what the editor meant to do

true, VE also jumps a popup message telling the editor "this is probably not what you meant", but there are two issues with that:

1. because of unrelated bug, this popup message is usually not even seen by the editor.
2. if the thing is cleaver enough to know that this is not what i meant, why can't it just Do the Right Thing (tm) ? (answer: of course it can, but the team decided to WONTFIX it).

this attitude of VE team - pissing on and pissing off the user base at the same time, already caused the editors in nlwiki to vote not to activate it in the planned date (and they can do it - you guys removed the switch - we can bring it back through common.js or through gadgets, and we can also make it "default". is a fight with the user base really what you need right now?).

why does it seem, with this and other bugs (specifically, insisting on hiding the preference to disable VE), that the VE team made a conscious (or maybe unconscious) decision to ignore the community and shun it?
what does the VE team expect to accomplish this way?

we want VE and we like VE, but you guys should do a better job listening to us when we tell you where it hurts.

peace.

We're listening, but in this case we're saying no, and that decision is final. We can elaborate a bit more on the why if that helps, but parsing wikitext in VisualEditor is absolutely not going to happen.

If accidental insertion of wikitext is still an issue, we should focus on other ways to mitigate that issue.

please look above: in comment 15, Forrester did some namedropping: "Microsoft
Word, OpenOffice, Google Docs, Apple Pages and more".

well, in all this products, when i misspell a word, the thing silently and valiantly just fix my mistake, instead of shouting at me[1].
generally, this is known as "Auto correct" (sometimes also [[DWIM]]: "Do What I Mean").

if really you use these products as your role model, please pick the good stuff, not the crappy stuff. who cares if the shortcut for "link" is <Ctrl>+K or <Ctrl>+L ?

why can't you adopt the real valuable features from them instead of the completely anecdotal ones?

when you recognize that the user did something they did not mean to do, such as mispelling a word (in M$ word) or typing [[Something something]] in VE, just Do What the User Meant.

peace.

[1] i cheated - i am not actually sure if it's really "in all those products". i know it's in most of them.

(In reply to comment #23)

well, in all this products, when i misspell a word, the thing silently and
valiantly just fix my mistake, instead of shouting at me[1].
generally, this is known as "Auto correct" (sometimes also [[DWIM]]: "Do
What I Mean").

[...]

when you recognize that the user did something they did not mean to do, such
as mispelling a word (in M$ word) or typing [[Something something]] in VE,
just Do What the User Meant.

Computers can't read minds and they monumentally struggle with understanding context. When I type "subst" into OS X (as in template substitution), it autocorrects to "subset" because surely that's what I meant, right?

I completely agree with you that [[muscle memory]] here is an issue. And I completely agree that we need to find ways to make linking as painless as possible in VisualEditor (we're not there yet). But part of meeting user expectations is to take input (such as "[[foo]]", which displays as "[[foo]]" in VisualEditor) and output it as the user saw it in the editor.

These type of magical transformations won't be supported in VisualEditor and I think that's a reasonable position to take. However, it should be completely possible to create a JavaScript gadget that can enhance the user experience for those who have a deep understanding of the difference between source editing and visual editing and who would like a hybrid option. I'd pursue this. :-)

i am not sure you understand the precise nature of this request, so let me elaborate:

what we ask (at least, this is what i asked - see bug 51897, which was marked as duplicate of this one) is that when the user types "[[", VE will remove the "[[" from the page, and behave as if the user typed <Ctrl>+K, i.e. open the "Link" form.

simple and easy, VE already recognizes that the user typed "[[" - all we ask is that instead of jumping less-than-useful-and-often-out-of-screen popup, VE will do something good and useful for the community, for society, and for humanity.

in the same way, when the user types "{{", remove it from the page and behave as if she clicked on the puzzle piece, instead of jumping the less-than-useful popup.

easy to do, simple, and does not go against any principle in UI design, except sheer stubbornness of the VE team.

unfortunately i am not able at this time to provide a patch, but 92.24% of the code is already in place - just find where VE jumps the popup, and do something useful instead.

peace.

(In reply to comment #25)

what we ask (at least, this is what i asked - see bug 51897, which was marked
as duplicate of this one) is that when the user types "[[", VE will remove
the "[[" from the page, and behave as if the user typed <Ctrl>+K, i.e. open
the "Link" form.

Yep, I think everyone commenting on this bug understands the request. :-)

The problem is, as stated, computers aren't very good at reading minds or understanding context. You want to support "[[" magically transforming into a VisualEditor link. This is certainly possible to implement, but then you naturally have to support:

• [[foo]]
• [[foo]]s
• [[foo|bar]]
• [[w:foo]]
• [[w:foo|]]
• [[w:en:foo (bar)|]]
• [[WP:FOO]]

When a user types "[[File:foo.png]]", do they really mean they want a link to the file or do they really mean they want to include the file?

What about "[[Category:foo]]"? It's often trivial for humans to understand what we mean or to understand what other humans mean, but computers... not so much.

Once we add support for [[]] magically transforming into a link, does that mean we also have to support magic words such as {{DEFAULTSORT:}}, NOTOC, and so on? What about ParserFunctions such as {{#time:}} and {{#if:}}?

And, of course, a certain percentage of users will want to actually include brackets ("[" and "]") in their edits. How do they undo the magical transformation?

Down this path, madness lies, I promise.

easy to do, simple, and does not go against any principle in UI design,
except sheer stubbornness of the VE team.

The VE team has certainly exhibited some stubbornness. But I personally agree with their decision here.

unfortunately i am not able at this time to provide a patch, but 92.24% of
the code is already in place - just find where VE jumps the popup, and do
something useful instead.

A patch to VisualEditor or to MediaWiki will not be accepted. However, users are welcome to create JavaScript gadgets, personal JavaScript subpages, client-side scripts (think Greasemonkey), or even implement site-wide JavaScript with appropriate community consultation and consensus.

i still do not think you understood the request.
it's not about transforming [[Foo]] to a link, it's about not getting [[Foo]] into the page in the first place: as soon as the user types "[[", the "[[" should be removed from the page and interpreted as <Ctrl>+K.

as to your questions about File:Foo.jpg or Category:Foo: what does VE do today when someone presses <Ctrl>+K and then feeds "File:Foo.jpg" or "Category:Foo" ?
whatever it does today, this is what i expect it to do when someone types "[[" and then feeds in the link form "File:Foo.jpg" or "Category:Foo".

(In reply to comment #25)
......
And, of course, a certain percentage of users will want to actually include
brackets ("[" and "]") in their edits. How do they undo the magical
transformation?

these are just straw arguments.
there are many many many things one can't do now using VE. it will not at all be so bad if the extremely rare case of having to add "[[" to the page within "nowiki" tags will be one of them.
definitely much much better than current situation, where hundreds of edits with "[[" enclosed inside "nowiki" tags are added to enwiki daily, when the editors actually intended to add a link (i did not count them myself - this is what i'm led to believe based on reports of editors who actually clean this mess).

peace.

There are at least two separate requests here. They are related in that they both want to change the current behaviour of the two character sequence "[[" in VisualEditor but they want to change it in incompatible ways.

Kipod is asking for the key sequence [[ to be treated the same as the key sequence ctrl+k. It is not asking for, nor would it require any changes to rendering. For the purposes of this comment I'll refer to this as "Kipod's request"

MZMcBride is commenting the original request which was for the sequence [[link]] to be parsed (either at save or on the fly) as if it were a link added using the link inspector. For the purposes of this comment I'll refer to this as the "original request".

The two are not the same and the past few posts have seen people talking past each other.

I can see the merits of the original request but I can also see where the VE team are coming from. The desire stems from people wanting the best of both worlds - they want to be able to have the structure and layout of the visual editor with the low-level control they are used to in the source editor all in one place. Long term something like this really ought to be possible, but I don't think this is the way. Rather there should be some way for the visual editor to include non-visual blobs that it sends to the parser as is without doing anything to it (other than word wrapping in the editing window); and some way for the editor to mark the start and end of such blobs. This is not what the original request is asking for though.

Kipod's request is something that imho should not be included as a default, as while [[word]] or [[short phrase]] are unlikely to be anything other than links, [[ on it's own is far more ambiguous and there is more scope for the desired action to be something other than inputting a link. Rather there should either be a built-in method for users to define their own shortcuts or a simple way (an API?) for a gadget that allows users to reliably define their own shortcuts to have the same effect without needing to be rewritten every time VE or some other mediawiki component is updated.

I recommend that if anyone wants further discussion on either request that the bugs are unmerged.

i think you are correct stating that these two "definitions" of the enhancement request are not identical.
however, i came here to bug you guys with "my" definition of the request after Forrester closed bug 51897 with "duplicate". the bug he closed listed my request exactly.
maybe instead of coming here, what i should have done is to reopen and remove the "duplicate" designation.

my guess is that it wouldn't make a huge difference - the team would have closed it as "WONTFIX" instead of closing it as "DUPLICATE". i took them on their word about these two request being one and the same - maybe it was a mistake. (afaik, Forrester is part of VE team).

as to "[[" being ambiguous: i did not dive deeply into it, and did not conduct extensive tests, but i think that typing "[[" anywhere on the page will cause VE to jump the "wikicode detected" popup. as a wikicode, "[[" is not ambiguous at all, i think. it means "start internal link here".

peace.

oh, and what you describe as "the ideal solution", sounds a lot like bug 51899 to me.

peace.

I think that James' marking your bug as a duplicate was likely caused by his misunderstanding your request. He is part of the VE team but I have met him at Wikimeets a few times and I can assure you he is human.

As for Bug 51899, yes that is a perfect match. Thank you.

(In reply to comment #28)
Thank you for clarifying the two requests, Chris. That was super-helpful. :-)

(In reply to comment #29)

maybe instead of coming here, what i should have done is to reopen and remove
the "duplicate" designation.

My apologies, kipod. Thank you for patiently putting up with me. Indeed, I think bug 51897 is not a duplicate of this bug. My comments were strictly related to the original request here on bug 49686.

I don't know what the VisualEditor team's view is on your request at bug 51897, so I'm going to go ahead and un-dupe bug 51897 now. Bug 51897 may also eventually be marked resolved/wontfix, but it doesn't seem to be within the scope of this bug, so it should be handled separately.

(In reply to comment #31)

I think that James' marking your bug as a duplicate was likely caused by his
misunderstanding your request. He is part of the VE team but I have met him
at Wikimeets a few times and I can assure you he is human.

the last line makes me think that maybe some of my comments can be read in a way that does not fully match the spirit in which they were written.

although i have criticism, especially toward the perceived attitude of VE team towards their user base, i never meant to say or hint any of them is a bad person or less than brilliant developer.

as i already said in this thread, i think VE itself is a great thing, we want it, we need it, and we want it to succeed.

hope that heated and less-than-polite things said in this (and maybe other) discussions will not be taken as attacks - it is/was never the intention to attack anyone.

peace.

Wikifram wrote:

Erik Moeller, do you have any idea how many hours are spent on correcting these "nowikis" every day? Do you, on the other hand, have any data on how many "correct" nowiki tags are added? Is there any reason why what should be a no-brainer (not per se an easy one technically, but a no-brainer from the should-be-done point-of-view) improvement is so drastically rejected?

Have any of you considered that, as of now, new editors using only VE and only editing the mainspace still need to know the [[ ]] syntax anyway? A simple example: on the English wikipedia, I opened [[HKBK College of Engineering]] with the VE, and clicked on the infobox. Click on a parameter, e.g. city, and what you are confronted with is [[Bangalore]]. So new editors ''need'' to use it in the infobox, but are ''not allowed'' to use it in the article text, and this is supposed to be an improvement why?

What is actually the reason (apart from perhaps "technical difficulty") that square brackets are no longer allowed as an alternative method of creating wikilinks? No one is asking to disable the VE wikilinking methods, but no one seems to understand the insistence of the WMF on disallowing the square brackets method either.

Wikifram wrote:

Note that this question is included in the large [[Wikipedia:VisualEditor/Default State RFC]] on the en.wikipedia, as question 5. The current tally, for what's it worth, is 28 supporting and 22 opposing, but with many conditional comments on both sides ("yes for X but no for Y"). Many of the opposes are "no, because this is a WYSIWYG", but in reality, of course, this isn't a wysiwyg but a hybrid anyway... (you still need to know wikimarkup to do a lot of things in the new editor in mainspace as well)

Amalthea.wikimedia wrote:

Erik:

(In reply to comment #18)

it's a matter of ensuring we can provide a user experience that's not modeled
on markup, but on best user experience practices.

I don't think that was the suggestion above?

Word processors have long supported text-based auto formatting logic, and they certainly aren't focusing on underlying markup. For example, to this day, you can *bold* and _italicize_ text in OpenOffice Writer and Microsoft Word by using the traditional markup, or define numbered and bulleted lists simply by starting the first item with "* ", "- ", or "1. ".

Adding auto-formatting logic does not impair the goals of the visual editor: defining a link via square brackets won't be the obvious way, and it will likely not be advertised anywhere except possibly in some settings page. It can be helpful without taking anything away from the vision.

(In reply to comment #22)

If accidental insertion of wikitext is still an issue, we should focus on
other
ways to mitigate that issue.

2 things:

1. it's not an "if", and i do not think you guys should wait for the community to prove it to you. you should go hunt for it, so you can see for yourselves that it *is* an issue (hint: look for edits with "visualeditor" tag that added <nowiki>: approximately 100% of those represent the problems. you have to tools to actually measure it across all projects where VE is enabled by default).
2. "focus on other ways to mitigate that issue": how about solving bug 51897, instead of marking it "low" and basically ignoring it? this *is* exactly "other ways to mitigate that issue".

or ,alternatively, find a better way to solve it: right now, it seems the team is saying "we'll focus on other ways to mitigate the issue", but they do not actually mean it: what other ways? who is working on it? what do they do? where is the "focus"?
what you guys are doing today does not look very much like "focus" - it looks much more like ignoring the issue and hoping the problem will go away by itself.

(In reply to comment #18)

Sorry, but this is not something we'll ever do, as I explained in comment 9.
It's not simply a matter of prioritization - it's a matter of ensuring we can
provide a user experience that's not modeled on markup, but on best user
experience practices. As James said, we provide keyboard shortcuts, and will
provide other user interfaces optimized for markup. But parsing markup within
the visual editing context is completely off the table.

this is nothing more and nothing less than saying "it's so because i said so".
you made a bad decision. that's something that happened in life to (almost) all of us. the problem is not so much this bad decision - the problem your refusal to accept that it was a bad decision, and you insistence that it was a good decision, in face of all the evidence.

The reason i am writing this is because nowhere can i find any indication that the VE team actually changed its mind or at least decided to reconsider.
it is very much possible that the team actually *did* decide to reconsider, and i just missed it. if this is the case, please be graceful and ignore my rant.

peace.

user John Broughton at en.wp comments:
"Rather than focus on improving [the warning about entering wikitext], a better direction to go would be for VE to be able to convert wikitext to its equivalent in VE. Thus if one typed [[New York City]], for example, VE would convert that to its format for an internal link. This is fairly straight-forward, programming-wise: after VE adds a closing nowiki tag for some text, it would examine it for conversion possibilities: external link? internal link? footnote? template?"

(In reply to comment #10)

Marking as WONTFIX per my earlier comments and Erik's.

… again. Bug 51897 is indeed different; my apologies for merging it based on my reading of the bug as filed. However, this bug is - by definition of the product - a WONTFIX.

Amalthea.wikimedia wrote:

(In reply to comment #39)

[...] this bug is - by definition of the product - a WONTFIX.

James, this is simply not true. See comment #36 about auto formatting logic in other visual word processors.
I really don't get why you're fighting this so hard.

Wikifram wrote:

Can someone explain why [https://www.mediawiki.org/wiki/Communication?veaction=edit this page] seems to accept wikitext markup, even in VE mode? On saving, it gives the "nowiki" warning, but it doesn't actually convert the existing "[[" and "]]" into wikitext. A very strange page in VE mode, that one.

Hi there, I don't think I see your VEdit there. I did https://www.mediawiki.org/w/index.php?title=User%3AElitre_%28WMF%29%2FSandboxVE&diff=794415&oldid=794413 and https://en.wikipedia.org/w/index.php?title=User%3AElitre_%28WMF%29%2FSandbox&diff=575429594&oldid=575429509 instead, nowikis are added as the only expected outcome. Which conversion should have happened when VEditing? Thanks.

Wikifram wrote:

What I mean is that you start with wikimarkup visible in the VE editing mode. When you add something (''not'' wikimarkup) inside such wikimarkup, you get the wikimarkup notice at the top right; but on saving, the existing wikimarkup remains. [https://www.mediawiki.org/w/index.php?title=User%3AElitre_%28WMF%29%2FSandboxVE&diff=794444&oldid=794415]

So my questions are; why is the existing wikimarkup accepted and displayed here, why is it recognised by the wikimarkup detection error, but why is it then not changed on saving?

This behaviour may give a clue as to how wikimarkup can be accepted in VE after all (but then again, perhaps not), but it certainly is baffling me.

48891 and 53974 cover that specific problem. The wikimarkup warning is just a warning, it does not stop you from doing anything.
As for [[[[this situation]]]], of course it shouldn't happen. I can't recall the bug number though, right now, and since a quick search did not seem successful, I'll come back on that later.

I'll clarify that "it shouldn't happen" means just that it is not useful/desirable to have it IMHO, or at least I can't think of a situation where it would be.

(In reply to Amalthea from comment #40)

I really don't get why you're fighting this so hard.

It should be obvious by now that VE's development has been made an ideological matter. This feature request involves some degree of the "old way" of doing things, thus is forbidden.