57

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 .


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?

Roadmap

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:

  • 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):

  • 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

We will be monitoring this post for responses until the end of July 2022. If you have feedback, bugs to report, or feature requests, please post them as an answer under this question — with one issue per answer. Please make sure what you’re posting here hasn’t been posted already, and do not report issues in comments. Please provide steps needed to reliably reproduce a bug, along with which browser/s you're experiencing the bug in. If an issue on the Alpha Release post doesn't have a link to an active case on GitHub (GH) feel free to repost here and link to the original in the report. If it does have a link to an active case it is being worked on so there is no need to repost here. Additionally, since this is an open-source project, you can also use the GitHub repo for the editor to submit new issues if you feel comfortable doing so — we'll cross-link stuff reported here and in the GH repo. As mentioned above, you can also use the repo to check out the issues still scheduled for work. After July 2022, issues should be reported as separate questions tagged .

7
  • 2
    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
  • 11
    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
  • 10
    @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
  • 1
    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
  • 2
    @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
  • 1
    @ArcanisGK507 we don't have plans for custom font support in the code editor.
    – Yaakov Ellis StaffMod
    Aug 7 at 13:41

69 Answers 69

30

Summary of bugs / feature requests posted as answers

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

Type Summary Status GitHub
License written in lower case
Too much space between "Draft saved" / Community wiki checkbox and bottom edge
Markdown display does not consider escaped * or _ when displaying text in italics #21
Preview does not support lang-* notation for syntax highlighting specification #21
Headings are not always shown as headings in Markdown mode #21
Blank lines are removed when switching modes #152
Switching modes causes links to be sorted in wrong order #163
Inserting an image never works the first time #167
Switching modes combines adjacent code blocks added in rich text mode #168
Undo/redo buttons always look enabled #172
Bibliography style hyperlinked image Markdown is partially broken when toggling Markdown #188
No room for contents in the image uploader while editing on mobile #202
Misplaced link edit tooltip after cancelling #193
Bare links in a list (in the rich text view) are prefixed with a loading spinner on MSO
Tag markup with disallowed characters is incorrectly rendered as a valid tag in the rich text view #201
Weird behaviour when using the inline code button multiple times
Weird behaviour with quotes and source fences #70
Copying text from one list bullet to another inserts the pasted text as a new sub-bullet #164
Heading button's tooltip (Ctrl-h) is hidden by the list of heading options #169
Weird behaviour when dragging to select a link in the rendered view #170
Heading disappears when applying blockquote #171
Switching modes has problems with asterisks #173
Pasting Markdown into the Markdown editor causes it to be surrounded by code fences #174
HTML comments disappear when switching modes #175
Cursor gets stuck after inserting link #178
HTML backtick entity is incorrectly converted when switching modes #180
Code blocks in numbered lists render incorrectly #181
Adding a [code block / heading / blockquote / table] on the same line as a [bullet / numbered] point is not possible #181
Standard HTML does not render properly in the rich text view #183
Quoting table removes leading pipes #185
Triple backticks can't be wrapped in source fence #186
Ctrl+Shift+Z is undo instead of redo... unless there are no more items to undo #187
Only one table can be deleted at a time when trying to delete multiple tables at once #189
Dragging to select text in the "Edit image" dialog box is not possible #190
Pressing the down arrow key in a code block with multiple lines moves out of the code block #191
Inserting a horizontal rule in Markdown mode makes the previous line a header #192
Various oddities occur when a numbered item is a child of a bulleted item #194
HTML comment inserts blue bar on top of post in rich text mode #195
Adding a link to text with a space at the end causes the space to be included in the link text #196
No way to escape source fence at beginning of post #197
In rich text <hr> doesn't have selection highlight #198
Moving cursor over <hr> pushes it down in rich text mode #199
In rich text, selecting blocks moves edit image dialogue #200
Cursor disappears in long posts #206
RT mode weirdly displays content made from HTML paragraph and HTML comment tags #207
Tags should be automatically rendered when first typing it in the rendered view #51
Applying a [numbered / bulleted] list to multiple lines works differently in each mode
Pressing italics on bold text removes bold
Only one spoiler can be revealed at a time in the rich text view
Bolded message in Markdown is already bolded
Placeholder text in edit summary is missing a bracket for mobile users
Removing code-block formatting results in broken state #179
Imgur logo not aligned with preceding text
Switching modes destroys the undo/redo stack
Multiple leading spaces render as spaces in rich-text mode, but turn into a code block
Update the Alpha label to the Beta label in the Preferences tab
Improve keyboard shortcut capitalization #166
Code button should indent/unindent things #50
Make the resize tool more (visually) accessible #101
In rich text mode, either help icon should not direct to markdown help or help page should mention both rich text + markdown
Inconsistent header levels #165
Allow saving edits to a post using with Ctrl+Enter #205
We should be able to drag the question right above the answer
Consider not including the strikethrough button
Capitalize syntax highlight language to source code fence
Sort reference's numbering by order of appearance in post
Add a visual formula editor as an editor feature
When will the editor be activated for questions?

