# Announcing the Stacks Editor Beta release!

TL;DR: The Stacks Editor Beta release rolled out on July 5, 2022! To see what we've been working on, what we are working on, and what we plan to work on, check out the Stacks Editor repo on GitHub. The editor is still an opt-in feature, and there is currently no timeline for a network-wide deployment.

## This question is no longer being monitored for new answers. If you have further bug reports or feature requests for the new Stacks Editor, please post them as new questions tagged stacks-editor.

Back in early 2021, we announced the launch of the Alpha version for a new Stacks Editor. The announcement post saw a lot of activity, and after a lot of work by our Stacks Team, we're ready to launch the Stacks Editor into its Beta version!

In the original announcement for the Alpha Version of the new editor, Catija highlighted some of the reasons why we needed to create a new editor, ranging from meeting our Teams users' needs to simplifying future dev work on the public sites (you can read more in the original announcement). We asked you to test it and provide feedback — and you did. The post gathered 110+ answers with bug reports, feature requests, and more general feedback provided by you.

The team worked hard to respond to your feedback, but after a while, public feedback from the team about what was being worked on slowed to a near halt. While the team was still working silently on the Stacks Editor during this time, they had to balance this work with other priorities on their plate. More importantly, though, and as I mentioned above, we ended up not updating you on where work on the editor was and where we were planning on going with it: this doesn't reflect well on us, and we apologize. We'll aim to be more proactive and frequent with communications on this going forward. This brings us to this post.

As Yaakov mentioned earlier in June, the Stacks Editor is the main editor used in the new Ask Question Wizard, which will be made available on Stack Overflow sometime after the Beta 2 release goes out. The new Wizard, in turn, will later be a central piece of the Staging Ground project. So where are we going next?

You can have a look at the Stacks Editor repo on GitHub to see a breakdown by feature of what's been worked on and what is still to come (issues in the “No Milestone” section are backlogged, with no projected pick-up date). To give you a high-level overview:

• Alpha 2: This is what the team's been silently building and shipping since the original Alpha release of the editor. The editors used on network sites were updated to include this release on June 21, 2022. The team’s worked to fix many of the issues reported by you, including:

• Beta 1: This was released on July 5, 2022 and is in production as of July 12. Full release notes are available. The main accomplishment of this release is to ensure the back-end library is feature-complete as compared to the old editor — meaning the Stacks team laid the groundwork that’ll allow the dev teams responsible for the Public Q&A sites to work on Stack Exchange-specific functionality. With this, the latter teams will be able in the future to build plugins into the editor, with the goal of reaching feature-parity (for all sites) to the old editor available on the network. Some of the issues addressed on this release were:

• adding initial support for a Markdown preview pane — we know this was a big pain point for many of our power users. Some integration work with the product still remains to be done before this is usable on the sites — we will post a separate update detailing this when it’s ready;

• enhancements to link insertion and editing, as per the issues reported here and here;

• and adding official external plugin support, which will be required for supporting various extra editor features across the Stack Exchange network, such as poker, go, chess, code snippets, and MathJax.

• Beta 2: This was released on July 28, 2022, and the editor was released on participating sites on August 8, 2022. For this release, we identified some issues we feel should be addressed before launching the Ask Wizard and Staging Ground projects. This release also included some issues that were reported in answers to this post. Some of the highlights for this release are (full release notes also available):

• An overhaul to the code highlighting system that addresses a number of issues reported with highlights to Markdown mode when text isn’t CommonMark compliant, as reported here, here, and here.

• A change in the toggle between Rich Text and MarkDown modes - the toggle is now icon-based, instead of the on-off switch that had been in place up until now.

• Bug fixes with image-uploads (here and here), code block serialization.

• Block elements are now allowed inside list items.

• Note: while the preview pane plugin is working in the editor code, some work remains with integrating this into the site. We'll post a separate update detailing this when it’s ready.

• Beta 3: These are issues that would be beneficial to address, but not required for baseline functionality. Once these are addressed, the Stacks Editor should be ready for a network-wide deployment (though we don’t currently have any plans to do that; more on that below). There isn’t a timeline for addressing these issues, and the team will tackle them as their bandwidth permits. Highlights for this release include:

Until the end of July 2022, we have members of the Stacks team as well as devs from one of the teams responsible for Public Q&A assigned to working on the issues marked as essential for the Beta 2 release. Additionally, there’s some flexibility on that roadmap to account for high-priority issues reported in response to this post, and though we can’t guarantee we’ll be able to address every single thing reported, we’ll be responding to all feedback as we triage it and, all applicable unique issues will be logged in the Stacks-Editor repo. Once July’s over, we’ll still be monitoring and responding to issues and feature requests surrounding the Stacks editor, be them reported on MSO or MSE (which can be brought to staff attention using this process), or on GitHub (more on how to report issues at the bottom of the post). These will be triaged based on severity and developer availability to prioritize issues for the Beta 2 release.

## FAQ

### What was that about a network-wide deployment?

As I mentioned above, the Stacks Editor is a central piece of the new Ask Question Wizard and Staging Ground, so for now we’re committing resources to ensure the work needed to support that project is successful. Additionally, we’re expecting you will report many more issues that have yet to be identified, and have to be prepared to be able to address those issues and respond to those reports. For that reason, at the moment we don’t have any timeline to roll out the Stacks Editor network-wide, and are instead focusing on ensuring we can undertake the near term work required to support the Ask Question Wizard and Staging Ground project. When we get to the point where it looks like extending the opt-in testing to questions, or even a network-wide deployment might be in sight, we’ll make sure to loop you in.

### Is this still opt-in?

Yes! The editor will continue to be available on Stack Overflow for Teams, and for answering questions on Meta Stack Overflow and Meta Stack Exchange — this is reached via an opt-in on the Profile > Settings page labeled “Enable new editor” (the text here will be updated soon to change the “Alpha” label into a “Beta” label). When the Ask Wizard is released on Stack Overflow, all users will be able to toggle into this question asking mode, where they’ll be able to try out the Editor in that context as well (more details around this will be shared on MSO when the release is made).

### How to provide feedback

• I have updated the statuses on all old posts/answers to reflect what was completed and released in Alpha 2 and Beta 1.
– Yaakov Ellis StaffMod
Jul 12 at 14:40
• I am a bit annoyed. How did I miss that y'all finally decided to include a preview pane, which is the main thing I miss from the old editor 😁
– Journeyman Geek Mod
Jul 12 at 18:44
• @JourneymanGeek You didn't miss it. This is the first time that we announced a preview pane. It is built into the editor not (you can try it out here), but it still needs some tweaks and integration work to get it to work on the sites. There will be a separate post about it when it is ready to go.
– Yaakov Ellis StaffMod
Jul 13 at 8:54
• Not quite a feature request proper - and more for the future but for the sake of clarity - especially during the beta phase, and as/when the new editor is more widely used, would it be sensible to have the current version somewhere for the ease of classification of bug reports between versions?
– Journeyman Geek Mod
Jul 14 at 12:56
• @JourneymanGeek you can always try out the current version at editor.stackoverflow.design (this will always be the same version as on-site, except for the slight lag between when a new version is released for the editor and has not yet hit the site).
– Yaakov Ellis StaffMod
Jul 14 at 13:01
• can implement fira code or any font with ligature in code??? i.imgur.com/mOO2sOM.png Aug 5 at 17:21
• @ArcanisGK507 we don't have plans for custom font support in the code editor.
– Yaakov Ellis StaffMod
Aug 7 at 13:41

## Summary of bugs / feature requests posted as answers

Want to contribute? Great! But please read the notes at the bottom of the table first.

### Credits

Original idea: here, further refined here and here.

Run the snippet below to check if this summary is up to date, or which changes are needed.

const summaryAnswerID = 380354; // ID of the summary answer
const key = "U4DMV*8nvpm3EOpvf69Rxw(("; // taken from API documentation
const typeTagRegex = /$(meta-)?tag:(discussion|support|feature-request|bug)$/i;
const statusTagRegex = /$(meta-)?tag:(status-[-\w]+)$/i;
const summaryRegex = /#+\s+(.*)/i;
const site = "meta";

