project name updated, now ready for updated patch

Possibly (?) related discussion at https://github.com/codemirror/CodeMirror/issues/4076

Unassigned, until work resumes on the feature.

Yeah, that works for now. Thanks.

In T170042#3446655, @DannyH wrote:

Schnark, good catch on the semicolon -- that should be the same blue as the colon.

But why is there a gray background behind the colon? I'm looking at it with Niharika, and we think that's a bug. I don't think there's supposed to be a background like that...

In T170067#3437773, @kaldari wrote:

#777 is almost indistinguishable from black, especially for someone with bad eyesight. What do most IDEs use? Mine uses #ae88c0 (a light purple), which also fails the contrast test.

We need to keep in mind here that the primary goal is to make different kinds of content distinguishable from each other. People with bad eyesight should stick with the default editor as that is going to be most legible. I imagine that at least half the colors in CodeMirror fail the contrast test as most colors are not high contrast against white (basically only black, purple, and blue). If we limit ourselves to only black purple and blue, however, we are throwing the baby out with the bathwater.

Done. Plus I split up the To do list, so that adding/removing new items won't invalidate the whole block. :-)

Yes, with a clean test account, but I've narrowed it down:
This is only a problem if "Automatically enable all new beta features" is also checked.
Plus it effects most other BetaFeatures, such as "New filters for edit review", but not all BetaFeatures (at testwiki, the exceptions are "Page previews" and "New wikitext mode". I'll accordingly remove the CodeMirror tag here.

Confirmed. Looks good at https://en.wikipedia.beta.wmflabs.org/w/index.php?title=User:Quiddity/sandbox&oldid=363971&veaction=edit
Thanks!

For colors, I'd suggest either duplicating the existing -indenting scheme:
.cm-mw-indenting { color: #08f; font-weight: bold; background-color: #ddd; }

I made a semi-related linkdump at https://www.mediawiki.org/wiki/User:Quiddity_(WMF)/Hubs_and_docs - please feel free to merge that here, or adopt/overhaul/move/ignore/etc that page, as you wish.

One suggestion in the thread I linked above:

My main objection is that the side effects are not mentioned and come as a surprise. Now that they are known they can be listed where one makes the choice.

Fresh report of frustration, particularly around use-case #3 which is very hard for any recipient to understand, at https://en.wikipedia.org/wiki/Wikipedia_talk:Notifications#Spurious_notifications
(Basically, the link update here, is causing notifications for this edit (and many many others))

Note: This would only be possible to fix for the users that have set the preference "Send me" to the values "A daily summary [...]" or "A weekly summary [...]".
I believe (?) the default is "Individual notifications as they come in", i.e. instant emails and web-notifications sent at the same time.

A) I strongly support the general idea (and I've used the Russian or English gadget for many years) -- it would be great to make this feature more efficiently implemented, and more widely available via CSS wrap. (The gadget is the ~30th most popular on the Wikipedias, per https://meta.wikimedia.org/wiki/Gadgets/wikipedia )

Thanks x2. I'll resolve this.

In T30856#3393320, @NickK wrote:

[...] For me the three options are:

• old toolbar: click on a button, type page name (one click)
• new toolbar: click on a button, type page name, click on another button in another part of the screen (two clicks and one mouse move) I wouldn't mind switching to a new toolbar if there was a way to have exactly the same set of buttons without dialog boxes: I am not that attached to the blue colour, but I do not want to see that dialog box each time I need to add a link. Is there a solution for that?

In T53736#3387626, @Nirzar wrote:

@Tgr I will take a look. we did some work around redirect notice using toast messages for mobilefrontend.

In T53736#3386679, @Tgr wrote:

[...] And the UX is broken in multiple ways

In T119681#3390022, @Aklapper wrote:

Is this only about the edit summary of pages? If so, wondering if this might be a sub-project of MediaWiki-Page-editing

In T119681#3385538, @Liuxinyu970226 wrote:

@Quiddity Shouldn't we create #MediaWiki-Edit-Summary instead?

I've updated the details in the task description, just to give clarity and confirmation on all the above discussion. Thanks.

Could you give an example link, or screenshot? I can't see that line given in any examples. (I checked a dozen, with a variety of creation-dates from the beginning and end of the newpagesfeed.)

Marking as resolved. Seems to be fixed (per comments above).

@CKoerner_WMF, @Trizek-WMF , and I, can probably do the notes again.

Perfect, thanks all!

I've added docs at https://www.mediawiki.org/w/index.php?title=Extension:InputBox&diff=2493340&oldid=2467274 (please always remember to add docs, for new features! Thanks!)

In T54905#3354372, @Izno wrote:

@Quiddity The task for that is T143310: Implement a way to access keywords such as "incategory", "intitle" via the Search special page.