Change #1015469 had a related patch set uploaded (by Novem Linguae; author: Novem Linguae):

[mediawiki/extensions/SyntaxHighlight_GeSHi@master] Add <sh> and <shi> parser tags

https://gerrit.wikimedia.org/r/1015469

Would also be great to get help with why my patch's 8 new parser tests pass locally when running the command docker compose exec mediawiki php tests/parser/parserTests.php --file=extensions/SyntaxHighlight_GeSHi/tests/parser/parserTests.txt, but 3 of the 8 tests fail in Jenkins.

https://integration.wikimedia.org/ci/job/quibble-vendor-mysql-php74-noselenium-docker/165698/consoleFull

Personally i was a fan of <source>....

putting pressure on folks to always add lang="abc" to <syntaxhighlight> tags

Without a language you are using <pre> which is pretty close to your desired short code tag length.

In T361407#9674162, @Bawolff wrote:

Personally i was a fan of <source>....

T39042: Remove <source> syntax from SyntaxHighlight (GeSHi)

I would not oppose declining this in favour of also declining that.

more industry standard

I don't disagree with the sentiment that there are widely used pseudo-standards for code documentation and these are often based on Markdown or borrow some Markdown syntax, but "industry standard" is a boring appeal to authority argument without even stating the authority you would wish to defer to. To my knowledge there is no well defined industry for the production and use of FOSS wiki software.

In https://gerrit.wikimedia.org/r/c/mediawiki/extensions/SyntaxHighlight_GeSHi/+/1015469/2#message-af7a885e798cc9cca3a95acc0472ede3c1632ece, @bd808 wrote:

Anecdotally I have spent more time that I care to recall over the course of my software development career pushing back on the idea that the number of characters in an identifier is a meaningful barrier to adoption of human readable labels. To my mind, the slight inconvenience of the number of keystrokes needed in this case is outweighed by the clarity of the tag's name being exactly analogous to the operation performed by the tag. The shorter "sh" and "shi" proposed aliases carry no semantic meaning without the longer "syntaxhighlight" label being presented in the same context.

Perhaps "highlight" could be seen as a meet in the middle compromise? I'm still not sure how to determine the actual need for such an alias however. It certainly would be easier to engage in a discussion of the topic if it was presented in the form of a Phabricator feature request task, a mailing list post, or a wiki page rather than a Gerrit patch.

In T361407#9674215, @bd808 wrote:

but "industry standard" is a boring appeal to authority argument without even stating the authority you would wish to defer to

A bit harsh. I was just trying to reference the other two tickets where backticks were suggested. Anyway, I'll edit my post to say "syntax that some people are already familiar with such as Markdown".

In T361407#9674204, @bd808 wrote:

Without a language you are using <pre> which is pretty close to your desired short code tag length.

Oh nice. I didn't know <pre> had nowiki built into it. I'll start using that, although I don't think it covers use cases where we want to specify a language such as <syntaxhighlight lang="js">. And I don't think it covers the one line/inline case.

<pre> is indeed processed in wikitext similar to many Markdown implementations, with "nowiki"-like treatment applied.

Another unofficial, but fairly common, feaure in Markdown implementation is support for <pre lang="js">. This works on GitHub, Gitiles, Doxygen, npmjs.org, and probably others. It'd be tricky to somehow work that into the SyntaxHighlight extension as it'd require replacing a core parser tag (or hooking into its callback), but not impossible.

See also: T251116

In T361407#9674209, @Krinkle wrote:

In T361407#9674162, @Bawolff wrote:

Personally i was a fan of <source>....

T39042: Remove <source> syntax from SyntaxHighlight (GeSHi)

I would not oppose declining this in favour of also declining that.

T39042#7084286 merits engagement if you want to go that path.

I actually think providing a short form of <syntaxhighlight> is great, but would personally rather not support the <shi> form. (And would prefer to see the triple back ticks supported for the block form, but I get why this task exists.)

I'm afraid I have to oppose as well. The syntax is 15 years old. Why change it? Why now? How often do people actually face the situation that they have to type it? How often will people have to decipher a cryptic <sh> in the wikitext? Isn't there always a way to add it with one or two mouse clicks? If not, why not? Won't it be copy-pasted anyway most of the time? Doesn't "sh" mean "shell (script)"? Or dozens of other things? In which other context does it mean "syntax highlight"?

Seems like there's lots of opposition to this.

I think I'll give up on the <sh> part of this ticket and just use <pre>.

But the inline stuff that <shi> would solve might be worth continuing to explore. Here's my use case (video):

Any ideas for what we can name <shi> that would achieve consensus and still be short?

<shi> combines a tag name (syntaxhighlight) with a boolean parameter (inline). That is even more confusing than the short tag name and should be avoided.

Somewhat of an opinion that <pre lang=""> and <code lang=""> should just function as synonyms to <syntaxhighlight> if the extension is installed. Or something similar to them (language or hlang to differ from HTML lang?). Yes, it is not ‘correct HTML’, but so what? As long as wikitext doesn’t insert the attribute into HTML, we’re fine, I’d say. And <syntaxhighlight> without any lang should be considered an error. (<source> to me is bad since it doesn’t say anything about what the tag does, even if it is less verbose.)

Change #1015469 abandoned by Novem Linguae:

[mediawiki/extensions/SyntaxHighlight_GeSHi@master] Add <sh> and <shi> parser tags

Reason:

objections in phab ticket

https://gerrit.wikimedia.org/r/1015469

Looks like the <pre> tag doesn't indent, making it much less useful on talk pages than <syntaxhighlight>.

Readability trumps writability, IMO. If you find it annoying to type <syntaxhighlight inline> or <code><nowiki> (me too), some ideas:

• Better editor support (a keyboard shortcut, or opening up a syntaxhilight dialog when you type ```).
• Introduce <syntax> or <highlight>, which isn't all that shorter, but easy to understand and doesn't conflict with HTML.
• Introduce a pseudo-namespace, like <mw:code>.
• Probably not feasible to do retroactively, but I wonder whether making <syntaxhighlight>text</syntaxhighlight> automatically inline iff text doesn't contain any newline would have made sense.
• We could create a parser tag for <code> or <source>, but have it just output the HTML tag unless some distinctive property is used. lang is also a HTML property though, so not the best candidate for that. Maybe something like format or type?
• Maybe the pre-save transform could convert <sh> and <shi> into <syntaxhighlight> / <syntaxhighlight inline>? That feels very hacky... also, not easy to do I think.

T311518: Add ``` as shorthand for <syntaxhighlight> would be cool if not very hard to do. I assume Linter could be used to weed out the few false positives?
(On the other hand, I doubt T217944: Support backticks (`) for code samples (as in Markdown) is feasible.)

In T361407#9674278, @Krinkle wrote:

<pre> is indeed processed in wikitext similar to many Markdown implementations, with "nowiki"-like treatment applied.

Another unofficial, but fairly common, feaure in Markdown implementation is support for <pre lang="js">. This works on GitHub, Gitiles, Doxygen, npmjs.org, and probably others. It'd be tricky to somehow work that into the SyntaxHighlight extension as it'd require replacing a core parser tag (or hooking into its callback), but not impossible.

Parser::setHook() just overrides the previous hook (and even gives you the old one as a callable), and ParserFirstCallInit runs after the core hooks are set, so that seems very easy to do. Confusing for editors though, because of the formatting/positioning differences between core <pre> and SyntaxHighlight blocks, unless plain (non-language-specific) <pre> is also taken over, which could cause issues with a lot of existing / historic code.