async function main() {
// Find question ID and current summary
var result = await $.get("https://api.stackexchange.com/2.3/answers/" + summaryAnswerID + "?site=" + site + "&filter=!nKzQURFm*e&key=" + key); let questionID = result.items[0]["question_id"]; let summaryBody = result.items[0]["body"]; let summaryMarkdown = result.items[0]["body_markdown"]; let lines = summaryMarkdown.split(/\r?\n/); var linesToAdd = []; var linesToChange = {}; var page = 0; while (true) { // Fetch answers result = await$.get("https://api.stackexchange.com/2.3/questions/380295/answers?page=" + ++page +
"&pagesize=100&order=asc&sort=creation&site=" + site + "&filter=!nKzQURFm*e&key=" + key);
for (let item of result.items) {
// Summary?
continue;

// Present in summary?
var currentLine = null;
for (let line of lines) {
if (line.search(new RegExp('/a/' + answerID + '[/)]')) != -1) {
currentLine = line;
break;
}
}

let markdown = item["body_markdown"];
let typeTagMatch = typeTagRegex.exec(markdown);
let summaryMatch = summaryRegex.exec(markdown);
let statusTagMatch = statusTagRegex.exec(markdown);

if (currentLine == null) {
// Generate new entry
let title = summaryMatch == null ? "(please add summary)" : summaryMatch[1];
let summary = "[" + title + "](/a/" + answerID + ")";
} else {
// Compare against summary
let components = currentLine.split("|");
let typeTag = typeTagRegex.exec(components[1].trim());
let summary = components[2].trim();
let statusTag = statusTagRegex.exec(components[3].trim());
let gitHubLink = gitHubLinkRegex.exec(components[4].trim()); // may be absent, if GitHub isn't used
var changeNeeded = typeTagMatch != null && (typeTag == null || typeTag[2].toLowerCase() != typeTagMatch[2].toLowerCase());
changeNeeded |= statusTagMatch != null && (statusTag == null || statusTag[2].toLowerCase() != statusTagMatch[2].toLowerCase());
if (!changeNeeded)
continue;

linesToChange[currentLine] = generateLine(typeTagMatch, summary, statusTagMatch, gitHubLinkMatch);
}
}

if (!result["has_more"])
break;
}

// Changes needed?
if (linesToAdd.length == 0 && Object.keys(linesToChange).length == 0) {
return;
}
var messages = [];
messages.push("\nThe following lines need to be added:");
}
}
if (Object.keys(linesToChange).length != 0) {
messages.push("\nThe following lines need to be changed:");
for (let lineToChange in linesToChange) {
messages.push("\n" + lineToChange + "\n-->\n" + linesToChange[lineToChange] + "\n");
}
}
console.log(messages.join("\n"));
}
main();

function generateLine(typeTagMatch, summary, statusTagMatch, gitHubLinkMatch) {
var components = [""];
components.push(typeTagMatch == null ? "(please add type)" : "[tag:" + typeTagMatch[2] + "]");
components.push(summary);
components.push(statusTagMatch == null ? "" : "[tag:" + statusTagMatch[2] + "]");
}
components.push("");
return components.join(" | ").trim();
}
<script src="https://code.jquery.com/jquery-1.11.1.min.js" type="text/javascript" ></script>

• @Glorfindel: That's one heck of a snippet you got there. Works like a charm! I've not added the post that needs to be added because it's a duplicate of an existing report. Jul 23 at 17:16

Toggling Markdown off and back on causes reference-style Markdown links to be re-sorted into alphabetical order rather than natural order.

• Source of the problem. Ideally, the original order should be preserved. Jul 13 at 6:38
• Jul 14 at 11:46

Copying text from one list bullet to another inserts the pasted text as a new sub-bullet.

• This is particularly vexing when composing review suspension messages, which use the new editor and whose content consists largely of a bulleted list of reviews. You can work around it somewhat by using Ctrl+Shift+V to paste without formatting, but then you can't copy the useful parts of the formatting. Jul 12 at 14:34
• Also reproduced on Firefox on MacOS, cc @YaakovEllis Jul 13 at 10:07

Inserting an image never works the first time; you always have to cancel the image insertion dialog and re-do it. This happens with both copy/paste and drag & drop. Tested in Firefox 104.0a1 on Windows 10.

• Also reported as a separate post here: New Stacks Editor doesn't let me upload images at first try Jul 12 at 14:30
• Also fails on MacOS. The only way to get this to work directly is to open the image dialogue, and paste an image in there. Jul 12 at 19:41
• Also doesn't work the first time when pasting an image. Even worse, if you try to paste a different image in the second time, it uploads the first one 🤦‍♂️ Jul 12 at 23:53
• @41686d6564standsw.Palestine is that a separate issue? I've noticed if you focus on the image upload bit it works first time with a paste? Jul 20 at 14:20

Toggling Markdown on and off combines adjacent code blocks added in rich text mode.

• Wasn't this, or something very much like this, fixed in the original alpha release? Jul 12 at 15:03
• I wonder if a more robust solution here would be to serialize the code blocks into Markdown with the triple-backtick codeblocks () instead of pure whitespace indentation. The code block button in Markdown mode already does this, and has the added benefit of being able to specify the syntax highlighting manually (css).
– Tyler McEntee StaffMod
Jul 12 at 18:23
• Either way, we still should be able to insure we preserve that indentation-free line in between the code blocks when round-tripping between Markdown and Rich Text modes.
– Tyler McEntee StaffMod
Jul 12 at 18:24
• @TylerMcEntee Addind a fence in rich text is likely the only chance because per CommonMark specification one empty line on the same indentation level does not break a code block. Jul 13 at 10:49
• @TylerMcEntee That you don't insure round trips from Markdown->rich text->Markdown always preserve things exactly as they were in the Markdown source is a huge portion of the fundamental problems with this editor. If you were insuring preservation in all cases, then a large number of your bugs wouldn't exist and people would be substantially more comfortable using this editor. Combined with having no preview other than switching to rich text mode (i.e. that to preview requires corrupting the Markdown) is one of the major reasons there's been such a negative response to this editor. Jul 14 at 14:43

The keyboard shortcuts use lower case for the letter keys, e.g. "Cmd-h" on macOS or "Ctrl-h" on Windows:

Could you switch that to upper case - that is much more common across the internet, and even used that way here, e.g. in the regular keyboard shortcuts:

• I would say that if the keyboard shortcut does not work if you press, say, Cmd-Shift-h, then this should not be done. Without the double negative, only change them to upper case if using them with an upper case letter works. Jul 12 at 16:13
• @HereticMonkey please have a look at your keyboard. The keys have upper case letters, right? Nobody gets confused that it usually produces lower case letters. I'm not really confused either, except when it comes to things like "Cmd+l" - is that a lower case l or an upper case I? Therefore, consistency is key, and keyboard shortcuts (almost?) always use upper case.
– Glorfindel Mod
Jul 12 at 16:55
• It isn't only case. The notation is a remnant from Emacs. A more common notation is Ctrl + H or Ctrl+H (without space). The existing editor (and the Visual Studio Code documentation and many others) uses the latter, e.g. "Strong <strong> Ctrl+B". Jul 13 at 10:15
• (More examples from Visual Studio Code documentation.) Jul 13 at 10:21
• @This_is_NOT_a_forum Emacs would write C-h for "Ctrl+H" or M-h for "Cmd+H." For example, the save chord is C-x s, which modern shortcut notation would write as "Ctrl+X, S," and the copy chord is M-w, or "Cmd/Alt+W." Jul 13 at 13:13
• @HereticMonkey A keyboard shortcut like ctrl-v tends to work even if caps lock is on. Therefore, the case of the s doesn't matter. ctrl-shift-v is a separate keyboard shortcut that works regardless of whether caps lock is on or off, it is more helpful to spell out the shift button rather than omit it and hope that the reader understands that a capital S indicates that the shift button should be pressed (regardless of caps lock mode). Aug 3 at 8:20

In Rich Text mode, we can choose different header levels:

In Markdown mode, we only have one, the H1:

Can we have that dropdown in Markdown mode too? And since (IIRC) the switch to CommonMark, we now have six levels of supported headers. It might make sense to add those too.

• Additionally: could we consider removing Heading 1 from the list? It is obnoxiously large, putting it on the same level as the page title. It definitely should not be the default heading level that is applied in Markdown mode. Jul 13 at 3:29
• @RyanM I don't (think I) use it, but it feels weird to start the list with #2. Heck, as a programmer I'm already confused it doesn't start with 0 ...
– Glorfindel Mod
Jul 13 at 7:00
• A better alternative approach might be to silently translate the headers in the post source into one level lower. For example, using Heading 1 would produce an <h2> tag, Heading 2 would produce <h3>, and so on. Though that creates the question of how to best handle existing posts that already use headings. Jul 13 at 8:07
• Agree with @RyanM. WCAG accessibility guidelines advise that there should only be one <h1> tag on a webpage, which should be for the page title, which for SO is the question title. There should be no other <h1> tags on the page because screen readers don't handle multiple <h1> tags well. Jul 13 at 13:06

