A more comprehensive idea: generate those section links asynchronously post-save instead of as part of the summaries.

I'd also like to state for the record that I was flabbergasted to find this was intentional and not a bug. And I would be equally astonished if any user could look at the current toolbar and go, "Oh, the blue background on the first icon means syntax highlighting is turned on, but the blue background on the second icon is for emphasizing that those settings exist. Obviously."

Do the developers of Firefox (Mozilla et al.), and the developers of browsers in general, have an obligation to maintain the way they deal with invalid code? Even if there is some informal understanding or tendency to do so, it seems like a precarious and untenable position to rely on said behavior.

In T427053#12265040, @pmiazga wrote:

IMHO - the issue is on Firefox side and they should fix it

Can you elaborate? Why is it incumbent on a browser to behave a certain way when it encounters something the HTML specs prohibit?

So is the exclusion still not implemented? Or has the default behavior changed so that a search doesn't cover redirects unless prefixed with withredirects:?

Will it be possible to sort descending (newest to oldest)?

Since I can't make it happen, would you mind trying to paste that content into https://en.wikipedia.beta.wmcloud.org/wiki/Cats?veaction=editsource (where the fix is definitely present) and tell me whether it's fixed there for you?

Invalid HTML causing unexpected behavior should not be considered an upstream issue.

If you copy the example barnstars from https://en.wikipedia.org/wiki/Wikipedia:Barnstars then the wiki-markup like { is wrapped by parsoid in <span typeof="mw:Entity">, which VE strips, resulting in an incorrect paste rather than the ticket-description's no-paste.

In T431137#12134782, @cscott wrote:

Seems like Cite shouldn't be emitting an error here when ParserOptions::isPreview() is true?

@stjn You seem to have misinterpreted what I said. The bug is reproduced only when Parsoid is used for the preview.

Yep. The bug is reproduced when you click the button label, but it works if you click on the button outside the label. Because in the former e.target.name is not wpDiff.

Identicon, which is used on Stack Overflow/Exchange, presents a viable alternative IMO, whether it should be used as-is, tweaked, or something similar built from scratch.

I think y'all are overthinking this. The function of the move feature is already to rename a page. We can swap the current icon for literal and call it a day as far as this task is concerned.

@Ladsgroup T294188: The icon for "Move" is far from intuitive

Was this only tested in Vector 2022? T428988: MinT translates the wish title only in Vector 2022 static heading

@EAkinloose Did you mean to claim this?

I've noticed that [[#|foo]] in wikitext still becomes a link to //[domain]/wiki/. I find this unexpected because if you can link to a certain place in an edit summary, it's natural to assume you can in wiki content too.

Couldn't any of the global interface editors just do it?

Somewhat related: T294188: The icon for "Move" is far from intuitive

I would recommend this be declined. data-sort-value exists precisely for this kind of situation.

@MusikAnimal Thanks!

Vector 2022 is updated to generate icon CSS using mw.util.addCSS

Are the votes that have been removed before the patch for this went live going to be restored?

It doesn't work the way I expected. The selection happens on mouse up, not down, so it's impossible to drag the selection and expand it to lines above or below.

In T130134#9571174, @thiemowmde wrote:

Sounds like this is effectively the same issue as T130888: Category addition/removal should be displayed in the watchlist independently of further edits on articles?

Different issue I'd say. This is about making it possible to subscribe to non-H2 sections.

Done: T420555: Triple-clicking on brackets should select the block of code

Too bad a third click doesn't select the entire lines. I found that quite handy in CodeEditor.

Merging the votes but also pinging the users will also allow them to retract it from the target wish in case they disagree with the target wish. Wouldn't that be enough @FonAfon?

You're not echoing my point. I was talking strictly about when the wish being closed and the wish it's being merged into both already have a support vote by the same user. It's a no-brainer to transfer the votes by users who have not voted for the target wish.

I imagine there should be consideration on which should be kept if the same user has voted for both wishes. I'd say don't transfer the vote for the closed one if it has no comment, and do if it does and the vote for the non-closed one doesn't. The question remains what to do if both have comment (and they differ). don't transfer the vote at all, given the two wishes may not describe the completely identical problem/request.

OK, I'll defer to @MusikAnimal. It is my opinion that it defies ASTONISH to go against most other editors, including Notepad, TextEdit, Vim, VSCode, Sublime, Notepad++, and gedit.

That Ace/CodeEditor did something poorly is a terrible excuse to continue doing it that defeats the whole point of replacing it. Name an editor besides Ace that considers the initial caret position to be line 1 but column 0.

Thanks for working on this! I've filed the related issue mentioned above as T418975.

Resubmitted original issue as T418345: Columns start at 0, not 1.

The caret is already blinking at the first position, so I doubt that. I don't know of a text editor whose status bar says "line 0, col 0" after opening a blank tab.

Still happening (note the removal of the votes at 2024-09-15T09:41:33.091Z, 2025-06-26T13:23:19.559Z, and 2025-07-02T17:57:40.216Z).

Video added in case it wasn't clear. (ETA: Replaced for clarity.)

Why? Why does the whole page need to change its scroll position instead of just inside the editor?

Has rECMI34d8c5eedca5: CodeMirrorSearch: allow native Ctrl-F to work when focus is on search been a solution, or at least a mitigation?

@Jdlrobson So you're not proceeding with your proposal, which I said is still an improvement to the status quo?

Fixed upstream: https://github.com/codemirror/dev/issues/1668

That's still an improvement to the status quo, isn't it. It does sound like allowing, if not requiring, specifying a class or classes when registering an "associated navigation link" would be a more robust approach, however.