Andreas, Matthias, I wondered whether you tried to select all content and use the 'Clear Formatting' option and how well that worked?

• previously I simply added a new line between them
• now placing the cursor in the table and pressing enter does create a new line - but in the table
• placing the cursor before the heading and pressing enter creates a new heading
  • so i'll have to use the mouse to "undo" the heading - then start typing

Nils, for a quick workaround of sorts, you can use the Keyboard Shortcuts to remove (and apply) the heading so you don't need to use the mouse when using your second approach.

Do you think instead of maintaining the heading format on the line you create between the bottom of the table/macro and the heading we should instead default it to a plain paragraph? I'm not sure which seems the more natural myself, interested in your thoughts.

Peter, interested in whether you were creating new pages or editing existing? How often do you need to do either ? How did you do it 3.5? If you document in a text editor did you know you can use the Insert > Wiki Markup dialog to put it straight into a page, would this work for you?

What's the use case behind this? Not something copy page can do? Have you tried copying from the Editor or View Source page?

How often do you do this on a mobile versus desktop?

I created my own Editable Table macro - which relies on saving its content by doing a form post with it's content as wiki-markup and html. The fact that wiki markup isn't processed in the new wiki editor breaks this macro.

Greg, can you let me know what limitations people are reporting?

Have you read Whats Changed for Wiki Markup Users? Very interested in your feedback if that didn't give you what you were after.

Diego Ballve

Jean-Yves Avenard

Shortcuts? I'm sure they are there.. but what about some simple list as the wiki markup list? And please don't tell me to click this icon or that icon, that is not what I'm after. Consider a help bar in the right side of the editor, for instance.

I can't remember all the keyboard shortcuts as there are so many of them

As above

Alex (posted Anonymously)

We do sometimes copy over parts of the text from JIRA to Confluence and back, and earlier the wiki markup mode allowed to keep text formatting fully same across both systems without any additional effort.Right now you can copy formatted text from JIRA to Confluence, if you highlight and copy it from the issue details page, not issue edit. However, this is not that handy, because you can't use Ctrl+A to actually highlight all the description text instantly. And obviously - there is no way now to copy formatted text parts from Confluence to JIRA.

Alex, I'd love to hear more details on your use case for this. Even before when both editors were using Wiki markup, it seems like a lot of manual work.

Interested to know whether the new Remote Issue Links functionality that is coming in JIRA 5.0 would help you. You can see this working on jira.atlassian.com right now, eg: because I've referenced CONF-24038 - Getting issue details... STATUS on this page there is an automatic issue link created to point back to here (as well as the obvious link from here to the JIRA case). I find this handy as then say a spec will be written in Confluence and easily linked to the JIRA case.

Seems to me the goal for us should be that we allow Confluence and JIRA to integrate in such a way that more value is created by using them together, and you wouldn't feel the need to copy/paste descriptions between them, so very keen to hear if Remote Issue Links helps or if it doesn't, more details on your needs.

As earlier you have claimed that implementing XML-to-wiki transformation is easy - I see no problem to still allow wiki edit, but with XML format on backend and disallow wiki if something too complicated was created through WYSIWYG.

This can easily be added as a plugin, to solve your problem with complains on the core software.

Anonymous

(In reponse to Alexy)

Todd Day

Andrew Spina

Keep wiki markup format by wrapping in a "wiki markup" macro

----

Todd - Ability to wrap entire pages in the Wiki Markup macro and not have them auto-convert to storage format. Additionally:

• Macros that come from plugins I currently use in 3.5 continue to work the same way in the wiki code block.  I'm willing to wait for the authors (Adapatvist, Customware, and the guy who wrote the LaTeX plugin) to upgrade their plugins for 4.0, but the end result must be that I can write in 4.0 wiki code blocks the same way I currently write in the 3.5 wiki editor.
• User macros I wrote for 3.5 need to also appear in the 4.0 wiki code blocks.
• When upgrading from 3.5 to 4.0, I want the upgrade process to wrap every page in a wiki markup block instead of converting it to the new XHTML format.
• Site and Space themes should be definable in terms of Wiki format.
• It would be nice if the wiki code blocks had a button on them that would convert to the new XHTML format if you pressed it.  I understand this would be a one-time no-reversal operation, and that would be fine with me.

----

Andrew

• I haven't read through this post, but this page says to post requests here. I'm new to confluence (and like it a lot), but was wondering why wiki markup is translated into a wysiwyg format after entry. I was wondering if it made sense to allow people to make a container (like a new column) which would preserve wiki markup, but render it on the saved page as rich text? I know it's not as friendly to non-technical users, but it seems a bit closer to the middle ground. Just a thought...

• See related issue at CONF-23895 - Getting issue details... STATUS

Treat macros and all special editor objects (images, links, etc) the same - i.e. they would all have a frame.

Currently the new editor doesn't treat everything as equivalent. This results in issues with where the insertion point moves during editing, what is selected, what gets cut or pasted, etc. Treating everything special (i.e. macros, images, links - things with parameters and/or bodies) as a framed object allows everything to be treated as an object, just like a character of text. Providing the frame also now allows you to explicitly see what is inside and outside a special object and allows you to select the object. For example, there is currently no way to select a link. You can select text that is linked, you can select an image that is linked, but you can't select a link. Raised in CONF-24026.

Display the associated parameters of the object (macro, image, link, etc) as text in the header of the objects frame.

With macros and special objects now having a frame, the hidden parameters of a macro/special object can now be displayed. Entering edit mode should expose all of the hidden information that is not visible when the page is rendered. Currently entering edit mode results in still having to enter a deeper edit mode (i.e. the macro browser or the special popups) to see the true values to edit. An edit mode within an edit mode is a huge productive hit. Simply seeing how a page was created is not currently possible while in edit mode.

A guiding rule should be "While in edit mode the user will be able to inspect the page and see all the properties effecting how the page renders without needing to do any further activities." If this rule was true a majority of the productivity hit of the new editor would be resolved. To do this requires displaying the parameters of macros and special objects in their frame. Raised in CONF-24026.

Allow the parameters in the frame to be edited as name value pairs and re-interpreted when focus leaves the frame.

The final hit to productivity of the new editor is the need to enter a sub-edit mode (the macro editor or the special popups) when making a change to a parameter that is already applied to a macro or a link/image. Allowing the name value parameter pairs in the frame to be edited would allow rapid changes to be made with a few keystrokes with no loss of user focus caused by having to visit a dialog.

Allowing new parameters to be added into the frame by just typing, for example "width" which is an obvious and easily remembered parameter on many macros, would allow common edits to occur quickly. Parameters that could not be parsed after the edit completes (i.e. after focus leaves the frame) could be handled by highlighting or in a similar way to how firebugs lets users change the parameters in the html editor window. Raised in CONF-24026.

The confluence editor should behave very similar to every other commonly used editor. At a high level, today's user's expectations of how an editor reacts is common across all editors. If the editor doesn't behave as commonly expected then the user's experience is compromised (some would say the editor is broken or unusable). I see these expectations as (please comment - do others agree?):

• 1. The focus of all activity occurs at the insertion point or selection.
  2. Pressing backspace or delete, removes what is to the left/right of the insertion point or removes what is selected.
  3. Typing or pasting inserts the contents at the insertion point or replaces the selection and leaves the insertion point after what is selected.
  4. Moving left, right, up, down with the arrow keys or page up/down in a document, if the same key presses are reversed, should place the cursor back in exactly the same location as it was before the first key press.
  5. Holding the shift key while moving left, right, up, down should extend (or start a selection from the insertion point). Pressing the opposite key should reduce the selection.

In general, the new editor doesn't respects these user expectations. This makes it slow, hard to use, and I would argue filled with special situations that while can each be individually explained as correct - as a whole make it wrong. An editor should be a simple experience - not complex.

Specifically with respect to what should happen when the insertion point is at the beginning of a macro, i.e. just inside the body. I would suggest:

• Pressing the backspace key should do something, currently it does nothing when just within the body.
• Pressing the left arrow moves to the outside of the macro (CORRECT), but starting at the same spot and pressing the left arrow, while holding the shift key, doesn't appear to do anything.
  • Unfortunately, it is more complex (in Firefox at least) continuing to press the left arrow while holding shift results in first the insertion point disappearing, with nothing selected, then nothing on the next key press. After some number of key presses the insertion point reappears with no selection. Reversing, i.e. pressing the right arrow with shift held, results in the insertion point appearing, then a selection appearing, then an insertion point, etc. Nothing is obvious as you attempt to select across a macro.