Extension talk:CodeEditor

Previous page history was archived for backup purposes at Extension talk:CodeEditor/LQT Archive 1 on 2015-07-10.

For example:

.mainpage-columns {
	gap: 0.5em; /* unknown property 'gap', but it is actually correct "/
	grid-template-columns: [begin] 1fr [end]; /* unexpected token but it is actually valid */
}
.mainpage-columns > div {
	padding-inline-start: 1em; /* unknown property but it is actually correct */
	padding-inline-end: 1em;
}

Besides, it seems that it cannot recognize CSS variables.

I also have an example of this problem:

@media ( min-width: 43em ) {
	body.skin-vector #frame-welcome {
		background-image: url("//commons.example.net/w/images/f/f0/Background-mainpage.png");
		background-repeat: no-repeat;
		background-position: -7px -57px;
		padding-left: 156px;
		/*background-size: 190px;*/
	}

}

We're based on Ace 1.15.2 (since February 2023); latest as of today is 1.23.4. Pasting your examples into https://mkslanc.github.io/ace-playground/#hello-world doesn't error but looking at the upstream release diff it's not obvious which version has those fixes, so I made a general task asking to update to latest.

@SolidBlock, @Sokote zaman: Heads-up that I've updated us to 1.32.7, which will ship to Wikimedia production this week and in MediaWiki 1.42.0 and later.

My version is 1.40.1. No matter which version of CodeEditor I install, when editing CSS or JavaScript, the search window cannot pop up, whether I press Ctrl+F or click the toggle button with the mouse. In addition, CodeEditor also blocks the browser's built-in search window, making it necessary for me to stay out of focus every time I search.

I've found out — it was all about Gadget, not this extension!

Pressing button "Edit" on [kinda] any page with CodeEditor enabled lead me to page with damaged view, where there are coloured spots above with no code (in front of big white square) and the code is below (in a window).

MW 1.39.1. I've updated all dependencies via Composer. Can anybody suggest the reason?

Probably, it's not CodeEditor, because problem repeats after its disabling.

Getting warnings on css cases that use "initial" as value.

>Warning: Expected (left | right | center | justify | inherit) but found 'initial'.

As far as I know "initial" is still a (global) valid CSS value.

Whether its a useful value ... the opinions on that seem divided.

Tested at test.wikipedia.org with Firefox(latest version).

When you select some text, in Linux(mint 20.3) and also the default mw-source editor, You can directly paste that(or last) selected text with a middle mouse button click.

This CodeEditor does not seem to support that feature. (at least not at the above site and used browser).

Think it would be really nice if this was also possible with this CodeEditor. (if possible of course)

Clearing user preferences enabled CodeEditor when logged in.

On my own MediaWiki 1.35 installation the CodeEditor extension does not work (downloaded the newest CodeEditor and WikiEditor packages).

Here, on MediaWiki.org all extensions are installed (Special:Version), same situation, CodeEditor not appearing if you try to edit CSS, JS or Module pages, like: https://www.mediawiki.org/w/index.php?title=MediaWiki:Vector.css&action=edit

If you check Wikipedia, CodeEditor is working there: https://en.wikipedia.org/w/index.php?title=MediaWiki:Common.css&action=edit One difference could be, VisualEditor is not enabled on Wikipedia in contrast to MediaWiki.org?

What is status of this extension, if it is not even working here, on the official site?

It's working just fine for me on mediawiki.org. What browser are you using ?

Using Chrome 106.x on Windows 10. New finding: the CodeEditor appears when I log out, but again not working while logged in. Now, I´ve reset my User Preferences bringing CodeEditor back to work(!).

Are there any settings/Gadgets colliding with the CodeEditor? As I still cannot figure out why it might not work on my own Wiki installation after updating.

This sounds like a user script or a gadget getting in the way yes. Easily confirmed by visiting https://www.mediawiki.org/w/index.php?title=MediaWiki:Vector.css&action=edit&safemode=1 which uses a flag to temporarily disable scripts and gadgets.

You might want to look at your browser's console for any errors. See Help:Locating broken scripts

CodeEditor magically reappeared on my Wiki installation, resetting User preferences and clearing the cache might have helped, not really obvious. Also there were no particular errors in debug console.

Thanks for the hints.

Now documented and fixable in css or js.

Hi, I added a custom booklet section to the WikiEditor toolbar. Unfortunately, when CodeEditor hides the default WikiEditor sections (advanced, characters and help), it additionally hides everything under the element with the "sections" class, which is exactly where WikiEditor has reserved space for booklet-related content (collapsed by default). Users can see the button on the toolbar, but the booklet itself remains hidden whatever you do. In order not to kill functionality, it seems best to be more discrete and just hide the specific booklets for the advanced, characters and help sections.

I just noticed that someone else had bumped into what appears to be the same issue: https://phabricator.wikimedia.org/T284791

An easy css fix would be to replace `.codeEditor-ui-toolbar .sections` in in jquery.codeEditor.less with `.codeEditor-ui-toolbar .sections .section-advanced, .codeEditor-ui-toolbar .sections .section-characters, .codeEditor-ui-toolbar .sections .section-help`.

I don't see a particular reason why only those 3 should be hidden. There is a chance that implementing it like that would cause posts here with "why is it not hiding my custom booklet"... For whatever is written, someone might just as much expect the opposite.

You can of course always just locally override any CSS.

I'm not sure why it should hide things like characters at all, but you're right that use cases differ from one wiki to another. Anyway, it's good to have this on record if anyone else bumps into the same issue (although I can't find the search feature for this issue board). Will close.

Hi everybody,

i have installed the extension, but it only works, when editing.

This means, if i use "insert codeblock" the syntaxhighlighting and linenumber is shown correctly. After saving there is no syntaxhighlighting, the linenumbers are not displayed and the wikipage is categorised in "pages with syntax highlighting errors".

The only thing, that is written on the page is:

<syntaxhighlight lang="python3" line="1" start="55">

def quick_sort(arr):

   less = []

   pivot_list = []

   more = []

   if len(arr) <= 1:

       return arr

   else:

       pass        

</syntaxhighlight>

Hey there, this is the talk page for the "CodeEditor" extension that provides syntax highlighting for certain code pages when you edit, as you say.

The syntaxhighlight feature, which shows syntax-highlighted code blocks in wikitext pages, is provided by Extension:SyntaxHighlight.

@Jdforrester (WMF): Thank you :)

The syntax check indicates "Warning: Too many errors. (81% scanned)" on the following code. When removing one "test1();", no error is reported anymore.

// syntax check demo: false positive error
function test1(){ return true }

function test2(){
test1();test1();test1();test1();test1();test1();test1();test1();test1();test1();
test1();test1();test1();test1();test1();test1();test1();test1();test1();test1();
test1();test1();test1();test1();test1();test1();test1();test1();test1();test1();
test1();test1();test1();test1();test1();test1();test1();test1();test1();test1();
test1();test1();test1();test1();test1();test1();test1();test1();test1();test1();
test1();test1();test1();test1();test1();test1();test1();test1();test1();test1();
test1();test1();test1();test1();test1();test1();test1();test1();test1();test1();
test1();test1();test1();test1();test1();test1();test1();test1();test1();test1();
test1();test1();test1();test1();test1();test1();test1();test1();test1();test1();
test1();test1();test1();test1();test1();test1();test1();test1();test1();
}

Yes, jshint is pretty poor. T250315 is a proposal to replace it with eslint which has much better behaviour in general, and might (?) fix your problem here, but some people are concerned that switching will change which "false positives" (and new true positives) are flagged. Your input would be welcome if you think this would fix it or otherwise be a good move.

I tested it again and the error appears to have been repaired. No syntax error is reported, even if I add multiple times as many test1(); as before. Thanks much!

Looks like the reason for this is browser compatibility.

For example, width: unset; and border: unset; cause a warning that reads "Expected … but found 'unset' ".

It is no major issue, since it does not refuse saving it, but the false error still needs to be removed at some point.