Notes

Credits

Original idea: here, further refined here and here.

Updates

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 gitHubLinkRegex = /\/\/github.com\/\S+\/issues\/(\d+)/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?
      let answerID = item["answer_id"];
      if (answerID == summaryAnswerID)
        continue;
      
      // Present in summary?
      var currentLine = null;
      for (let line of lines) {
        if (line.search(new RegExp('/a/' + answerID + '[/)]')) != -1) {
          currentLine = line;
          break;
        }
      }
      
      // Analyze answer
      let markdown = item["body_markdown"];
      let typeTagMatch = typeTagRegex.exec(markdown);
      let summaryMatch = summaryRegex.exec(markdown);
      let statusTagMatch = statusTagRegex.exec(markdown);
      let gitHubLinkMatch = gitHubLinkRegex.exec(markdown);      
      
      if (currentLine == null) {
        // Generate new entry
        let title = summaryMatch == null ? "(please add summary)" : summaryMatch[1];
        let summary = "[" + title + "](/a/" + answerID + ")";        
        linesToAdd.push(generateLine(typeTagMatch, summary, statusTagMatch, gitHubLinkMatch));
      } 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());
        changeNeeded |= gitHubLinkMatch != null && (gitHubLink == null || gitHubLink[1].toLowerCase() != gitHubLinkMatch[1].toLowerCase());
        if (!changeNeeded)
          continue;
        
        linesToChange[currentLine] = generateLine(typeTagMatch, summary, statusTagMatch, gitHubLinkMatch);
      }
    }
    
    // Any more answers?
    if (!result["has_more"])
      break;
  }
  
  // Changes needed?
  if (linesToAdd.length == 0 && Object.keys(linesToChange).length == 0) {
    alert("The summary is up-to-date.");
    return;
  }  
  var messages = [];
  if (linesToAdd.length != 0) {
    messages.push("\nThe following lines need to be added:");
    for (let lineToAdd of linesToAdd) {
      messages.push(lineToAdd);
    }
  }
  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"));
  alert("Changes needed, please check the console for details.")
}
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] + "]");
  if (gitHubLinkMatch != null) {
    components.push("[#" + gitHubLinkMatch[1] + "](https:" + gitHubLinkMatch[0] + ")");
  }
  components.push("");
  return components.join(" | ").trim();
}
<script src="https://code.jquery.com/jquery-1.11.1.min.js" type="text/javascript" ></script>

2
  • 4
    @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.
    – Justin
    Jul 23 at 17:16
  • 1
    The snippet doesn't render as a snippet when using the new editor, just plain code (it removes the <!-- language: lang-[html/js] --> block upon posting or switching between modes). I fixed the snippet by switching back to the old editor.
    – Justin
    Sep 3 at 14:16
41

GH #163 Commit 20f338a

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

Screen recording of numbered links being reordered from the correct order to 1, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 2, 20, 21, etc.

2
28

GH #164

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

Screen recording demonstrating the above-described bug

2
  • 4
    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.
    – Ryan M
    Jul 12 at 14:34
  • 1
    Also reproduced on Firefox on MacOS, cc @YaakovEllis
    – Luuklag
    Jul 13 at 10:07
24

GH #167

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.

A screen recording of an image file being dragged onto the Stacks editor, resulting in a blank image upload dialog.  Once it is canceled, the process is repeated, and it shows the thumbnail properly.

4
  • 4
    Also reported as a separate post here: New Stacks Editor doesn't let me upload images at first try
    – Justin
    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.
    – Luuklag
    Jul 12 at 19:41
  • 12
    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
21

GH #168

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

Screen recording of two adjacent code blocks shown in rich-text mode, then Markdown mode is toggled on and off, and they are combined into one

5
  • Wasn't this, or something very much like this, fixed in the original alpha release?
    – ouflak
    Jul 12 at 15:03
  • 10
    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
  • 3
    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.
    – bad_coder
    Jul 13 at 10:49
  • 4
    @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.
    – Makyen
    Jul 14 at 14:43
20

GH #166

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

enter image description here

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:

enter image description here

6
  • 5
    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
  • 24
    @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."
    – Andrew Ray
    Jul 13 at 13:13
  • 1
    @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).
    – Flimm
    Aug 3 at 8:20
17

GH #165

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

enter image description here

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

enter image description here

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.

4
  • 8
    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.
    – Ryan M
    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
  • 6
    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.
    – Ryan M
    Jul 13 at 8:07
  • 6
    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.
    – Andrew Ray
    Jul 13 at 13:06
15

GH #169

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

Overlap

15

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

enter image description here


Compare with the old editor:

enter image description here


[Chrome (latest version) for Android and Windows (11)]

