Extension talk:CodeEditor

Jump to: navigation, search

About this board

By clicking "Add topic", you agree to our Terms of Use and agree to irrevocably release your text under the CC BY-SA 3.0 License and GFDL

How to set the content of the textbox?

10
He7d3r (talkcontribs)

If I go to https://en.wikipedia.org/wiki/Special:MyPage/common.js?action=edit and type $('#wpTextbox1').val('NEWCODE') in the console:

  • The code is replaced by "NEWCODE" if CodeEditor is disabled
  • Nothing happens if CodeEditor is enabled

What should be used to set the content of the textbox if CodeEditor is enabled? I know from en:Special:Diff/617061684 that we can get the contents by using

  • $( '#wpTextbox1' ).data( 'wikiEditor-context' ).$textarea.textSelection( 'getContents' ) or
  • $( '#wpTextbox1' ).textSelection( 'getContents' )

But I have no idea what to use to set the content...

Mxn (talkcontribs)
var editor = $(".ace_editor");
editor[0].env.document.setValue("// This is awesome!");
editor[0].env.editor.selectAll();
TheDJ (talkcontribs)

This would allow you to use the Surface of the ace editor directly yes. It is the interface that our textSelection plugin ought to be talking to really....

He7d3r (talkcontribs)

Thanks Mxn and TheDJ!

I was able to fix the jsUpdater script, where I needed this feature.

TheDJ (talkcontribs)

Yeah, the textSelection plugin basically abstracts away browser differences when it comes to dealing with text areas. The CodeEditor plugin uses a totally different text surface. You should see #wpTextbox1 here more as the form value, then a input field in the case of CodeEditor. It has a basic implementation of textSelection API, which allows it to 'communicate' it's value trough the text area object, but it uses a totally different text surface to draw the value.

The textSelection plugin is not fully implemented however (neither for textareas nor for CodeEditor). Notably the 'setContents' method is missing, which would be used for what you describe. But ou can select and then insert characters in the selection (encapsulateSelection allows this).

Some links: https://git.wikimedia.org/blob/mediawiki%2Fcore.git/HEAD/resources%2Fsrc%2Fjquery%2Fjquery.textSelection.js#L58 https://git.wikimedia.org/blob/mediawiki%2Fextensions%2FCodeEditor.git/c9499815539390beff23527dc968465c30d4ec92/modules%2Fjquery.codeEditor.js#L522

We ought to improve this at some point. The textSelection plugin is a remnant of the iframe wikicode highlighting experiment of the 2010 WikiEditor that got cancelled, so it hasn't seen too much action since then. It's currently only used for special character insertion.

He7d3r (talkcontribs)

For future reference: the setContents function was implemented in gerrit:149529.

However I didn't figure out how to use it as a solution for the initial problem. None of these work if CodeEditor is enabled:

  • $( '#wpTextbox1' ).textSelection( 'setContents', 'TESTING' )
  • $( '#wpTextbox1' ).data( 'wikiEditor-context' ).$textarea.textSelection( 'setContents', 'TESTING' )
Sadashiva5510 (talkcontribs)

my test 1

Reply to "How to set the content of the textbox?"
Cafeinlove (talkcontribs)

Typing Korean characters through IME(bundled in Windows 10) outputs oddly. Please see next:

There is some irregularity in typing in Korean. Basically, Korean characters are composed of Consonant + Vowel + Optional secondary consonant . That combination forms one single character; and the pronunciation varies according to its components — meaning, 1 character equals 1 syllable. In consequence, the typing software generally tries to hold your input until the formation completes and release the formed character into the editor afterwards. (I am not sure if this relates to the issue, just providing some context.)

As of now, I am escaping this by typing just one character at a time then add space + delete the space with backspace: this action sort of resets something and allows me to continue writing another character.

Reply to "Weird output with IME Ko-KR"
Jack who built the house (talkcontribs)

Are there plans to update Ace from its author? Several important changes were made. Of particular importance to me are—removal of the concept of "Too many errors" from JSHint with the buggy implementation in Ace where this warning sometimes shows up even if no errors at all are present in your code above the line with warning, which makes it impossible to see the real errors after the line (the removal was done back in 2011); giving an opportunity to customize worker options and adjust which warnings & info you want to see in the gutter line.

Jack who built the house (talkcontribs)

In the meantime I have found that there is an opportunity to customize worker via calling editorSession.$worker.call('setOptions', [{ options }]); (editorSession is obtained by

mw.hook('codeEditor.configure').add(function (editorSession) {
    ...
});

). The list of the options is available here. You can set maxerr to a higher value if you experience the same issue as I do. The fact that, by default, the editor shows "Too many errors" warning at 210–220 line in two distinct scripts of mine with no other errors at all strikes me nevertheless.

This comment was hidden by Jack who built the house (history)
Reply to "Update Ace?"
Jack who built the house (talkcontribs)

Would like to set print margin column other than 80 (it's done via setPrintMarginColumn() method of the Editor object, see https://ace.c9.io/#nav=api&api=editor), but unable to do so, because codeEditor.configure doesn't give access to the Editor object, only EditSession. There's also plenty of other useful settings which I believe some users would like to adjust to their preferences.

Reply to "No way to access the Editor object"

codeEditor.configure on edit formulas

1
Gianlucarigoletti (talkcontribs)

When it says that it is possible to change the configuration of the ACE editor, by hooking into the MediaWiki JS hook codeEditor.configure

it seems that this hook is fired only when the page has content model of js, css or json (by looking here ). Any chance that this hook will be fired also when editing a math formula? I want to use the Ace editor session manage some math snippets

Reply to "codeEditor.configure on edit formulas"
Innosflew (talkcontribs)

I did everything during the installation and configuration as it written in the instructions but the Code Editor is not working. It doesn't show up, my wiki just uses the regular source editor. Please help.

Reply to "Not working"
Waldir (talkcontribs)

How can a user disable this if it's installed as an extension (rather than as a gadget)? I found nothing in the preferences on enwiki, and the extension's page only mentions a server-side variable ($wgCodeEditorEnableCore).

TheDJ (talkcontribs)

There is a toolbar option that disables the editor (remembered by cookie). There is no preference option (and I doubt we will add it).

Waldir (talkcontribs)

Thanks. And why not a preference option?

TheDJ (talkcontribs)

Because in general we want to have fewer preference options, especially when it comes to preferences that are used by a very small set of users.

George Orwell III (talkcontribs)

... and that cookie has recently been reset (or expired?) and now the editor is enabled once again as my default. "Turning it off" again would require me toggling the button in WikiEditor - as I've done many times before when this has happened - but I never get the "chance" to hit that button because it just hangs & hangs (IE8/XP Pro, Wikipedia/Wikisource/etc. same story everywhere) whenever I open an applicable page (User: js css, MediaWiki: js css - doesn't matter).

Usually I can use the built-in IE "debugger" to isolate sh!t like this and more often than not it's WikiEditor and it's screwy "button & icon generated from over here, button & icon generated from over there, buttons & icons generated from any & everywhere" design, but this is different & can't run it without the "hang" preventing it from reaching anything meaningful in the console (and don't get me started on spirited span vs. old-school image - I wish somebody would fish or cut bait and standardize one or the other already.... but I digress).

So what's the way to turn the cookie off again so that reads as my default given the absence of some similar option in User: preferences? Another adventure in API again where am not an admin screws me either way? TIA. --

TheDJ (talkcontribs)

I'm considering starting to use localStorage to safe some of this, which would be a tad more permanent and not submit it with each and every request. It will be a while before that is done though. I'll attempt to run it in IE8 myself. See if I can find an IE8 specific problem.

He7d3r (talkcontribs)

Be aware of bugzilla:64721 (mw.loader.store should not occupy all of localStorage for itself).

This post was posted by He7d3r, but signed as Helder.wiki.

Waldir (talkcontribs)

The impermanence of the preference setting is quite inconvenient indeed, and it general it makes no sense to use a temporary measure for a setting that's meant to be permanent. Since this is an extension and not part of core mediawiki, I really don't see why including a preference would be such a problem...

TheDJ (talkcontribs)

Perhaps we should have hidden preferences and allow the CodeEditor UI to switch those using JS...

George Orwell III (talkcontribs)

That makes no sense as well and is contrary to normal best practices (to the best of my knowledge) on any wiki project. Your earlier assertion about this being "... preferences that are used by a very small set of users" seems hard to prove through cookie usage alone - if it ever was a formal preference, what was the opt-in/opt-out percentages?

Debate aside - this is no longer an isolated low-level issue for me since the remaining project where I'm an admin has also reset itself and CodeEditor is now "on" no matter what I try to avoid it. I can no longer edit in any namespace where CodeEditor is present without edit-mode hanging the session. I cannot "reach" the code-editor button before the focus is lost to the hang.

Happens when logged in or logged out now. Relevant? Pref settings

  • Show edit toolbar OFF
  • Enable enhanced editing toolbar ON
  • Enable wizards for inserting links, tables as well as the search and replace function OFF

All the latest patches for IE8 & XPpro applied. Some sort of relief is desperately needed here. TIA. --

George Orwell III (talkcontribs)

Interesting....

Even when I disable all 3 preferences [above] concerning toolbars altogether - giving me no toolbar whatsoever in most namespaces upon edit mode - CodeEditor still manages to give me the finger, activate WikiEditor, turns itself on and proceedes to hang like it was before the preference change(s) in those namespaces its been "cleared" for (MediaWiki, Module).

Anyone able to replicate?

I'm sorry. This is beyond unacceptable. If a User: opts for no toolbar (no old toolbar, no WikiEditor, no enhanced WikiEditor), the equivalent of disabling all 3 previously mentioned User Preferences, then that is what Users should get. CodeEditor should not usurp that basic standard. --

TheDJ (talkcontribs)

You can submit patches like anyone !

George Orwell III (talkcontribs)

I would if I could... "fixing" something like the above is beyond my limited skill set. Sorry.

I see similar complaints have already been submitted as Bugzillas however; bug 45850, bug 46779 and bug 62250 in particular. --

Waldir (talkcontribs)

Thanks for the pointers. I left a comment on bug 46779 with a link back to this discussion.

TheDJ (talkcontribs)

I invested some time to bring all of this together. Will take a while before it's all passed review I think, but I think it works quite nice and intuitive with the patch that I created.

George Orwell III (talkcontribs)

fwiw... these are my findings @ test2.wikipedia.org under 1.24wmf4 & IE 8. From the chicken bones I can read at Git, it seems more than one "patch" was applied / still needs to be applied but don't hold me to that

Settings Key
  • User pref "show edit toolbar" = Option 1
  • User pref "use enhanced toolbar" = Option 2
  • User pref "use wizards and tables..." = Option 3


With all three Options disabled, the previous issue of CodeEditor forcing WikiEditor "on" no longer seems to be an issue. No toolbar, neither old or new, rendered at all so CodeEditor not "present" no. I'd say this is Fixed.

With only Option 1 enabled, the old toolbar appears in all namespaces BUT in those dealing with MediaWiki and Modules. No toolbar of any sort appears in those cases. I'm not sure if this is normal or not (boy do I miss meatspace) and can't recall if I tested for this earlier if ever. Personally don't really care because I never plan to enable the "old" toolbar either way but other folks might take issue with this nevertheless.

From here on, there is no difference between an enabled Option 1 or a disabled Option 1 as long as Option 2 was always enabled at the same. This has always been the normal and intended behavior concerning Option 2 to the best of my knowledge --> An enabled WikiEditor (enabled Option 2) always superseded the old toolbar (enabled Option 1).

That said, all other combination of Options 1, 2 & 3 no longer produce the previous "hangs before I can toggle off" issue & CodeEditor is easily toggled on & off here (plus it stays that way over session logins/logouts).

In fact, most other "minor" layout &/or rendering &/or focus issues that drove me to avoid CodeEditor altogether in the first place seem to be gone now too ( damn that last comma?). I'd have to see the same under a full wmf4 deployment to futz with it again - it could just be the watered-down beta site & settings.

Anyway, hope that helped.


One last suggestion - I see there is some "new" feature(s) at the bottom left of the EditBox with a "stop" symbol, a "yield" symbol and an italic letter i. Would be useful to add some pop-up descriptions for each upon a typical mouseover. Where would I find more info on whatever that is. TIA.

TheDJ (talkcontribs)

I noticed that part of the problem here is that apparently CodeEditor was working, and now seems to be totally broken icw IE7/8. This is unintentional, and I suspect it happened after the last update. Can you check if you get similar freezes on http://ajaxorg.github.io/ace-builds/kitchen-sink.html ? Then we can at least update to a newer version that IS working with IE7/8. Opened bugzilla:64559

George Orwell III (talkcontribs)

Not exactly sure what it is that I'm suppose to be looking for at that URL, but if it is the same "forever hang" as I was getting on the wiki-sites; nope- no hang there. able to scroll. able to select/deselect on the left... in short, "focus" not an issue and I am able to do pretty much everything I tried.

The following appears upon landing on that page if it helps any...

function foo(items, nada) {
    for (var i=0; i<items.length; i++) {
        alert(items[i] + "juhu\n");
    }	// Real Tab.
}

Sorry if I came off like the typical wiki-jerk earlier & Thanks again for any attention given to this matter - I realize the death clock is ticking for those versions of IE and addressing issues for them is an investment producing less & less in the way of positive returns as the final hour draws near. At the same time, that's what I'm stuck with for work reasons and really wouldn't be able to "contribute daily" otherwise. Prost.

TheDJ (talkcontribs)

I too apologize, I should know better. Thank you for confirming that the above link does load for you, this indicates that indeed there was a serious regression in our last CodeEditor update with regard to IE7/8, that had gone unnoticed.

Reply to "How to disable?"
He7d3r (talkcontribs)

If a script was created without the CodeEditor, and uses tabs for indentation, when we edit the code using the gadget it mess up with the alignment. See this example, where the added lines were indented using the CodeEditor, but they are converted to spaces while the tabs in the other lines are not. The result is a script wich looks good while we are editing it, but it awful after the page is saved.

He7d3r (talkcontribs)

Hmm, I'll have to check how ace handles tabs by default... right now I don't think I'm changing the tab settings from default.

This post was posted by He7d3r, but signed as Brion VIBBER.

Rillke (talkcontribs)

On the one hand there are the Coding conventions that recommend tab chars and on the other hand this editor that inserts 4 spaces!? What game do you play here?

Rillke (talkcontribs)
// Make CodeEditor using TAB
(function () {
	var tb1 = document.getElementById('wpTextbox1');
	if (!tb1) return;
 
	mw.hook( "codeEditor.configure" ).add(function( editorSession ) {
			var ce,
				we = $(tb1).data('wikiEditor-context');
 
			// Wiki editor?
			if (!we) return;
 
			// Code editor plugged in?
			ce = we.codeEditor;
			if (!ce) return;

			// Do something with the editor (ce)

 			// Set tab indention to 3 (uncomment next line if wanted)
			// editorSession.setTabSize(3);

 			// Disable "soft tabs"
			editorSession.setUseSoftTabs(false);
	});
})();

+2 hours of research within code that is not following the documentation rules set out for JavaScript for this crappy solution.

Reply to "Tabs"
217.187.60.243 (talkcontribs)

no text

Kghbln (talkcontribs)

Cannot verify, works for me.

Kghbln (talkcontribs)

Oops, your right, it's broken. Use this for MW 1.25.x

TheDJ (talkcontribs)

The download site is out of sync due to some problems. User legoktm will be working on it.

Reply to "download broken!?"
George Orwell III (talkcontribs)

I had been operating under the assumption all this time that the not-so-unusual reason behind the non-functioning status-worker cells & status-message bar in CodeEditor was because even the latest release of IE still was not supported.

Imagine my shock when I happen to go change something in my common.js on test.wikipedia.org yesterday and the little bangs down the left and status messages bar field began reporting my typos!! Having convinced myself this must be something "new" and will be live in today's wmf13 roll out on Wikisource as well, I come here now -- hat in hand -- to find why CodeEditor's status-bar related features are absent for me on both en.wiki & enwikisource.

  • W8.1/IE11 (both the most current possible)
  • User prefs...
    • Classic toolbar: off
    • WikiEditor: on
    • WikiEditor's dialogs: off
  • Scribunto (Lua module: namespace) use CodeEitor = true

... and what is this I head about " buttons " (plural; more than one)?

I know there are bits and pieces dealing with buttons still stalled out, longing to be merged into the master code, but as I researched for possible causes around the wiki-world, I did get the impression some folks had more than just one "On / Off" button like I've always had.

Any pointers greatly appreciated ahead of time.

Reply to "CodeEditor status bar inconsistent?"