This issue was created to collect feedback related to the Content Editor and its initial implementation in the Wiki. We have gathered the feedback we needed to mature the editor so we'll be closing this issue. If you have additional feedback, please create a new issue and label it with ~"group::editor" and Content Editor
GitLab %14.0 includes the first publicly-available implementation of the new Content Editor, a WYSIWYG editing experience for Markdown. Our first goal is to make the Content Editor the default Markdown editor for the GitLab Wiki, with full support for GitLab Flavored Markdown extensions.
Currently, we have support many of the basic Markdown content types like
Headers
Bold and italic text
Inline code and code blocks
Blockquotes
Links
In the coming milestones, we're excited to continue working on more complex content types like Images and Tables.
Direction
The Content Editor was architected as a reusable and extensible component, meant to be consumed by more than just the Wiki. Behind the scenes, the editor reads and writes Markdown. This is an important distinction because it would have been easier to read Markdown and write out a proprietary format. We feel this prohibits collaboration on content from those who don't wish to use the Content Editor and prefer to edit content in the repository directly. If you like writing Markdown in vim, we don't want to stop you.
As we complete support for GitLab Flavored Markdown, we'll be looking to spread the Content Editor around GitLab wherever Markdown content is edited. Our second target is likely going to be issue and epic descriptions, something we're very excited to work on!
Hi! I'm the Product Manager for the Editor group and I want to thank you for your interest in the Content Editor.
FYI I'll be out of the office leading up to the 14.0 release so if you stumbled in here early because you found the editor early, I'll respond to all your feedback when I'm back on 2021-06-21
I've tried the editor on gitlab.com (the beta one) today. It is really nice to use and is a huge benefit for users who don't like markdown (I personally write most of my stuff in markdown 😄 ).
What I miss is the shortcut for inserting a hyperlink. Most application using CTRL + K (I guess MacOS has CMD + K) including GitLab itself (in the markdown view). The workflow through the link button and the inline textfield/apply-button feels not very straight forward for non markdown users (I assume people who are using Word or Google Docs).
Also I'm not sure how I can insert images. When I drag an image into the browser (in my case Brave) the whole image will be opened instead of importing it (in the markdown version it would insert the link). I'm not sure where I can add an image (there is no button in the toolbar) or if this is a missing feature right now.
Issue: After inserting a code block at the end of the content, there is no way to continue the content with regular text, i.e., to get the cursor out of the code block.
I also had this happen. I was able to work around it by entering a space after the location I intended to place the code block and was then able to move the cursor past.
I created #334190 (closed) to address the code block behavior. It turns out that the official way to do this is to use Cmd/Ctrl + Return to exit the code block. But please don't do this because there is a conflicting shortcut and that will actually submit the form on the page. I have this open bug to address that behavior as well #334191 (closed).
I agree, and we've been exploring some concepts for increasing the usable space of the editor in this issue: #328750 (closed). And we also feel pretty strongly that the future of the editing UI will be more of a block-based, contextual menu experience (similar to what you'd find in Notion or Medium) to specifically address the toolbar shortcomings. We're planning that out still, but it'll be tracked here: &5915
I have an issue with the [[_TOC_]] feature described here.
The visual editor (unexpectedly) allows editing of the TOC, which on saving becomes "hardcoded" (the [[_TOC_]] macro is replaced by literal/hardcoded markdown).
Perhaps the visual editor should treat these macros specially?
The [[_TOC_]] shortcut is part of our custom extensions to Markdown and something we are tracking in this epic: &5438. We plan to support this, all GitLab Flavored Markdown extensions, and some really exciting custom content nodes in the future!
Even worse: even if I don't edit the TOC, the [[_TOC_]] is replaced by the corresponding text (with links, etc.) and hence becomes obsolete at once when the headings are changed.
So I cannot use the content editor on pages that have [[_TOC_]] (or then I always have to re-edit it in Markdown, delete the corresponding, long text and add back the [[_TOC_]]).
@userq I'm not sure I see what you're experiencing, but it's possible you're using a version before we shipped support for the [[_TOC_]] macro. We shipped this issue in 14.4 that should fix the behavior for pages that include a Table of Contents.
Here's what I see when I edit a page that includes a ToC:
In later iterations, we'll work on making this more interactive and update as you type, but for now it should not require any re-editing.
Thanks, you are right. Now we finally got an update (to 14.7.2) and the [[TOC]] problem disappeared.
The "```" becomes "```plaintext" problem remains, but it is not that important. (So "```" becomes "```plaintext" when you use the "Edit rich text", but TOC:s are not changed anymore, so I'm quite happy.)
A quick follow-up, I found our list of supported browsers right after creating the issue. Since Waterfox isn't on our list of supported browsers, we're not likely to pick this up any time soon but it would make a great community contribution so I'll leave the issue open.
If the bug affects other browsers we can revisit. But please feel free to add any specific browser details, error messages, or other information in the linked issue @c33s. Thanks again!
I prefer using the old editor. Two killer features for me (compared to GitHub Wikis) are
the ability to drag and drop images and
the ability to copy paste tables from LibreOffice and get automatic md formatting 😎
Something I miss is:
some syntax coloring in the (old) editor (if possible) and
automatic list continuation, i.e. pressing Enter should generate another list entry in the new line (indentation and tick box as neccessary). This works in GitHub issues editor (but not in their Wikis editor).
We'll continue to iterate on the experience of those content types in later milestones as well, including adding custom UI for editing images and table structure.
some syntax coloring in the (old) editor (if possible)
I think what you're saying is you like the syntax highlighting in the new editor when viewing code blocks. We can do a lot more with this new editor in that area for sure. Your feedback actually had me thinking more and I just created #334198 (closed) to start the conversation about theming the editor. We'll keep it on our radar as we refine the UI and introduce the Content Editor elsewhere in GitLab.
automatic list continuation
Agreed, this is super nice. I like this about the new editor but it could be useful in other contexts. I could see this being added to our Source Editor (the counterpart to the Content Editor, for editing source code). I created #334200 to explore this. That said, the "classic" Wiki editor isn't using Source Editor either, so it wouldn't likely inherit this functionality.
Sadly, the shortcut crtl+enter for saving the document DOES save the document but not the one from the new editor but the underlying plaintext document which does not contain any changes from the editor. Thus all changes are lost :(
Wow, you're right @julianseeger. I just created #334191 (closed) to investigate but we'll get that resolved as soon as possible. Thanks for the report!
Hi @Matthias.Lensing, thanks for giving the new editor a try and for the kind words!
Split-Screen (Markdown and Preview) or toogle-function
We've started thinking about that in this issue: #328764 (closed). The idea is that for the vast majority of users, writing in the new editor will be preferred. But a way to switch over and view the source would be helpful in some cases.
Scrollbars or that toolbar always on top
I mentioned this in another thread above, but the UI for the editor is something we intend to iterate on in the coming milestones. We're hoping a full-screen experience will be easier to use and moving toward a block-style editor (similar to what you'd see in Medium or Notion) will bring the controls closer to your cursor.
Paste image from clipboard
Yes! We're working on inserting images in %14.1 and I'll be sure to capture that they should be able to be pasted from the clipboard.
Hello, there are two things i should love see in next updates :
Floating customization bar/menu
Code bloc rendering when reading the page
1 ->
When i write long texts, its annoying to scroll up, click on "bold" scroll down, looking if it works and etc...
2 ->
New editor code block rendering is pretty nice :
But its ugly when reading afterward :
And of course, thanks you a lot for you lovely work !
Yes, I agree, this is something we're working toward. Similar to what you'd see in Medium or Notion, we want to bring the content "node" selection closer to your cursor. We're starting the conversation in this issue, so follow along and feel free to add additional feedback or use cases as you see fit.
2. Code bloc rendering when reading the page
Good catch. The issue here is that we're rendering the page differently for the read and edit modes of the page. Consistency is important and we'll work on making sure the experience is delightful in both modes!
I agree 100%, we're hoping to make that editor a lot bigger in the near future. A fixed toolbar will help, but we're also exploring ways to bring the formatting options closer to your cursor by introducing a block-style editing experience.
Resizing images is interesting and definitely something we should explore further. I just created &6231 to start exploring specific implementations. Feel free to expand on your use cases over there or just follow along as we refine the epic and issues!
@sbondorf You're right, checkboxes are part of the GitLab Flavored Markdown extensions and we're still working on supporting those custom content types. Right now we've nearly reached full support for the basic Markdown content and we're tracking progress toward full GFM support in this epic: &5438
Please do not take away the plain text editing mode.
Rich editing is nice to do quick edits and see the result, but not really to write big documents. Markdown is really simple markup that is not that hard to enter by hand, unlike many other markups, like the one in Confluence for example.
Seconded.
I can see why people want to use the wysiwyg editor, but basicall every developer I know really disliked Confluence taking away the plain text view. If you know markdown it's a lot easier to just type and at the end check to see how it's rendered.
Without a plain text view, frankly I'd rather use the old editor.
Thanks @andreyorst and @cFranke_dpa for adding your perspective. I'm curious, when you think about writing in Markdown versus a WYSIWYG editor, is it the actual typing of the syntax that you want to preserve, or do you actually want to see the markup (for example, ### or __x__?
We don't want to force anyone to move away from Markdown. In fact, it's been one of our top priorities to maintain the connection to Markdown at the source. It would have been a lot easier to create a new, proprietary file format and build an editor on top of that.
The reason for my question is that right now you can continue typing Markdown as you are used to in the editor. Similar to some more modern editors, the formatting is applied as you type. So typing ## Header will render an appropriately styled <h2> in the editor. So, if you're used to writing Markdown, you can hopefully continue to do so.
But if your preference is to actually see plain text with markup inline, you'll want to keep an eye on this epic. It's early, but we plan to offer the ability to toggle between the WYSIWYG view and a "source" view in the editor for this exact purpose. Please feel free to add additional perspective or support in there!
I'm curious, when you think about writing in Markdown versus a WYSIWYG editor, is it the actual typing of the syntax that you want to preserve, or do you actually want to see the markup (for example, ### or __x__?
I was talking about plain text editing mode, e.g. no highlighting, no markup, all manual input. In Jira there's "Text" and "Visual" modes (IIRC), and I only use "Text", because it has no hidden semantics.
But if your preference is to actually see plain text with markup inline, you'll want to keep an eye on this epic. I
If this would be possible I'll be fine by that too. Seeing markup and being able to edit it freely without editor enforcing me and automatically escaping things in the background (as Reddit's Fancy Pants Editor does for instance) and immideatelly seeing the result is good.
@andreyorst It sounds like we're headed in the right direction then!
I'm glad you mention Reddit's Fancy Pants editor. I think the experience of toggling between a rich text editing environment and a "pure Markdown" mode is very similar. But in my experience (maybe I'm doing something wrong?) our Content Editor has one big advantage over the Fancy Pants editor. Specifically, I can type Markdown exactly how I'm used to writing it and the editor will render it in real-time. This kind of experience like you'd find in Notion or Typora is something the underlying editor (Tiptap) calls Markdown Shortcuts and will allow us to provide helpful UI when needed but not slow you down when you're typing something that is actually faster if you know Markdown.
The two best examples I can think of are headers and tables.
I, like you, know that typing ### will give me an h3 and that's really fast for me to type. I don't want to have to select a line, mouse over to a menu, select the appropriate header, then go back to typing.
However, I would be perfectly happy to never ever write another table in raw Markdown as long as I live. Here, I would appreciate a rich editing experience.
Hopefully with the Content Editor, we're able to deliver the best of both worlds. And if it's still not your cup of tea, we intend to let you switch over to editing raw, un-styled, plain Markdown.
I agree with @andreyorst and @cFranke_dpa here, we need to be able to edit, and view, our source as-is. I don't want to type Markdown and have it rendered in real-time, as I dislike hidden semantics as Andrey mentioned.
I'm curious, when you think about writing in Markdown versus a WYSIWYG editor, is it the actual typing of the syntax that you want to preserve, or do you actually want to see the markup (for example, ### or __x__?
It's more like: If I know Markdown, it's easier to just type it down as plain text.
When I'm writing down some documentation I'm focused on the content. Seeing a line I just typed being automatically rendered is irritating and takes the focus away from what I'm writing to how it looks. Basically I feel like I have to do two things simultaneously (writing and formatting) and I find it a lot easier to do them one after the other.
But if your preference is to actually see plain text with markup inline, you'll want to keep an eye on this epic.
Oh that looks good. That should be a good solution.
However, I would be perfectly happy to never ever write another table in raw Markdown as long as I live. Here, I would appreciate a rich editing experience.
Just to be clear. I'm not against a wysiwyg editor. And as a wysiwyg editor I like what I saw. I'd only suggest keeping a plain text (or source code) view as an option.
Seeing a line I just typed being automatically rendered is irritating and takes the focus away from what I'm writing to how it looks
This is super important and I hear where you're coming from. Making sure you still have access to the raw source is very important to us!
Oh that looks good. That should be a good solution.
Great to hear!
Just to be clear. I'm not against a wysiwyg editor.
Understood, I didn't take it that way personally. But I hear what you're saying about wanting an option to see the raw source. Thanks for the perspective here!
Just to be clear @ericschurter, the "option to see the raw source" is essentially the original editor right? I.e. not just see the raw source, but edit it as well? It wouldn't make sense to have to switch from the new editor where we can edit, to a source viewer which is read-only.
I came here to tell that I also like seeing Markdown while typing. The web software Discourse has a side by side view (left side writing, right side rendered preview).
I prefer this kind of compromise, because I can type fluently and immediately see the result.
@pommes We appreciate that feedback and we'll keep it in mind as an option for the Wiki, but I want to call your attention to a different issue where we're working on something similar: &4859. I think that experience that we're working on for editing Markdown in the Source Editor is more like what you're expecting.
@petar.tomov Thanks, I'm glad you like it! As I mentioned in the thread right above, we intend to provide a way to switch back and forth between the WYSIWYG editor and the raw source.
I took the time to write up a medium size guide as part of one of my project's documentation. I really liked the overall experience using this new editor. However, I noticed a few shortcomings to the new WYSIWYG editor experience. Here are my recommendations.
Add shortcuts to common formatting options (Ctrl + b for bold formatting and so on).
Once shortcuts are added to the editor, add the shortcuts in the toolbar icons' tooltips.
Keep the formatting toolbar always visible, so there would be no need to scroll all the way up in larger documents. This issue can be mitigated with the previous point on shortcuts.
When adding a link to a piece of text, the Link pop up appears, so I can paste something in there. When I hit "Enter" I expect the action to be fulfilled, but in turn, I think it tries to submit the change to the whole document.
When I'm writing a new line and finished the line with code-formatted text, I want to move out from the code format mode and hit the period key to end the sentence. Instead, I'm not able to exit the code formatted text and need to create a new line, add the period and then hit backspace several times to make it join with the previous line, which is quite inconvenient.
When pasting text copied from a preformatted context (such as source code from the GL code viewing page), it is placed correctly with code formatting. However, I expect to keep typing text in normal format, not code format.
When adding code blocks, let the writer choose which syntax highlighter to use.
Let code formatted text to be formatted with other styles as well, such as bold, italics or underlined.
These were points I noticed and remembered to write down for this feedback. So far, it's been a really good work!
Thanks @jzmz for giving it a shot on a real project! This is great feedback, I'll try to address it all:
🤔 I'm not sure what's going on here, I thought we had a shortcut for bold. There are some still to be implemented though. Visibility and discoverability of those shortcuts is definitely an area for improvement though.
Agreed, we want to make formatting and content insertion available no matter how long your page gets.
That's unexpected. We're looking into some issues related to conflicting keyboard shortcuts and form submission in 14.1. Hopefully we resolve this soon!
We're also looking into exiting code blocks in 14.1!
Interesting! Pasting options would help here, as I imagine different use cases have different expectations.
We were just discussing syntax highlighting options for the code blocks. Follow along in this issue: #334576 (closed)
🤔 We'll look into that, thanks for the suggestion!
The new editor is a big improvement, however I would echo the comments I have read about being able to paste in images.
As well, it is annoying that the save button is fixed at the bottom of the page. I would like it much better if it would float with the view and always be available without having to scroll to the bottom.
That's very concerning @neosoft-fvildoso, I'm sorry to hear that. Can you share any information about your setup like your browser and OS so we can try and isolate the issue?
And also it's very convenient to copy/paste the code when creating a new wiki page.
This is a very interesting use case, thanks for bringing that up @berliozdavid
Rest assured, we don't intend to remove the ability to view or edit the raw source.
Thanks for voicing your support for partial editing too. We'll keep that in mind as we work on the UX of the editing experience, especially for long pages.
Right now however you can't enter content in WYSIWYG and then switch over to see the code (because you need to switch to the old editor to see that) - it tells you all edits will be lost. Could a way to view the code be added?
Thanks for the feedback @darrensapalo, these are both helpful UX improvements. I think part of it will be improved as we move away from a toolbar-centric layout and bring the controls for formatting block-level elements (like headers, quotes, lists, etc) into the content body. We casually refer to this as "block" style editing but if you've used Notion or Medium, that's fairly similar.
I just created #335573 (closed) to investigate how we can improve the shortcuts for formatting selected text, specifically the code format.
@joel.j.k.parker Thanks for taking the time to provide the feedback!
#334191 (closed) was just merged a couple days ago and is live on production. If you're on self-managed, it will be available in %14.1
I created #335552 (closed) to track the work for full-screen editing. I agree, this is a great feature and we'd definitely want to have it in the new editor!
I have to admit I didn't test the new editor for long. The reason is that a great lot of my wiki pages have complex tables. By that I mean tables with collapsing rows and/or columns and cells with block elements inside. That's why these pages contain a lot of HTML code and at current state the WYSIWYG editor isn't able to process them.
If one day the editor can process those things I probably would make extensive use of it 😁
on-the-fly input parsing
Personally I'm not a big fan of parsing input on the fly. Let's say I want to change the semantic structure of a document and to do so I want to change the headings. In plan text I can cahnge all headings quite fast by adding/removing #.
There seems to be no easy way to do the same in WYSIWYG editor mode.
Examples of where I like automatic input parsing:
emoticons/icons (i.e. ⚠ and ℹ)
all kind of enumerations
simple text formating (italic, bold, underline) as long as I can change the formats scope easily
labels
Preview
Someone above wrote he doesn't trust WYSIWYG editor output to be correct and valid. I have the same feeling - but maybe the likes of us have been disappointed too often by a lot of WYSIWYG editors in the past.
Anyways I'd like it better to have some sort of at-the-same-time preview of what I am writing in markdown.
The preview option we have is fine and nice but writing would be even faster and more productive if I wouldn't have to close the editor to see the preview.
When I write my documentations in vscode to push them to the wiki repo afterwards I use vscode extensions that make use of this approach a lot.
I see the new WYSIWYG editor as a minimal viable product step to something that's gonna be really cool. But maybe there is a chance to keep the "old" content editor and improve it further, too.
@jochen.sauer83 Thanks for providing the feedback, we appreciate you giving it a shot. I saw your comment on our issue related to tables and just for the sake of documenting things on this thread, here's the issue we created to implement support for more complex tables that use block level elements in the cells: #335844 (closed)
There seems to be no easy way to do the same in WYSIWYG editor mode.
Currently, you're absolutely right. We'll be iterating on this and we have some ideas for how to make it easier to adjust block-level attributes like changing the header level.
But maybe there is a chance to keep the "old" content editor and improve it further, too
Agreed, and we plan to do so by eventually using the same code editor as you use to edit files in the repository or create a Snippet.
Love the decision to move to a WYSIWYG Markdown editor!
I'd like to echo and emphasize some things others have said, but perhaps not in the same way:
As it currently is in the latest build, the editor makes it much more difficult to actually use Markdown because to do so you need to use the toolbar (or know some shortcut), but the toolbar requires scrolling the whole page back up to the top, and this is only practical on tiny documents, and not all actions have shortcuts associated with them. It would be great if the toolbar remained fixed either to the bottom (preferably) or the top of the screen, easily accessible both on desktop and mobile.
Agree with others on the usefulness to be able to switch back and forth between the new editor and plaintext. Sometimes we just prefer the simplicity of plaintext, and want an intimate connection with the actual document that is being created. The only way to get that is plaintext and therefore it should really remain trivial to switch back and forth between the two. In an ideal world, this would be similar to how this comment box works, with its "Write" and "Preview" options, except it would be "Plaintext" and "WYSIWYG", or maybe "Plaintext" and "Render".
please give the nagscreen a proper id so it is blockable. i don't want to block all alerts as alerts can be quite important but i keep dismissing this dialog just to see it again and again. "try it later" should not mean "you see it after your next refresh. as i use waterfox i simply cannot test/use it.
@mle for the waterfox classic issue, there is already a separate issue for that: #334195 (closed)
i gave the editor a try today with chromium, the first thing is miss is the raw source editor. the whole reason for me to use markdown is to edit styled text in plain text. so give me a <textarea>, a submit button and the shift + enter shortcut to submit and i am really happy.
currently the new editor takes away this lightweight option, has no fallback for non-standard (chrome) browser (even a textarea would be enough), has a nagscreen which i cannot dismiss, has a quite strange styling (too loose, why the ul items have to be so stretched?), needs webcomponents to run and has no raw source edit mode. for me this is a big regression.
my biggest fear, after you make this editor the default editor and removed the "old" one, is that you also introduce this editor for the issues and that you also have no good fallback for non-chrome browsers and no setting to start always start in plain text mode.
please also look at your "power"-user / markdown-aware-user and let plain text markdown and also non-chrome browser be a first level citizen in gitlab (yes i know there is firefox and safari, with non-chrome i mean also other browsers like waterfox and palemoon, but currently i even have problems with the latest firefox and gitlab).
@c33s Thanks for explaining the importance of having an easy Markdown input. This is something we will be looking at in future iterations #328764 (closed).
I have raised a separate issue to address the problem with the extra spacing #335970 (closed)
@mle will the old editor be available until you address the issues (raw edit, browser compat, fallback, setting to auto start in raw source mode. or at least an option to do it ourself by using greasemonkey)?
One specific question for you @c33s, does the Snippet editor or the Web IDE work for you in Waterfox? We intend to use the same underlying code editing component from those features to power the "raw source" editing mode.
my biggest fear, after you make this editor the default editor and removed the "old" one, is that you also introduce this editor for the issues and that you also have no good fallback for non-chrome browsers and no setting to start always start in plain text mode.
Thanks @mle for adding some details and just to reiterate here, our hope is absolutely that this new WYSIWYG editing experience can be made available in issues, or wherever Markdown is written. Your input @c33s is valuable and highlights something that has been a core tenant on our team: We don't want to alienate those who prefer to write in Markdown but we want to enable those who don't to contribute efficiently and effectively.
We're very familiar with the challenges we've seen others face in this area, including Slack, and hope to learn from them!
but if i add a file via "add another file" it works. so the workflow is: add a 2nd file, delete the first and then click on the line number to allow editing (if i dont click on the line number i simple cannot focus on the edit area. just clicking in the edit area doesn't work.
webide
works quite ok. also cannot focus empty lines via mouse, have to click on full lines or on the line number. focusing with the cursor keys is no problem
gitlab ci lint
same problem as with the snippets but there i cannot simple trigger a "rebuild" via delete and add.
btw this issue is slowly getting too long for waterfox. since webcomponents getting more and more required for gitlab i cannot open issues with a lot of comments. loading time is getting longer and longer the for each comment added until i simply cannot open the issue any more (timeout). not 100% sure if waterfox would handle it better on a good network but i have constant drops. it looks like async js doesn't work well with drops.
We intend to use the same underlying code editing component from those features to power the "raw source" editing mode.
your really kill an awesome UX for poweruser with that. gitlab ci lint, snippets, webide - yes they partly work. lint not at all, snippets with workarounds and webide quite ok.
the current editor works. it work on quite all browsers. shift + enter for submitting works, autocomplete for @, slashcommands, ... simply work.
i really fear that you destroy this UX/DX with "we need a WYSIWYG editor". please keep and them both. a textarea only fallback in the issue would really destroy my gitlab experience. i am really a poweruser of the slashcommands. for the wiki, well i can clone the wiki repo and work in my IDE of the DX with the new editor is not awesome (and a mean awesome. not good or ok. becuse currently the DX is awesome). i can simply not use the gitlab ci linter and fix the gitlab-ci.yml file locally and push it again to let it lint in the pipeline. also i simply can skip using the snippets (what i have done since the "enhancements" which broke them for me) but i really can't work with a broken issue editor.
After creating my first page, i cannot edit it anymore, it keeps showing this msg after any new edit and save:
"Someone edited the page the same time you did. Please check out the page and make sure your changes will not unintentionally remove theirs."
I'm positive i'm the only one working on my new page. We are just three people sharing the project...
Am I doing something wrong?
https://gitlab.com/mofuss/mofuss/-/wikis/home When I try to edit this page it will show the above error message and won't save any new edits, regardless of using or not the new editor. I might have my gitlab account open in other computers, but that shouldn't be an issue i presume.
Thanks a bunch for any tip, GitLab's Wiki looks exactly what i was looking for but can't make it work.
Adrian
You're right @mofuss that shouldn't be a problem. There may be something wrong here unrelated to the editor itself. I might not have sufficient permissions for the project you linked but when I tried to clone your wiki repository, it is empty. So it seems like you're stuck in a weird state that has a single page visible in the UI but it doesn't exist in the back end?
@fjsanpedro or @himkp are either of you aware of any way a wiki could have ended up in this state or a quick way to try and recover from it?
This message is shown when the update operation SHA is different from the page last SHA which, in other scenarios, means that somebody or the user updated the page after another operation.
@mofuss if you can, add me as a developer to your project and I'll try to debug the problem.
@mofuss I think it's already solved. For some reason, the HEAD of your repository didn't match the branch you were making the commits to. Therefore, when we tried to retrieve the commits for the specific branch we couldn't because it was pointing to the wrong branch.
Many many thanks Francisco @fjsanpedro, and sorry for the slow response, i took my kids to the countryside for a couple of days. Mandame tu dirección postal y te envío unos cavas! Gracias otra vez.
Markdown is code oriented by essence. And with code, editing is not really bidirectional. I don't really want to edit the result, I want to see the result at some point. But I want to edit the code. The goal is not (only) to see a result but to maintain a well formatted code.
So in a code first approach, maybe a markdown editor should focus on syntax highlight and assist.
So in a code first approach, maybe a markdown editor should focus on syntax highlight and assist.
I think that's the distinction here. We're not saying that this editor is code first by any means but we are hopeful that our approach to respecting and maintaining the source code (regardless of the syntax, it could be AsciiDoc or RDoc in the future too) as the single source of truth will be what enables teams to collaborate efficiently no matter what their preferred editing experience may be.
Where others have introduced rich editing experiences that go from Markdown -> HTML -> [proprietary format] -> database] we hope that the Markdown <-> HTML round trip with this editor will actually aide others in maintaining well-formatted code. As mentioned in the threads above, we intend to provide a path to editing the raw source, so if that's where you're comfortable then hopefully you'll remain happy. But, the idea that we can expand our audience to include those who don't feel comfortable working code-first while maintaining a git-friendly, versioned, code-first data source... that's where we see the potential here and that's where we can drive more efficient and meaningful collaboration within GitLab.
Thanks for giving it a shot @kareemzok! I'm glad you found it helpful and stable. Keep an eye out for rapid growth here, we have a lot of features coming in the next few months!
Noticed a possible bug when rendering references of the [^1] sort:
Notice that the 1 isn't rendered as a superscript when it should be.
I also ran into some issues when trying to create that reference. It would be escaped in the plaintext (e.g. \[^1\]). So I had to create it using plaintext to get it to work.
@kareemzok Great question! We just added this last week, but now you can insert an image from the toolbar. You can also drag an image into the editor frame. This is available now on GitLab.com and will be part of the 14.1 release for self-managed installations.
Thanks for reporting this @seb.poplidays, I went ahead and created a new issue: #336458. Feel free to add any more details there or follow along for updates.
Thanks @jacsonpaz1, if I understand you correctly this is a request based on the differences currently with rendering in the edit view and the final output to the wiki? If that's the case, our goal is to ensure 100% consistency between the edit view and output so that we don't have to have a separate preview workflow while you're editing. We're tracking a few specific instances of discrepancy, like code blocks and line spacing for list items, but if you have any other cases where rendering is off please let us know.
Great news to everyone following along in this issue!
Available now on GitLab.com and coming in 14.1 for self-managed instances, we have added two of the most commonly-requested features in this feedback issue!
Insert images
Now you can add an image by URL, upload an image directly from the editor, drag an image into the editor, or paste an image from your clipboard!
Insert and edit tables
Working with tables in code can be rough! Now you can create a new table of any size using the toolbar UI and edit the content in existing tables. Our next goal is to bring you custom UI controls for adding or removing columns and rows and using block-type content (like lists, checkboxes, or even other tables!) in a table cell.
If I want my wiki page to display something like <foo> (a word enclosed between < and > characters), and I simply type in <foo> to the WYSIWYG editor, then nothing is displayed on the resulting wiki page.
Now when entering markdown directly (such as when posting this comment), I am aware the < and > characters need escaping and am happy to use escape characters, but I would expect a WYSIWIG editor to supply the escape characters for me (after all, the whole point of using it is to save me the need to write markdown).
@nigeldeakin Thank you for that feedback. That's a good observation.
In the Markdown editor, we would allow for as itself because we allow some HTML markup to be inserted directly in the editor. With the WYSIWYG (aka content editor), I can see the case that should be recognized as inline code and if someone wanted to insert HTML markup then we should treat it like a block element where you actively decide to "insert a code block" or "insert HTML code".
Thanks we will take this feedback onboard as we iterate on this experience.
@nigeldeakin We appreciate you pointing this out, it's a use case we hadn't noticed yet. I imagine it's something we need to solve for as part of broader support for inline HTML, which we're tracking here: &5869
I just tested and confirmed the behavior, so I'll create a separate issue specifically for writing prose that looks like code.
This is unexpected, thanks for pointing that out @davidCarlos. I was hoping our paste rules would kick in but I'll create an issue specifically to track this workflow.
I should clarify, it's not meeting your expectations for how pasting content is handled. We have to send the pasted content through our Markdown parsing API and display the result. But it's a known limitation, not a bug.
+1 for toggling WYSIWYG vs SOURCE editor. Even better would be to include keyboard shortcut (e.g. ⌘+/ in Typora) to toggle between editors. In WYSIWYG markdown editors like Typora, the formatting just doesn't look right and editing the source is the easiest approach to fixing it.
@ericschurter@ealcantara There is a shortcut currently in GitLab that is established for toggling between WYSIWYG and SOURCE, ⌘+Shift+p or Ctrl+Shift+p. We should have this as the shortcut key once we have both views in the content editor.
Something that could help people writing long documentation a lot: making the toolbar sticky when scrolling.
It's painful having to scroll back up when needing to use it.
HI @lifistic_cedric thanks for the kind words! I agree, there's an opportunity to persist the formatting options on longer documents. We hope to address this in the near future.
Thanks @a7l97nn I'm glad you're excited to see the new editor. You're not missing anything, we just haven't implemented those custom controls yet. We'll be working on those in a later iteration. #328759 (closed) is where we're tracking that work.
How can I turn off the nag dialog for the new editor? I looked at it, but as a longtime markup user I am much happier using text markup. However, it seems like almost every time I edit a new issue, I have to dismiss the nag dialog telling me about the new editor (or I get less screen real estate to edit in).
New editor is an improvement. It would be helpful if the content scrolled within the editor box so that you can use the editing tools no matter where you are on the content OR if the tool bar were sticky. For example, if you are at the bottom of your content doc, in order to link some text you will need to scroll back up to the top to click the link button.
Thanks @emmaearl for the feedback and we hear you on that. We're working on some updates to the Wiki edit view that might address that issue. We'd love your feedback on the issue if you have time: ux-research#1505 (closed)
New editor is cool. However, it destroys some of our custom editing when using.
For example, tables and the table of contents are negatively impacted (altered without our making edits to them). It's very difficult to move between the old editor and the new as well.
Hi @livinabsurdism! Thanks for giving it a try! You're right, working back and forth between the classic editor and the new one isn't seamless... yet. It's our goal and one of our immediate focuses to ensure that data isn't corrupted or lost when switching between the two. You should see more stability here over the next couple releases, so keep checking back in!
Cool! But in my case, I had issues with line breaks
This is the source:
# Stability of Files for Release 1| Symbol | Meaning ||--------|---------|| **-** | the file/directory is not relevant for the first release || :sunny: | the contents of the file/directory are ready to be stabilized || :partly_sunny: | the contents of the file/directory are close to be ready || :cloud_lightning: | the contents of the file/directory are under construction || :wastebasket: | the file is obsolete and can be deleted || | none of the above | # Files in `src/`| Directory/File | Stability ||------------------------------------|----------------||`src/`| ||`├── boundaryconditions`|:sunny: ||`├── CMakeLists.txt`| ||`├── common`|:partly_sunny: ||`│ ├── array_ext.h`|:sunny: ||`│ ├── CMakeLists.txt`|:sunny: ||`│ ├── definitions.h`|:partly_sunny: ||`│ ├── Euclidean.h`|:partly_sunny: ||`│ ├── fileUtilities.h`| :wastebasket: ||`│ ├── interpolators.h`|:sunny: ||`│ ├── mpiutilities.h`|:sunny: |
We're tracking improvements to the code blocks in a couple places (&6246 and #338079 (closed)) but I'll specifically capture the line wrap functionality. That's a great suggestion!
I like the new editor. I'm not sure how to switch back and forth between markdown source code view. Sometimes it is nice to be able to directly edit the markdown and then switch back to the WYSIWYG editor
Our vision is to have the content editor be almost everyone's favorite way to edit, but we want to make sure that if you want to write raw, unstyled Markdown, there's a way. We'll be working on that in the near future.
I also wish I didn't have to scroll all the way to the top of the editor window to access the buttons. It makes it difficult to use the buttons with wiki articles that stretch beyond one screen.
@joe.jasinski1 That's also great feedback and validation of others' input as well. ux-research#1505 (closed) is an issue where we've been exploring some larger changes to the Wiki edit view that will address this. We'd love to get your input in that issue!
Possibility to insert "Copy to clipboard"-button for code/quote segments would be sweet.
Tab would IMO be better suited if it created an indention instead of skipping to next page element.
Selection of multiple lines/text passages using CTRL + highlighting would eliminate need to repeatedly scroll up and down to
un-/select "Insert code" button. Consequently, editor toolbar should follow when scrolling.
We've got an issue for copying code blocks here: #330627 (closed) but I love the idea of extending that to block quotes!
I agree, keyboard navigation could improve a lot by making that one change and the selection of multiple elements is something we're definitely planning to work on further.
I'm happy to see the intent to accommodate both people who prefer a WYSIWYG editor and people who prefer entering raw Markdown text. My team consists of both, so lossless roundtripping is important to us.
For example, if I edit and save a wiki page with a Markdown list using syntax <space><space><space><hyphen>, then I edit and save using the new Content Editor (without making any changes), currently it rewrites it as <asterisk>:
I'd love to see the Content Editor preserve as much of the underlying Markdown formatting as possible — both to minimize the diffs (to make it easier to find the actual content changes when browsing wiki revisions), and to minimize the disruption to people who still want to edit raw Markdown text.
We're working on this. But it is somewhat of a hard problem to solve. There's only so much you can do with source maps right now. As an initial prototype, we added support for preserving list style types in the editor. That still won't preserve the spaces before lists though. In general, preserving whitespace is a hard.
We're having conversations about improving our markdown rendering pipeline to have better support for sourcemaps in rendered markdown though, so that we can preserve a lot more than just list style types. Specifically things like distinguishing inline links with reference style links.
@himkp if preserving whitespaces, formating, intending, ... is so hard, please don't forget to provide us with a full plain-text/only-markdown/not-wysiwyg expierience as main-citizen in your new editor.
i really don't want to ruin my commit history in the wiki just because "preserving structure is hard" (of course i know it is hard, i code by myself).
as a markdown only guy i really fear that i loose the awesome developer experience with the new editor.
the main features i fear to loose/not have:
settings for disabling the wysiwyg editor and fully stick with the source editor
still a preview option (which does not ruin the formating/whitespaces)
compat with non-main browser (as palemoon and waterfox classic)
@c33s The last thing we want to do is ruin your commit history! As @himkp mentioned, the challenge is providing tools to foster more collaboration while not alienating those who are working perfectly fine in the current environment. To that end, I hope these feedback threads have made it clear that the new editor may someday become the default, but it will never be the only option (at least as long as I have a say! 😄 )
To address your main concerns directly:
settings for disabling the wysiwyg editor and fully stick with the source editor
Once we move the new editor out of "beta" this will absolutely be something we implement. If you prefer to use a raw source editor, that will be something you can set as the default.
still a preview option (which does not ruin the formating/whitespaces)
This is a good point. We'll keep this use case in mind as we architect the source editing aspect, but I don't see any reason to prohibit this.
compat with non-main browser (as palemoon and waterfox classic)
I'm not sure if this is a feature request or if you mean the wiki-specific Markdown extensions like those used to create links or new pages. If it's the latter, then we fully intend to support that in both editing environments. If it's a feature request, then it sounds like this is the epic you'd want to follow: &70 (closed)
ctrl + enter for submitting a comment
I don't see any reason to change this pattern, I agree with you here.
keep the format as-is
It's good to know how much you enjoy the current format. We understand how disruptive change can be to a workflow and we're doing everything we can to balance that with progressing the user experience so everyone can contribute.
If you prefer to use a raw source editor, that will be something you can set as the default.
will the raw source editor be the fallback editor? will the fallback editor be like the current editor (with preview, autocomplete, quickactions, ctrl + enter, ...)?
i really fear that this new editor will kill our workflow and cost a lot of time and effort to adapt (which means not working productive on software but only on browser-updates, greasemonkey scripts, workarounds, ...)
working autocompletion for quick actions
the comment was only about when this editor comes to issues
keep the format as-is
i mean stuff like indenting, whitespaces, change from * -> -, ... my point of view is that the format must not be changed. if changed the commit history will be broken.
thank your for answering all the questions and your work here. 👍
will the fallback editor be like the current editor (with preview, autocomplete, quickactions, ctrl + enter, ...)?
I don't know that for certain yet. I doubt it will actually be the same code but the functionality will be the same. I understand the reason for the question, in that your browser doesn't support the more feature-rich editors as well. We'll keep this in mind as we figure out a solution.
the comment was only about when this editor comes to issues
There's a little while before we tackle this so I don't have a definitive answer for this yet either. We'll work with the Plan team on this, likely at the beginning of next year.
i mean stuff like indenting, whitespaces, change from * -> -, ... my point of view is that the format must not be changed. if changed the commit history will be broken.
Ah, ok, thanks for clarifying. Yes. Actually we just had a wonderful discussion about this today and we are actively investigating ways to ensure only the edited content is changed (meaning no re-formatting of the entire page every time the WYSIWYG editor loads the data) and that user stylistic preferences (like using * instead of -) are preserved.
I hope I am not repeating something which already have been mentioned, a cool feature with this editor would be if the header would scroll with the page, so that it is always visible:
If that is not the case the usage is pretty limited when working on bigger markdown documents, because you would always need to scroll the page to access the icons for formatting
We appreciate the feedback @TanjaBayer! It has come up as feedback fairly regularly but that doesn't mean you shouldn't add your voice! We're exploring some changes to the layout of the Wiki edit page that would make the toolbar more persistent on the page. We'd love some feedback on this research issue if you have a chance: ux-research#1505 (closed)
(this is in response to a 2-month-old thread -- I did not read all two months, so my apologies in advance if this has already been discussed and the topic has been beaten to death)
The idea is that for the vast majority of users, writing in the new editor will be preferred. But a way to switch over and view the source would be helpful in some cases.
I want to respond to this idea (that the vast majority of users will prefer wysiwyg,) because over the past 30 years -- yes, I'm old :) -- I have seen a lot of great tools go down this path. They start out with a tool that is very "expert-friendly" and then somebody (usually a product manager -- they are never happy to leave well enough alone 🙂 ) decides that the tool is not easy enough to use, so they start tweaking the UI, removing infrequently-used keystroke shortcuts while adding buttons and GUI features, always trying to make things easier for the mythical wiki-editing grandmother to use, and before long they have dumbed things down to the point where they have alienated their core audience. If you know any die-hard VIM or Emacs users, try to imagine getting them to switch to Notepad for coding.
Right now, Gitlab's core audience is software developers. I understand you guys are trying to get more and more enterprisey, and trying to get your platform to be used by QA, and PM, and Support, and all the other departments in a company, and that's fine, but at its heart, Gitlab is still a tool ecosystem that primarily exists to support the software development process, and those developers are the people that generally drive the decision on source control tools, so I think it's important that you strike a balance where you enable new users to access your platform, while still supporting your power-users/champions. And power users only get to be power users when a platform is stable; when you change things out from under them, they get very cranky. You may only have one user in a thousand who writes a python script that runs on a weekly cron job to auto-generate some graph or table in markdown to create the new wiki page for his team, but the day you take away source view and break a tool that a person like that worked hard to create - one that had been working for that poor schmo flawlessly for years, you will have created a highly motivated Gitlab-basher.
usually a product manager -- they are never happy to leave well enough alone
That's actually a great way to describe my chosen profession @jvmatl! 😆 We're generally motivated by pushing the product further, making it more accessible to more people, and iteration. I understand the sentiment was a little bit of a friendly dig, but I'm going to embrace it!
That said, I'll cut right to the point and hopefully what you want to hear:
We have watched others tread this path. We have been frustrated by the same complexity you bring up. We love Markdown too! We will not be removing the ability to edit the raw source.
What we are doing is creating a first-class visual editor for Markdown content that enables those who don't consider themselves power users, who are flummoxed by the peculiar syntax requirements, or who simply prefer to see their changes styled in something other than a monospaced font to contribute to GitLab as efficiently as developers can today.
My (our) hope is that when the new editor has matured, we have a final product that is delightful enough to reach the point where the majority of our users prefer to use it over the raw source editor. That doesn't mean we'll stop working on or remove the ability to edit the raw source.
It's all words now and you don't know me well enough to take my word 😅 but I hope one architectural decision we've made so far that can point to as proof of our commitment to this principle... It would have been a lot easier to create a new, proprietary file format for files that use this new editor as other platforms have done. The translation from Markdown to HTML, then back to Markdown introduces a lot of complexity (see the threads right above this one for more detail). But that would have prevented collaboration from local environments and it would have meant you had to make a decision: Do I want to use the fancy new formatting tools, or do I want to keep the Markdown source? We strongly believe that you should not have to make that choice.
decides that the tool is not easy enough to use, so they start tweaking the UI, removing infrequently-used keystroke shortcuts while adding buttons and GUI features, always trying to make things easier for the mythical wiki-editing grandmother to use
Again, I acknowledge the tongue-in-cheek jab here, but the reality is that no one at GitLab is "deciding" that it's not easy enough to use and there's nothing about someone's age that prevents them from learning Markdown. We have real data, real people, even members of the GitLab team, who want to contribute to Wikis, issues, and other content within GitLab that can't because they find Markdown either too difficult or too inefficient. In order to live up to our motto, everyone can contribute we have to make this easier.
dumbed things down to the point where they have alienated their core audience
This is 💯 always, forever, in the back of my mind. It's my job to make sure this doesn't happen. I appreciate the reminder and I hope you keep me honest as we iterate on this new editor!
Tried out the new editor today for the first time on an existing page that featured a PlantUML diagram. The diagram rendered, but there was no obvious way to edit the content. I also intended to add a second diagram to the target page and was unable to manually get the code syntax format to pickup correctly, kept formatting as regular text. Since I've used several PlantUML diagrams in these pages, this new interface is currently not an option. Please maintain access to the legacy editor until more of the advanced formatting features can be used as expected.
I'm happy to hear the existing diagrams rendered correctly. You're right though, there's no way to add a new diagram in the new editor. Here's a placeholder issue that we intend to refine and implement soon that will allow for the editing of a PlantUML diagram in the new editor: #332096 (closed).
Please maintain access to the legacy editor until more of the advanced formatting features can be used as expected.
This is exactly our plan. We introduced the new WYSIWYG editor early so we could learn from the community and let those who don't have more complex pages take advantage of it as soon as possible. We fully understand though, that there are many features it doesn't support yet. That's why we made it an opt-in experience and it will stay that way until we reach parity with the classic editor.
Hi @jacopo_lenti, I'm not familiar with pedix but quick googling leads me to believe you're asking about superscript and subscript. If so, then it's on our roadmap but currently we don't have a shortcut for quickly creating superscript or subscript content.
We do have input rules for superscript and subscript, among other inline HTML tags. So you just need to enter your content in some HTML tags and it will work automatically. We still need to work on updating the documentation for the shortcuts and input rules, but here's a brief list of examples of supported HTML you can directly type in the content editor:
If the changes <abbr title="Looks good to merge">LGTM</abbr>, please <abbr title="Merge when pipeline succeeds">MWPS</abbr>.
Do not forget to buy <mark>milk</mark> today.
This is a paragraph and <small>smaller text goes here</small>.
Press <kbd>Ctrl</kbd> + <kbd>C</kbd> to copy text (Windows).
That's great feedback, thanks @sviatoplok. I'm curious about the use case and your preferred approach.
font-variant: small-caps; would be the "preferred" method in my approach but that's a CSS-based solution that we don't really support in an easy-to-use form today.
I could see us using <small> to indicate it directly in HTML but that's not semantically correct if I understand it's implementation correctly.
As there's no native support for small caps in Markdown, we'd need to land on a solution that requires as little markup as possible and renders consistently across browsers.
The use case is that we are publishing a hybrid text edition (for print and online publication) with xpath etc on GitHub and GitLab and use the GitLab wiki to make sure all editors use the same font styles when editing the text.
Problem is 1) that the style sheet requires small caps for displaying author names etc and 2) that editors are not using xml but are (so far still) working with Word processors.
That's why it would be very good to display the styles in the wiki correctly, including small caps.
However, it would suffice if the small caps were displayed in the wiki only, for our purposes.
@sviatoplok That's a really interesting use case, thanks for sharing more detail!
I don't see anything technically standing in our way for implementing smallcaps, but the underlying markup would be a little messy given the lack of support in Markdown and iffy support in HTML as well.
@mle Do we even have smallcaps as a style defined in our typescale? This is an interesting use case for the sort of advanced customization and flexible styling we've been talking about.
While this can be nice for simple text editing I find the wiki rarely needs simple text editing. I could see this being really useful in issues and could be a huge benifit to those of us trying to get buy-in on using the Gitlab issue queue from non-tech users.
This feature really falls flat in complicated usecases. Especially around the creating of checkbox lists. We often create checklists in our wiki to be used for later reference and so we have lots of extra information:
go and do this thing
/link/to/thing <= this will be copied and thus isn't a real link.
Then there would be a long paragraph that talks about how to do the thing listed above. there might be an image or other information too.
Other things that I would like to see I have already seen mentioned but thought I would +1 them; Preview Mode ++ and Plain Text Mode ++
I could see this being really useful in issues and could be a huge benefit to those of us trying to get buy-in on using the Gitlab issue queue from non-tech users
Yes, we're excited about this opportunity too. As soon as we can get it in issues, this is going to be a huge benefit for those unfamiliar with Markdown!
We often create checklists in our wiki to be used for later reference and so we have lots of extra information:
The good news is we're planning to address this as we iterate through supporting the entire GitLab Flavored Markdown spec. Checklists are one of the elements that is currently able to be rendered by the new editor (so existing pages with this content will display correctly) but we have not yet added the UI for inserting new checkbox lists.
Hopefully once we implement that you'll find the new editor more useful for your needs!
When typing links with the Markdown syntax, pasting the URL triggers "autolinking", so adding the closing parenthesis does not transform the whole string into a link.
Copy in editor, then Paste in Notepad: I expect to paste the Markdown text instead of cleaned text.
I created an issue to look further into the behavior. I agree, we should keep things in Markdown format as much as possible.
A button to view the Plain/Formatted text view, like a common "HTML Editor": so the user can view the plain Markdown text.
Absolutely, this is definitely on our roadmap. Here's an epic to follow along. We're actually doing some technical planning for this in the current milestone.
When editing long texts it would be useful to have toolbox panel in 'frozen' state. Now I have to scroll back and forth to apply 'header' style for some string.
Also I dont see 'code block' formatting option. 'Code' formatting applies for each row separately. I need to make it single block.
When editing long texts it would be useful to have toolbox panel in 'frozen' state
We've been exploring some improvements to the editing experience on the Wiki page and in the content editor as a whole and this is feedback we've definitely heard loud and clear. The good news is that we have an MR in review for adding a fixed vertical height to the editing fields in both the "classic" and new Wiki editors. This will be a great initial solution while we work on a larger update to the edit page.
As for code blocks, the button you're looking for is on the toolbar here:
Alternatively, you can surround your content with three backticks as you would in the raw source editor. Hope that helps!
I've found a bug with the table editor: I've created a table below a list with the old editor. Then I have opened it with the new one, saved (happens even without changing anything) and the new editor has removed the empty line between the list and the table. Because of that, the table couldn't be displayed any more after saving. This can be verified with 14.4.0-pre on gitlab.com.
I'm not 100% sure what's going on here @anke.visser but that's definitely not what we want to see. I have a feeling that it's something that will be fixed with our approach to serializing the Markdown content in order to preserve unchanged content as it passes through the editor. We're actively working on that now, so I hope this will improve for you soon!
@himkp or @ealcantara Would you be able to use this as a test case or confirm whether it's related to that serialization? If not, I'm happy to open a separate issue to investigate.
@ericschurter: I can’t assure that the work we are doing to preserve unchanged markdown will fix this issue. This bug is very specific to list serialization and preserving markdown source doesn’t change the way the serializer works. I recommend opening a bug report
There is already an issue about newlines being lost between two tables, but there isn't one for newlines removed between lists and tables. Ideally this should already be fixed after we remove the block tables feature flag (!71064 (merged)). If not, I will take this up in the next release.
First of all thanks a lot for this new editor which enables non-developers in our company to edit wikis (and hopefully issues and documents in repos etc soon) without learning Markdown first.
However, we did encounter some issues with HTML comments in the Markdown source which we sometimes use to instruct people, e.g. something like templates for meeting minutes as shown below. These comments originally being present in the source code will vanish once the new editor is used and the wiki page is stored.
<!-- ------- START COPY TEMPLATE -------- -->## ??.??.2021 (Template)**Participants**<!-- Please add or remove who participated and who did not -->* Mickey Mouse* Donald Duck* ...**Topics to discuss*** ...**Next Steps*** ...<!-- ------- END COPY TEMPLATE -------- -->
First of all thanks a lot for this new editor which enables non-developers in our company to edit wikis (and hopefully issues and documents in repos etc soon) without learning Markdown first.
You're welcome! We certainly hope it encourages more collaboration across teams and companies 🙌
we did encounter some issues with HTML comments in the Markdown source
You're right, this is a really common use case and one that we're not yet handling in the editor. I thought we had an issue in the backlog, but I couldn't find it so I created a new one: #342173 (closed). The last thing we want to do is accidentally remove content from a page so I'll get this prioritized as soon as I can.
There should be a way to preview the triple backtick code blocks. Specifically, when I am working on mermaid charts I often like to switch between the plain text and the rendered preview. There seems to be no way to do this with the new WYSIWYG editor. The mermaid code is displayed as a code block with no way to quickly preview.
Specifically for Mermaid diagrams, we have a placeholder issue that we hope to pick up soon that will render the output of the diagram in the editor: #332093 (closed)
@lanny.lin That's interesting 🤔 Are you on GitLab 14.3 or later? It should look something like this:
Clicking that little caret/arrow in any selected table cell should give you a popup menu of options, including the ability to add and remove columns or rows. Please let me know if you're not able to see that, maybe we have a bug or browser incompatibility issue?
You are right. Now I found it from the ^ dropdown menu. I was looking for it from the toolbar. Maybe change the icon for the dropdown to make it more visible in the future?
Clicking that little caret/arrow in any selected table cell should give you a popup menu of options, including the ability to add and remove columns or rows. Please let me know if you're not able to see that, maybe we have a bug or browser incompatibility issue?
That's great, thanks for confirming @lanny.lin! I agree, the UI has room for improvement, this was an initial iteration just to get something in place for this commonly-requested feature. We'll keep working on it and make sure it's more discoverable!
This is pretty cool and I look forward to it being finished.
I'm hoping to convert a multi-hundred-page Word document to Wiki, so I tried copying and pasting a chunk of it in - and it looked much better than I ever expected, but after saving and going to view mode, the tables turned to a hot mess.
Edit: Actually the tables are fine once you add in the "second line" that's alternating pipes and strings of dashes between the header and the body of the table.
I'm hoping to convert a multi-hundred-page Word document to Wiki
Oh wow, that's quite a task @WFDexter! I'm glad to hear it exceeded your expectations!
We have some upcoming work to improve tables, especially those with more complex structures. Perhaps it will get better with that work but I will keep an eye on this and give it a shot myself to see if I can replicate it (I have to get a copy of MS Word first, I guess 😆).
Also, pasting in from Excel results in an image - also not desirable but not sure what's actually in the clipboard at that point. If I remember right, Windows clipboard can have multiple versions of the same "copied thing" simultaneously so there's probably both tablular data and image in there and I suspect the default thing to get is image.
You can subscribe to Office 365 for $10/month (or $100/year) for personal use and there's a free month trial.
I'm using the desktop versions of Word & Excel, not sure if using the in-browser versions would behave differently.
Thanks for pointing that out @vincentSC! I believe it stems from the lack of support for block-level elements in a table cell. Luckily we have a draft MR already that adds support for these more complex tables: #335844 (closed). We're working on some related work that we need to merge first but hopefully you'll see this improve soon!
When, for example, I edit the description of an existing issue or edit an existing wiki page, I just want to go and make a quick fix at a certain place.
I go then and make this small change and press Ctrl+Enter (on my linux machine).
Which however triggers the wrong button! It used to trigger the "Save changes" button, that had the focus as the main button of the page. But now the focus is somewhere else (on the "Cancel" button !?) and all I get is a browser warning:
To make things worse, the "Save changes" button is greyed out and there's no way to convince the page to re-enable it... So I have to copy the text, leave the edit form, enter the page again and do my edit remembering not to press Ctrl+Enter but rather click on the "Save changes" button...
I don't have a linux machine to test this personally, but when I try any combination of shortcuts on my Mac to submit the page, it works as expected. Can you share which browser and version you're on so we can narrow things down and try to replicate the behavior?
@lanny.lin That is strange! Do you happen to have an example you can share that's part of a public project? I'd love to take a look at the console to see if we can get to the bottom of this.
If I go to the object details page of this, the public url and authenticated url are similar, but not exactly the same.
I was able to use <img> tag to include this image in my wiki page using the public url (googleapis.com) and also was able to resize it with height and width attributes.
So with the original problem I reported, if my image in google storage is not with public access, authenticated url would only work with the [[url]] notation, not the  or <img src="url"> notation.
I use the full screen option of the old editor a lot. The new one doesn't seem to have that?
My documents are always very structured, and I'm using headers, sub-headers, sub-sub-headers, etc. So the #, ##, ###, #### headings. In the new editor I must say that it is more difficult for me to keep track of the level of a particular heading. I'm not sure how you could solve that... Maybe some shortcut to jump from one header to the next of the same level? Or is that undoable?
I know the old editor didn't support that either, but what would be helpful is some navigation menu to jump to specific headings/levels.
You're right, the full screen option isn't available yet but we have this issue open for it: #335552 (closed)
In the new editor I must say that it is more difficult for me to keep track of the level of a particular heading.
That's really insightful feedback! You're right, especially since the difference in styling of the headers can be pretty subtle. We'll keep that in mind as we investigate UI changes. @mle👈 This is great feedback to consider as we think about the "bubble menu" approach
I know the old editor didn't support that either, but what would be helpful is some navigation menu to jump to specific headings/levels
That's a great suggestion! I created #342347 (closed) to track this feature and we'll continue to refine it as we iterate on the new editor.
hi,
I don't know markdown. wanted to copy a table from a google email to the new editor.
Did not work on just pasting it into a new editor after an initial comment, on a new line.
Then, first inserted a table of the same size as data (3 rows, 5 columns), placing cursor on first cell and pasting. the table looked good though it inserted a new table and the empty one moved below. but on saving it was all messed up. finally, put a link to a google doc. would be nice to be able to copy a simple table with all rows having the same number of columns from Libre office calc or writer or google email to an issue.
@jimsmith-vitrifi Thanks for the feedback. You're right, and thanks to a recent community contribution that closed out this issue, you should now be able to scroll vertically within the content editor while keeping the toolbar on screen!
For anyone following along that may have mentioned the difficulty in using the toolbar on longer pages, having to scroll back up to format text, or otherwise asked for a "sticky" toolbar: I have great news!
A fantastic community contribution was merged just a few days ago that introduces a vertical scroll inside the editable view, allowing the toolbar to stay on screen as you edit longer pages! 🎉 Here's the issue and MR for reference.
We'll continue to iterate on the layout and UI for the edit view, but this is a great first step in improving usability in both the Wiki editors!
So glad you're liking it @JayTT! Yes, we're actually working on that now and should have something in place in the next 1-2 releases where your preferred editing experience persists across edits.
Loving this and can't wait to have it everywhere. One pain point is it wasn't obvious how to delete a table once I had added one. I actually couldn't figure it out the first time and had to go back to markdown to remove it. The second time I tried, I finally clicked on the caret and saw you could delete the table. I would expect to be able to delete the table by highlighting and hitting the delete key.
Thanks @mnearents and bonus points for sharing feedback here instead of Slack! 🤣
Agreed, there's room for improvement here. It boils down to how we handle selecting of nodes in the editor, something we've captured here and hope to improve in the near future: #334147 (closed)
@userq Hmmm, that's unexpected. I think it's a bug. I'm actually seeing some other very weird behavior with the code blocks that we'll investigate at the same time. Thanks for pointing this out!
I've created #345425 (closed) to address some bigger bugs related to code blocks, but we'll be sure to include this feedback to ensure the plaintext attribute doesn't get added unintentionally.
Hi, this is still an issue. For me it would render the code blocks in the content editor, but upon clicking save I'd find all code snippets on my page have been replaced by
```
plaintext
```
effectively deleting all code snippets from that version, very frustrating.
I love the new editor, but have a problem where it is not able to save an edited page. I can make changes to the page using the normal text editor and it saves without any issue, but when I use the new editor, the save never completes.
The console error "Assertion failed" happens when I attempt to add text to the page.
The TypeError occurs when I save the page.
I am using "GitLab Community Edition 14.4.2". My browser is FireFox
I found the root cause of the problem. I had copied and pasted an image from within the editor. Once I removed the pasted image via the standard editor, I was able to save again in the new editor.
Why doesn't the insert link dropdown include a list of the other wiki pages to link to? Seriously, that is such an obvious idea it is impossible for me to invent a reason for not doing it
@r.brown.bayliss Thank you for taking the time to leave some feedback. I agree it is a good idea to include a list of other wiki pages to link to. I have created an issue for us to look into it #345861 (closed)
This is how it looks like on my side, with FF. If I zoom out to 90% then it gets back to normal.
improvements:
a. When dropping a link from google docs, if it can automatically convert it into its title with link to the document
b. when I select a link, would like to be able to modify it's text and its link in 2 separate field
Editor / format
Something that might not be directly related to this issue (then let me know where) but when I select org format instead of markdown, the editor still generate markdown, and do not preview correctly org
Thanks for the feedback @yashasolutions! I'll try to address each point:
The toolbar is getting a bit crowded and that's a challenge with smaller viewports. We're looking at ways to address this: #339673 (closed)
Automatically converting google docs (or other links) into rich previews is something I've thought about. Just formatting the link with the document title seems like a great first iteration. I went ahead and captured that here: #346068
You're right, you should be able to edit a link's description and URL separately (also the title). I thought we had this on the backlog already, but I couldn't find it. So I created this issue: #346070 (closed). Thanks for that suggestion!
Previewing Org docs in the wiki isn't directly related to this, but I appreciate the feedback! We have an issue to track this feature here: #228886
Two things related to 'collapsible':
Copy pasting content from one page (with the new editor) into an other wiki page (with new editor enabled as well) doesn't yet work when copying collapsible elements.
Hello,
noticed that the new editor is changing content of the .md (and not always correct)
plantuml inside ``` replaced with <div> container
followed the plantuml block header is moved a line upper - so it is not a header anymore
Cyrillic ref withing same page is replaced with encoded url href
to reproduce:
create an .md on pc
-> push to wiki
-> open and edit with new editor
-> add a dot (or what so ever) and save
-> pull back to pc
-> check content
Below are:
screen 1 - origin content
screen 2 - content after saving in a new editor
screen 3 - git diff
Thanks for the feedback, @roman2git! The Content Editor doesn’t support PlantUML or Kroki diagrams yet. We have an issue that documents this requirement: #332095 (closed)
I will investigate the technical requirements now, and determine with @ericschurter if we can schedule this feature for the upcoming milestone.
Thanks for adding that detail @ealcantara and @roman2git for highlighting the gap. We'll work in the issue on the details but hopefully we can get the backend support needed to ensure the integrity of the document loaded into the new editor.
@ealcantara or @himkp can you add any additional details to the Cyrillic text being URL encoded? I would expect the unicode characters to remain unchanged.
@ealcantara, @ericschurter - thank you both for the response.
Just want to add I was concerned even not about functionality, I'm worrying about the content unpredictable changes. If the new editor can't handle plantuml not an issue in general (however would be nice) but I still expect editor to not touch any part it doesn't understand and the content to be preserved 'as is', at least I would not be afraid to open docs in the new editor.
Basically (in my opinion) the safe "Open-Save-Close" is "must to have" functionality.
@roman2git Absolutely, I understand where you're coming from and data integrity is our top priority as we mature the new editor! As you said, if you can't trust the editor to open a document safely, you're never going to try it.
We'll be working on the few remaining edge cases that aren't preserved over the next couple releases.
My personal feedback:
I feel uncomfortable writing markdown and then suddenly my "#", "*" are disappearing or links "[]()" are not working, because "[" is interpreted as "\["...
My personal favorite would be, having the "Write" and "Preview" tabs opened at the same time side by side (comparable to codimd).
I will not use the new editor.
@dr.br Thanks for the feedback and I understand where you're coming from. We recently introduced a live side-by-side preview of Markdown content in the Web IDE and Web Editor, which we will continue to iterate on and improve. That might be more desirable than the WYSIWYG mode for you, and many others. We're not looking to force anyone to use the new editor, so rest assured you will always have the option to write raw Markdown.
We are looking at completely replacing JIRA with gitlab because JIRA switched to a WYSWIG only editor. Adding WYSWIG is cool, but please don't remove the raw markdown editor.
😄@JRocha-Stratovan You're making some of our engineers very happy with that statement! 100%, we hear this and we will not be removing the raw Markdown editor (or limiting its functionality). In fact, one of the many principles we designed this new editor around was to ensure the Markdown source stayed intact so it could still be stored in the repo and edited locally. So, if you like using vim to write Markdown, you got it. But if your PM or Designer prefers a visual table editor? They're covered too!
Hi. Thanks for working on improvements to Wiki Editor.
I find the new editor good to write non-tech text documents, and very limiting for technical developer documentation:
Impossible to specify the programming language of the code block (in Markdown it's possible with language name next to the beginning of the code block).
Text editing inside of the code block with >100 lines is super slow (it takes half a second to type the new letter after the previous one)
Having text in code block
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.Line 2 Line 3
the navigation via pressing arrow up from position at the beginning of third line scrolls the code block as if I jumped with the cursor to the end to the first line, but actually I jumped only to the second line.
@edudnyk I appreciate the feedback, this is very helpful. On the topic of changing the syntax highlighting language, that is something on our roadmap and we hope to work on it in the near future. I hadn't run into performance issues related to code blocks myself, so this is a great test case to consider. @himkp@ealcantara FYI, as we look to improve the performance of the content editor as a whole.
I was missing the ability to highlight. We often write TODO <mark>TODO</mark> to highlight updates we need to make or questions we have for each other.
Thanks for that feedback @hellokailyn! That's a great example of inline HTML that isn't technically part of the GitLab Flavored Markdown spec that we want to support. While the Content Editor can render existing content that includes <mark> formatting, there is no way to apply it visually in the editor. I just created #349078 (closed) to track that feature.
Hi! I've been doing some documentation for my team's repository. But from some weeks (mid December...aprox) until now, I've been experiencing some issues with the new editor. Sometimes the tab does not respond (when copy-pasting a piece of code from pycharm) a piece of text or even the whole page is deleted (while doing cmd+z)
This causes to lose all work done and/or lose some already created code extracts (displayed as "plain text"). It's a shame, because from everything else the new edit is really helpful and easy to use.
@gustavo.rivera I'm sorry to hear that! If you wouldn't mind, can you share more about your setup and the scenarios in which you've encountered lost data? I'd like to understand whether this is a performance bottleneck with large amounts of clipboard data, or possibly a content node type in particular that's having issues. Are you able to reproduce this on multiple browsers? I appreciate any additional details you can provide since data integrity is the most important thing to us.
One quick way to reproduce it (after several tests is the "go to" way) is:
Edit a page with a code block already on it
Change the view to the rich text view
Click the copy to clipboard on the previous code block
Sometimes it gets blocked even after step 2.
Chrome Version 96.0.4664.110 (Official Build) (x86_64). The first time that happened this week:
Currently having 3 tabs pinned (gmail, calendar and jira) and our repo wiki opened. I clicked the Edit page and starting writing with the rich editor. First thing was to set the headers, followed by "normal" text and afterwards a code copy paste from a ".robot" file opened with pycharm.
I've been able to reproduce it on firefox also, version 95.0.1 (64-bit), with no other tabs opened besides the gitlab wiki page.
@gustavo.rivera Thanks for that context! I was following up to see if the related issues in threads below may have resolved your issues with code blocks? Are you still experiencing this now that %14.7 has been released?
@ericschurter Hi!! Yes, I've been somewhat working on other wikis of the repo and it seems that everything's ok. At least from my side. Thank you very much for all the work :)
Am I missing something? After updating to 14.6.1-ee and switching to the WYSIWYG editor, I can't find the new "Edit source" link in the Content block that is shown in the release notes. The WYSIWYG editor also reverts back to the classic editor upon save/cancel.
Thanks for reporting this @Thaurin – I'm not sure what's going on here. @ealcantara@himkp would one of you mind investigating? I'm not sure what could be causing the Edit source link to not appear.
@Thaurin: On self-managed GitLab, by default this feature is not available. To make it available, ask an administrator to enable the feature flag named wiki_switch_between_content_editor_raw_markdown.
Another interesting issue I'm seeing is that the rich editor is emptying my code blocks in the wiki. These code blocks are in a numbered list; I haven't tested this for code blocks that are not in a list, but I assume those would work. For example, if I had this on a page:
```xml <add key="my-key" value="key-value" />```
After saving it with the rich text editor, all that is left is:
```xml```
The classic editor functions as usual. Other than that, slightly less worrisome, the rich editor seems to change some other things in the Markdown:
Bolded text in back ticks (i.e. inline code that is bold) in a list is replaced by just backticks (bold is removed)
The lesser/greater than characters in URLs like <https://www.google.com> as Markdown standard are removed, also in a list
Some empty lines are removed
Some extra whitespace is added at the end of a line
Of course, these things, especially the first, currently make the rich editor unusable for us.
I tried to create a new wiki page and pasted that XML code block into the classic editor, then tried switching to the rich editor and the page shows a spinning loader forever and hangs until I kill the tab. I'm out for now, good luck.
Thanks for reporting these issues. I could reproduce the code block issue you ran into, and I’m currently working on a fix. I apologize for the inconveniences.
!78081 (merged) enables to wrap inline code in bold and other formats.
Regarding the other problems:
The lesser/greater than characters in URLs like <https://www.google.com> as Markdown standard are removed, also in a list
Could you provide a Markdown snippet that demonstrate this problem so I can reproduce?
Some empty lines are removed
We’ll start working on a technical spike to determine an approach to preserve Markdown that is unchanged. This is the related issue: #347558 (comment 807545584)
Some extra whitespace is added at the end of a line
Could you provide a Markdown snippet for this one as well?
If I click "Edit rich text", then click "Edit source" before it is done loading, the entire document contents disappears.
If I click "Edit rich text", wait until it loads, then click "Edit source", the code blocks all lose their content and become empty code blocks. Blocks without a code type gain the plaintext type, and bash blocks become shell:
```shell```
I start with a larger document, copy all the contents and replace it with the bash code block included above, then click "Edit rich text", wait until it loads, then click "Edit source". The document becomes unresponsive and the content never loads, and this forces me to reload the page.
If I click "Edit rich text", then click "Edit source" before it is done loading, the entire document contents disappears.
I’ll submit an MR to address this problem.
I start with a larger document, copy all the contents and replace it with the bash code block included above, then click "Edit rich text", wait until it loads, then click "Edit source". The document becomes unresponsive and the content never loads, and this forces me to reload the page.
If I click "Edit rich text", wait until it loads, then click "Edit source", the code blocks all lose their content and become empty code blocks. Blocks without a code type gain the plaintext type, and bash blocks become shell
We’ve addressed these problems in !77965 (merged) and !78071 (merged). This fix will be included in 14.7. I apologize for the inconvenience.
My feedback after just trying to use this in 14.6.2 is:
There is no indication in the release notes (https://about.gitlab.com/releases/2021/12/22/gitlab-14-6-released/#toggle-wiki-editors-seamlessly) that the live switch feature is hidden behind a feature flag in self-managed instances. Please can you add a sentence to the release notes to mention that? The only way I found out was by reading the comments in this issue. Also please can you say which upcoming release is set to enable the feature by default?
I also have the 100% CPU tab lockup issue in both Firefox and Chrome, causing the laptop fans to go crazy. It sounds like that will be fixed by !77965 (merged), although we would definitely appreciate it if it could go into a 14.6.3 release.
It's a real shame that it is not possible to use the editor when editing .md files in the code repository. It looks like this is now tracked by #349635 (closed). Hopefully this can be implemented soon, as our main use for Markdown is editing hundreds of .md files in code repositories, not in the wiki.
That being said, I really appreciate the work on this feature which should be very useful to us once the above issues have been fixed. Thank you for your continued hard work.
Hi @montgomery.anand thank you for your feedback and apologies for the delay in response!
To your specific points:
Apologies again, that miscommunication was my fault as I didn't realize the feature flag was still in place when the release was cut. We strive to be accurate with the release post and documentation but the feature flag should be defaulted to on for everyone now.
I don't believe this was a bug that was getting patched back to previous releases but @ealcantara can confirm there. Hopefully now that %14.7 is released you can update soon.
Absolutely, I agree with you that this becomes so much more valuable once it's applied to the repository editor and Web IDE. We are headed in that direction but we wanted to make sure to mature the WYSIWYG editor in a more controlled environment first. The Wiki was perfect for that and luckily the work has paid off and we're close to being able to introduce it elsewhere!
I don't believe this was a bug that was getting patched back to previous releases but @ealcantara can confirm there. Hopefully now that %14.7 is released you can update soon.
@ericschurter: That’s right. We didn’t patch previous versions, and we addressed this problem in 14.7.
@kyle_hunter Yes, that's a great feature that we'd love to add as soon as possible. We're tracking it here: #322174 (closed) in case you have any specific implementation notes or just want to follow along.
Visual editor reformats existing markdown pages. Doing so it f***ed up code markdown "```". Therefore all bash commands in our doc "vanished" after saving the article with visual editor.
@m4x.mu3 I'm really sorry to hear that, data integrity is one of our highest priorities. I know that can be frustrating and I hope you were able to get the content back by using the Page History button on the wiki page.
Can I ask what version of GitLab you are using? I was aware of some bugs related to code blocks, but I thought they were resolved in %14.7. If not, we'll absolutely look into this right away.
@m4x.mu3: Could you provide us with an example of the bash commands that vanished from the document, please? We fixed some problems with code blocks, but none of them removed the code blocks from the document.
@ericschurter@ealcantara excuse me I didn't want to blow up my feedback text and therefore left out the part that we could easily revert my changes. No frustration on our side as gitlab is fantastic in exactly this use case. 😄
Version: 14.6.2-ee
I'll forward your feedback about 14.7 to our gitlab team.
Our code looked something like this:
* category
```
software
```
The code block stayed but "software" wasn't readable anymore after saving the page.
Thanks for sharing this code snippet, @m4x.mu3. I pasted it in the Content Editor, and I couldn’t reproduce the problem that you describe. We are aware of a bug that adds plaintext to code blocks that don’t have a language set, but that doesn’t make the code blocks unreadable anymore:
Problem: Editor deletes empty lines after collapsible section
The editor is a really great alternative and simplifies the interaction with Gitlab especially for new colleagues. Unfortunately, we encountered the following problem:
The editor deletes empty spaces after the collapsible section. I couldn't find an already existing report to this topic in this thread, so I created this one. Thank you very much.
Thanks for sharing this feedback @StephanM87! I'm going to see if it's related to #342345 (closed) but if it's not, I'll create a new issue to track this bug.
Thanks for reporting this @FossPrime, that's concerning.
@ealcantara given the relationship with empty lines, I tried reproducing it on production hoping it was fixed by !81849 (merged). Unfortunately it is quickly reproducible still. Is there a chance that MR introduced a bug in the serialization of tables?
@ericschurter I checked and can confirm that while this bug exists on production, it wasn't caused by the recently merged MR.
@ealcantara I think the root cause for most of the issues like this is that the markdown serializer adds one line break between elements like these instead of two.
We appreciate the feedback @mxzinke! I'm not sure that I understand the issue you're running into. Can you share more about your setup (browser, OS, GitLab version) so we can try to reproduce it here? This is what I'm seeing:
For those following along, this long-standing issue has been incredibly valuable but it has become a little unwieldy to manage individual threads of feedback. I'm closing it but please keep your feedback coming in the form of new issues labeled ~"group::editor" and Content Editor. Thank you everyone for your feedback!