The Heading button's tooltip (Ctrl-h) is hidden by the list of heading options (such as Heading 1, 2, 3).

There's too much space between "Draft saved" / Community wiki checkbox and the bottom edge of the new editor:

Compare with the old editor:

• @Yaakov no GH entry for this one? (Asking because it's in status planned.) Jul 14 at 15:29
• No. It is logged internally, as it is an issue with how we use the stacks editor on the site, not an issue with the stacks editor itself.
– Yaakov Ellis StaffMod
Jul 14 at 15:30

There's some weird behaviour when dragging to select a link in the rendered view. The raw link in the popup is also selected:

1. In Markdown mode if you press the Inline code button a first time you get a pair of backticks:

1. If you next press it a second time you get another pair of backticks:

1. But if you press it a third time the second pair of backticks are just removed and you return to step 1.

Is this intended behavior? Should the second click in step 2 remove the backticks from step 1 instead of adding another pair? I fail to see the gain from a Markdown syntax POV in having 2 pairs of backticks, either you have a literal defined by 1 pair or a code fence defined by a pair of 3 backticks... Right?!

Also reproduced on https://editor.stackoverflow.design/ using Firefox 102.0.1 (64-bit) on Windows 10.

• The removal of the backticks in your Step 3 is because you already have one set of backticks highlighted. The button at that point effectively functions as a toggle for inline code formatting.
– Tyler McEntee StaffMod
Jul 12 at 20:38
• I cannot reproduce this (windows chrome 103) on answers on the site or the test editor
– Yaakov Ellis StaffMod
Jul 13 at 11:39
• @YaakovEllis I think that was fixed yesterday since the dev acknowledged the behaviour? Maybe a fix was rolled out and it's status-completed? Jul 13 at 11:51
• I cannot repro on Firefox 102. Every time I try, regardless of browser, and regardless of keyboard shortcut or button, the text with the backticks is highlighted after the first inline-code formatting, and then is completely un-backticked after clicking again.
– Yaakov Ellis StaffMod
Jul 13 at 11:52
• I can confirm that this was not fixed yesterday (maybe it was fixed in the past). Do you still see it now?
– Yaakov Ellis StaffMod
Jul 13 at 11:53
• @YaakovEllis yes, did it right now. Start with an empty line that has empty lines above and below, click the Inline code button 3 times without any text and it happens. Jul 13 at 12:00
• I get it now. It is happening when you click the "inline code" button with no text selected. Then (as happens with bold, italics, etc), only the text inside the new markup is selected, so as to allow the editor to just start typing and maintain the new formatting. When clicking the button again after doing nothing, it will do as you noted. I am mixed as to whether to mark this as a bug, by design, or wont-fix. We'll talk internally.
– Yaakov Ellis StaffMod
Jul 13 at 12:12
• @YaakovEllis my suggestion: allow the 2nd click to revert back to the exact state that preceded the 1st click, if the user did nothing else in the meanwhile besides those 2 clicks. Jul 13 at 12:43
• @bad_coder I removed my earlier comment identifying this as a bug. After getting caught up on the comments this morning I realized I was applying my own selection over text, not clicking the Bold/Italic/Inline Code buttons in an empty editor. Like Yaakov said, it's a little more complicated than I previously alluded to.
– Tyler McEntee StaffMod
Jul 13 at 13:02
• @TylerMcEntee yes, the issue isn't obvious. The button works as a "surround with markup" shortcut, but next the text selection stops the more intuitive undo Ctrl+z functionality (the right choice is actually the keyboard, not the button). It's a UX issue and I'm left wondering how popular IDEs do it!? I think novice users (and rich text folks especially) will find the buttons unappealing because they're likely to expect a 2nd click undo, if they get it wrong they'll have to select, delete, so the mis-click/expectation will lead to overhead in undoing making for an unpleasant experience. Jul 13 at 13:19

Selecting heading text (with the hashes) in the Markdown view and applying blockquotes using the Markdown button for blockquotes (or using Ctrl+Q) removes the hashes and renders it as normal text. This does not happen when applying blockquotes using the > character:

Also reported in this answer to Opt-in alpha test for a new Stacks editor.

The undo/redo buttons (which may only show up on mobile?) always look enabled even if I haven't done anything:

The table button however looks disabled because I selected some text in the answer.

They used to be disabled if there was nothing to undo/redo (though that had its own bugs).

Toggling from Markdown to rich text and back to Markdown causes asterisks (in the placeholder text for links) to be displaced.

Also reported in this answer to Opt-in alpha test for a new Stacks editor.

Tags should be automatically rendered when first typing it in the rendered view.

This is what it looks like when switching to the Markdown view:

It only renders after posting the question / answer.

In rich text mode in Firefox only if you insert a link and next try to move the cursor using the left arrow starting from the right, the cursor gets stuck and won't move past the second to last char in the link.

The same doesn't happen however starting from the left side and using the right arrow to cycle through the characters, in this case you can move across the text in the link and beyond.

• Repro in Firefox 102. Works fine in Chrome 103.
– Yaakov Ellis StaffMod
Jul 14 at 11:22

The editor seems to support comments like <!-- language-all: bash --> but it's just not taking effect. A comment like <!-- language-all: lang-bash --> disappears when switching modes.

Code example:

Var "hello"


I have a comment above the code but it's still showing as "plaintext". System: iOS. Let me know if you can reproduce on other setups.

• If you wait a second or so, it appears to correctly switch to bash formatting. I also can't reproduce it losing the comment when switching modes, at least by editing your post. Jul 13 at 0:30
• @RyanM How many seconds? I've done my Mississippis and I've spent the time to write this comment and it still says "plaintext". It could be a browser specific thing. Jul 13 at 0:33
• Very quick, within a second. Firefox 104.0a1. Jul 13 at 0:36

Writing inline code which contains backticks in the old editor used to be really annoying, so I still instinctively default to writing HTML, like this:

<code>&#96;</code>


When I write that into the Markdown mode of the new editor, then switch to Rich mode, it displays correctly:

but then when I switch back, it gets converted into completely broken markdown:

<code>  </code>


This does not render correctly; it looks like:

 



• The way I've been writing backticks within inline code in the new editor is by wrapping the desired text with double backticks like this  this has  single backtick .
– Tyler McEntee StaffMod
Jul 13 at 13:24

### Multiple leading spaces render as spaces in rich-text mode, but turn into a code block when pasted or after a round trip through Markdown mode

Honestly, I'm not sure what the best way to fix this is. Non-breaking spaces, maybe?

• I am thinking that once you add 4 leading space, it should automatically become a code-block. Thoughts?
– Yaakov Ellis StaffMod
Jul 14 at 11:46
• @YaakovEllis That certainly solves the problem, but I'm not sure it's a useful feature in its own right (other than not having to remember the shortcut for a code block). It may also introduce other problems. If a user isn't expecting it, they'd probably try to backspace to undo whatever they just did. It's maybe also worth considering what would happen if you did it to the line after a code block - should it add it to the code block or just make a new one? Should that depend on whether the code block is fenced or indented? Jul 14 at 13:16
• I think it comes down to a philosophy question of whether you want the user to understand that they're editing Markdown (so 4 spaces = code block) or if it's just a normal rich-text editor that happens to serialize to Markdown (so 4 spaces = 4 spaces, and you should try to preserve what the user typed, such as with non-breaking spaces). Of course, the latter approach then raises the question of what to do if the user types multiple spaces elsewhere in a line. I think I personally lean slightly toward "spaces in a rich-text editor are just spaces", but reasonable minds may disagree. Jul 14 at 13:17
• I hear you. Spaces in RT should just be spaces. But then round-tripping leads to the obvious: "what do we do with these 4 leading spaces now" issue, which could end up being a wont-fix, since the fix isn't really obvious or intuitive. And switching them into non-breaking spaces is also not so great, since that is also changing their input.
– Yaakov Ellis StaffMod
Jul 14 at 13:19

### Pasting Markdown into the Markdown editor causes it to be surrounded by code fences.

While it's quite useful that pasted source code is auto-fenced, this should not happen if the source is Markdown. It's not uncommon to compose longer or more complex posts outside the site (or to periodically copy their source out as a "backup"). Pasting the source should have the correct result.

To reproduce, copy the source of this question (I used revision 2) into an answer.

• The text you copied is wrapped in a pre, hence the reason why the editor interpreted it as code. Jul 13 at 6:32
• This is reproducible regardless of the source of the copied text. I reproduced it copying from: 1) the old editor, 2) the source link in the revisions list, 3) the new editor, 4) Visual Studio Code on Windows. Jul 13 at 8:02