3
  • 1
    @Yaakov no GH entry for this one? (Asking because it's in status planned.) Jul 14 at 15:29
  • 3
    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
  • 3
    We fixed this issue in the newest version of stacks editor. We hope it helps!
    – marrados Staff
    Sep 14 at 12:50
14

GH #170

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

enter image description here


[Chrome (latest version) on Windows 11]

13

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

first press inline code button

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

second press inline code button

  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.

10
  • 3
    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
  • 1
    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?
    – bad_coder
    Jul 13 at 11:51
  • 1
    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
  • 1
    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.
    – bad_coder
    Jul 13 at 12:00
  • 3
    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.
    – bad_coder
    Jul 13 at 12:43
  • 2
    @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
  • 2
    @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.
    – bad_coder
    Jul 13 at 13:19
13

GH #171

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:

enter image description here


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

13

GH #172

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

Undo/redo in black

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).

11

GH #173

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

enter image description here


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

11

GH #51

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

enter image description here

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

enter image description here

It only renders after posting the question / answer.

1
11

GH #178

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.

enter image description here

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

GH #175

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.

3
  • 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.
    – Ryan M
    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.
    – Laurel
    Jul 13 at 0:33
  • Very quick, within a second. Firefox 104.0a1.
    – Ryan M
    Jul 13 at 0:36
10

GH #180

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:

screenshot of the new rich editor, showing an inline code element containing a single backtick

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

<code>` ` </code>`

This does not render correctly; it looks like:

`

instead of

`

1
  • 3
    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
10

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?

Screen recording of adding spaces to the start of a line, copying that line further into the post (resulting in a code block), then toggling Markdown mode on and off to turn the first one into a code block as well.

4
  • 4
    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
  • 1
    @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?
    – Ryan M
    Jul 14 at 13:16
  • 3
    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.
    – Ryan M
    Jul 14 at 13:17
  • 1
    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
9

GH #174

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.

Screen recording of Markdown being pasted into the Markdown editor, resulting in 3 backticks shown above it (they are also below it, but this is not captured). A switch to rich-text mode shows that it is rendered as a code block (auto-detected as VHDL)

2
  • 1
    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.
    – Ryan M
    Jul 13 at 8:02
9


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.

Screen recording of the above described bug, reproducing bug 1 first, then bug 2

2
  • @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.
    – Ryan M
    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
9

GH #181

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 above post rendered with the code blocks in-line with the numbers

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.

Screen recording of the above-described bug

4
  • 2
    This is the same issue as described here: meta.stackexchange.com/a/380344/513150
    – Justin
    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.
    – Justin
    Jul 14 at 14:11
  • 1
    @Justin you will notice that I put them in the same GH issue
    – Yaakov Ellis StaffMod
    Jul 14 at 15:12
9

GH #187

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.

A screen recording of "Testing" "One" "Two" being typed each on one line.  Then "One" and "Two" vanish, and "Testing" begins flashing

2
  • 3
    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.
    – Makyen
    Jul 14 at 15:48
9

GH #21

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: Image of markdown view of the above text

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.

9

GH #188

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

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

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

Profile Picture

Becomes:

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

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

GIF: GIF of a hyperlinked image with bibliography style link markdown becoming partially inline linked and partially bibliographically linked

8

GH #50

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.

3
  • 2
    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).
    – zcoop98
    Jul 12 at 18:21
  • 1
    This was already requested in this post with a less explicit example.
    – bad_coder
    Jul 12 at 19:56
  • 3
    @zcoop98 No matter what they do, it's still useful for old posts and posts that have horrible indentation inside the code fence.
    – Laurel
    Jul 12 at 19:58
8

GH #181

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:

enter image description here

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:

enter image description here


Comparison with the old editor for reference:

  • Table:

    enter image description here

  • Blockquote:

    enter image description here

  • Heading:

    enter image description here

  • Code block:

    enter image description here

0
8

GH #190

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:

enter image description here


[Chrome (latest version) on Windows 11]

9
  • 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.
    – bad_coder
    Jul 14 at 20:56
  • 1
    @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.).
    – Justin
    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.
    – bad_coder
    Jul 15 at 7:06
  • 1
    @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?
    – Justin
    Jul 15 at 7:18
  • 1
    Trying to drag to select some text ends up dragging the entire dialog box as if it were being treated as an image.
    – Justin
    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.
    – bad_coder
    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.
    – Justin
    Jul 15 at 7:29
  • What system are you doing this one? It works for me on PC with Firefox.
    – bad_coder
    Jul 15 at 7:34
  • 1
    On Chrome (latest version), Windows 11. It would be helpful if you could provide a GIF.
    – Justin
    Jul 15 at 7:35
7

GH #183

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:

enter image description here

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

Test:

left

right


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

enter image description here


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

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

GH #186

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

enter image description here

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

  1. Using four backticks
````
```
````
  1. Using tildes
~~~
```
~~~
  1. Using indentation
    ```

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .