Hi Nick, thanks for chiming in & casting an eye over.
I did mean on a users local clone - not the real deal haha (note to self, be more explicit )
I'm not certain if you have looked at the implementation but this is the approach I took.
In the settings file, you have to set the editor to "monaco" to use it.
One thing that might wish to be considered leading to this (or any other editor for that matter) is to abstract the ACE interface and discipline ourselves NOT to call anything other than the functions offered in editor.js - that would make any editor more of a drop in replacement instead of shimming the ACE functions (not quite a plugin - but approaching that level of integration).
So, how could we proceed Nick?
Shall I raise a PR for discussion? I am certain there are better ways to achieve the integration than what I have done (I just dont know core as well as you guys) so there will be some leg work - and i know your time is tight (mine too) - but it would be a shame to not explore this?
The only way to get me to look and review code is a PR. That then gets it somewhere where it can be put into a plan and prioritised against everything else.
Just chiming in to encourage you to submit this PR at your earliest convenience
I'm working on a (phenomenally talented) team that doesn't have much experience writing enterprise-level software outside of myself, and an improved editing environment would be extremely helpful. We're building a fairly complex system, and even just auto-formatting on save (let alone everything else) would make the change worth it. The ACE editor truly leaves a lot to be desired...
Hi all, I have updated my fork to latest monaco editor V0.21.2 (released 2 days ago)
I have pulled latest node-red from github and merged that into this repo.
I had to make some extensive changes to how it integrates due to issues with the AMD loader it uses.
I ended up compiling the ESM code using parcel and adding it manually to avoid the dreaded Uncaught Error: Can only have one anonymous define call per script file
I will try to get a PR raised soon.
In the mean time, I would appreciate it if anyone wants to evaluate - would give me confidence to raise PR...
git clone https://github.com/Steve-Mcl/node-red.git
cd node-red
git checkout monaco
npm install
npm run build
npm start
Another update pushed to repo (and recent changes in upstream merged into the monaco branch) - in short, this fork is in-line with latest node-red source & the monaco branch is in-line with the dev branch (v1.2.0 as of writing)
Progress...
Fixed: hover tips clipped by the container DIV
Finally got JSONata colourisation, tooltips and snippets going (this was the last major feature point)...
Also plays nicely with es2020 nullish coalescing operator & optional chaining
and common language tooltips / intellisense...
Issues...
Monacos' context menu & hover tips are still clipped by the side-bar - regardless of z-index - cant figure this one out. Not a show stopper and could release with a "known issue"
Otherwise - looking good.
No errors in console
All contrib nodes (that i have installed) work without modification
I haven't installed every contrib node that might use the ACE editor but I have tested ui_builder, template, ui_template, function, unsafe function, mssql, json
h-e-l-p
I would appreciate it someone would be willing to download / test / feedback on...
mac
linux
ios?
andoid?
... to give me confidence to (finally) raise a PR.
Install instructions are in above post (and in post #1) but if you need help, gimmie a shout
On linux, I'm getting an uglify error during 'npm run build':
Running "uglify:build" (uglify) task
JS_Parse_Error [SyntaxError]: Unexpected token: punc «.»
at JS_Parse_Error.get (eval at <anonymous> (/home/ms/nrtest/node-red/node_modules/uglify-js/tools/node.js:1:1), <anonymous>:71:23)
at formatError (internal/util/inspect.js:1179:38)
at formatRaw (internal/util/inspect.js:949:14)
at formatValue (internal/util/inspect.js:803:10)
at inspect (internal/util/inspect.js:336:10)
at formatWithOptionsInternal (internal/util/inspect.js:2006:40)
at formatWithOptions (internal/util/inspect.js:1888:10)
at console.value (internal/console/constructor.js:313:14)
at console.log (internal/console/constructor.js:348:61)
at /home/ms/nrtest/node-red/node_modules/grunt-contrib-uglify/tasks/uglify.js:144:17 {
filename: 'red.js',
line: 29249,
col: 95,
pos: 1244282
}
>> Uglifying source packages/node_modules/@node-red/editor-client/public/red/red.js failed.
Warning: Uglification failed.
Unexpected token: punc «.».
Line 29249 in packages/node_modules/@node-red/editor-client/public/red/red.js
Use --force to continue.
Never understood why programmers want ligatures myself. It hides the actual characters which are core to the syntax. Always feels like there could be a danger of getting a wrong character that would be almost impossible to debug. Of course, that could just be my natural paranoia or a reflection of my own poor programming skills.
I've been using Fira Code with ligatures for 2-3 years now. I would say there's no going back after you get used to them. I just recently went through the trouble to switch and reconfigure a new terminal app for Linux partly due to ligature support.
I think they rather make you certain you typed the correct characters as otherwise the the characters wouldn't snap together in a satisfying way. .
But I'm also a lot into code aesthetics and nowadays ligatures are part of if it.
Well, I'm rather OCD about code layout but conversely I date from those heady times when getting to work on a 4-colour text terminal on the mainframe meant that you were a VIP user
In fact (off topic), I was instrumental in creating a set of "gui" overlays for the IBM ISPF terminal "personal computing" system to implement IBM's Common User Access gui on 3270 text terminals. IBM told us it couldn't be done, so we went and did it anyway. It was a cheat of course in that you had to craft lots of individual screens that you swapped between. It was good though and I built some really useful business apps using it.
I have a quick test below. I would love it if you could take a glance, see how many errors you spot? I deliberately haven't posted the code (so less chance of cheating)
You will not be judged - I am genuinely interested in your answers. I have made several of the errors myself in my time with node-red...
While it may not be beneficial to have such strict error checking on by default, individual issues can be easily quietened by adding // @ts-ignore above the item
And if you wish, the whole file in one go...
alternatively, the JS checking option could be toggled by a node option e.g... Check JavaScript
All of these improvements are now pushed to my fork (see first post for info)
)
.