### Removing code-block formatting results in broken state

Let's say I have text that is a mix of code and text. I paste it in, and it's detected as a code block. That's reasonable so far: it did contain code. The problems occur when trying to fix it after removing the code block:

1. Selecting a portion of the text that was in the code block and clicking the code block button results in the entire text that was previously in the code block being converted back into a code block, rather than only the selected portion. This works correctly when the text in question has not previously been a code block.

2. Typing anything into the text that was previously a code block causes all line breaks to be immediately removed.

• @YaakovEllis re: "status-bydesign for code block function removing the code block for the entire code block." I expected that part. The unexpected part is that after removing it, I cannot select only part of the text that was previously in the code block to add a new code block. Jul 14 at 13:44
• I have updated the GH issue to make note of that (I suspect that it is the same underlying issue, so keeping them together there).
– Yaakov Ellis StaffMod
Jul 17 at 7:36

### Code blocks in numbered lists render incorrectly, and are further broken by toggling Markdown mode on and off

To reproduce, create a post with this content:

You can solve this in the following ways:

1.     println("Hello, world!")

2.     System.out.println("Hello, world!")


The correct rendering of this, as shown by the old editor, is:

The new rich-text editor initially renders the code blocks on a new line from the number (but still correctly indented). When Markdown mode is turned back on, it has moved the items onto new lines. When it is switched back to rich-text mode a second time, the indentation is now lost.

• This is the same issue as described here: meta.stackexchange.com/a/380344/513150 Jul 13 at 14:09
• @Justin I dont think that that is the same. Here is a specific scenario with list items. And that is with indented code blocks.
– Yaakov Ellis StaffMod
Jul 14 at 13:05
• @Yaakov: The issue is the same in the sense that adding indented code or code blocks (and headings, blockquotes, etc.) on the same line as the numbered or bullet point is not possible. Switching between modes just shifts the formatted text on a new line. Jul 14 at 14:11
• @Justin you will notice that I put them in the same GH issue
– Yaakov Ellis StaffMod
Jul 14 at 15:12

### Ctrl + Shift + Z is undo instead of redo...unless there are no more items to undo

I would expect this to behave identically to Ctrl + Y (redo), as it does everywhere else (Firefox 104.0a1 on Windows 10). At any rate, it certainly should not sometimes undo and sometimes redo.

• Same behaviour with ⌘ Cmd + Shift + Z on Chrome 103.0.5060.114 on macOS Monterey. So not OS or browser specific. Jul 14 at 4:34
• sigh One of my continuous frustrations with the existing editor is that SE has chosen to (poorly) implement their own "undo" feature and override the browser/system based ctrl-Z/ctrl-Y behavior. IMO, the browser/system based undo is what should be used. It's what users are expecting to happen, because it's what happens everywhere else in all the other applications they are using, even in other places on the site. Jul 14 at 15:48

Bibliography style hyperlinked image Markdown is partially broken when toggling Markdown:

[![Profile Picture][1]][1]

[1]: https://i.stack.imgur.com/VOU20s.png


Becomes:

[![Profile Picture](https://i.stack.imgur.com/VOU20s.png)][1]

[1]: https://i.stack.imgur.com/VOU20s.png


GIF:

I use the code button really often to indent and unindent things, but that doesn't work in the new editor. It usually adds backticks instead. Can there be a button to indent and unindent on code sites?

You can try to edit this post.

## Block 1:

Try and format this not as code
Try it!


You can, but it's not intuitive because the one button (first <>) is disabled and you have to use preview mode. The fact that there is a second button to do code is not obvious.

## Block 2:

            Really indented


This appears to work but only as long as you remain in preview mode.

## Block 3:

This is indented enough
This is indented too much
Try and make it match the first line


You can't fix code that has bad indentation like above.

• I completely agree that having an indent button would be helpful; that said, hopefully, when the code button finally starts adding fences instead of indents, we won't have to fix the indents on most posts anymore, because they'll be using fences to begin with (One can dream, at least). Jul 12 at 18:21
• This was already requested in this post with a less explicit example. Jul 12 at 19:56
• @zcoop98 No matter what they do, it's still useful for old posts and posts that have horrible indentation inside the code fence. Jul 12 at 19:58

Adding a [code block / heading / blockquote / table] on the same line as a [bullet / numbered] point is not possible in the new editor.

In the rich text view, the buttons are disabled when trying to do so:

When adding the [code block / heading / blockquote / table] on the same line as the [bullet / numbered] point in the Markdown view and switching to the rich text view, the formatted text is rendered on a new line rather than on the same line as the [bullet / numbered] point:

Comparison with the old editor for reference:

• Table:

• Blockquote:

• Code block:

In the rich text view, editing an image link or image text in the "Edit image" dialog box works, but dragging to select text in any of the sections in the dialog box is not possible. Instead, it drags the entire dialog box as if the dialog box itself was being treated as an image (if you notice, dragging the dialog box also drags the (unicorn) image).

Workarounds to select text in any section:

1. Keyboard shortcuts Ctrl+A or Shift+ / .

2. Double/triple click on the desired text.

#### GIF for reference:

• I think it isn't supposed to have "text dragging". The text in those 3 fields can be copy-pasted but where would you drag it to? The 3 fields don't have much usefulness outside of the picture they're part of. Jul 14 at 20:56
• @bad_coder: I didn't mean literally dragging the text. I meant dragging to just select the text (so it can be edited, copied, etc.). Jul 15 at 5:49
• That follows the usual UX after you apply copy-paste the selection, It's not a good idea to have the UX turn drag&drop into a copy-paste because you'll risk loosing the clipboard. Jul 15 at 7:06
• @bad_coder: I really don't understand what you're talking about.. The bug report is simple: Dragging to select the text is not possible in the dialog box. Have you tried selecting the text by dragging your mouse over the text? Jul 15 at 7:18
• Trying to drag to select some text ends up dragging the entire dialog box as if it were being treated as an image. Jul 15 at 7:20
• No it doesn't. At least in Firefox if you select the image you can drag&drop, in the gif you aren't selecting the image just clicking on it, so the UX is correct. Jul 15 at 7:25
• I'm not clicking on the image, rather the popup that shows up. And I'm not clicking at all. Rather, I'm trying to drag my mouse over, for example, the text in the Image description section. But it's not working because the popup seems to be attached to the image; dragging the popup also drags the image. I don't know of any popups on this site that act in this way. Jul 15 at 7:29
• What system are you doing this one? It works for me on PC with Firefox. Jul 15 at 7:34
• On Chrome (latest version), Windows 11. It would be helpful if you could provide a GIF. Jul 15 at 7:35

Markdown display does not consider escaped * or _ when displaying text in italics

Markdown:

Markdown view shows **bold** and *italics*, however it doesn't consider escaped \* all of this is now displayed in italics even though the "\*" was escaped. Now notice we are no longer in italics because of the final escaped asterisk. This also applies to "\_" escaped underscores... Switching between modes does not resolve this.


The Markdown View Looks like:

How it renders:

Markdown view shows bold and italics, however it doesn't consider escaped * all of this is now displayed in italics even though the "*" was escaped. Now notice we are no longer in italics because of the final escaped asterisk. This also applies to "_" escaped underscores... Switching between modes does not resolve this.

Standard HTML (when used to add different heading levels in the header of a table) does not render properly in the rich text view. Moreover, switching back to Markdown completely destroys the table:

It only renders the HTML after posting the answer (provided you've not switched back to Markdown before posting).

Test:

# right

Compare with the old editor (the HTML is properly rendered in the preview):

Also reported in this answer to Opt-in alpha test for a new Stacks editor.

• Tables don't behave nicely with previews already, might be either an existing bug or related to one? Jul 13 at 10:24

Highlighting a line of backticks  and trying to turn it into block code produces broken markdown:

Correct ways to format block code which contains three backticks would include:

1. Using four backticks




1. Using tildes
~~~

~~~

1. Using indentation