Using Monaco editor - monaco branch now in fork (PR#2971)

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.

3 Likes

I am personally on the fence.

Some folk really love em so I guess I just wanted to demonstrate the possibility for folks who must have them.

2 Likes

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. :grin:

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. :slightly_smiling_face:.

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 :smiley:

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.

1 Like

Hi all, been progressing monaco implementation.

Progress...

  • Added @types for node and node-red
  • Deleted all the DOM stuff from intellisense
  • improved snippets
  • improved JSONata
  • error checking

If anyone is still reading - would you mind?

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...

If anyone is still reading - results...

A few hours ago, in the previous post, I asked how many errors did you see in the screenshot.

Some were easy, some were a bit more knowledge based, others were downright devious :slight_smile:


There were 10 issues / errors - here is a demo of what monaco editor can do...

(click me to reveal)



Thoughts

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

image

And if you wish, the whole file in one go...
KyXTi45AB0

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)

4 Likes

I want it! When can we have it in Node-RED main branch :pray:

1 Like

See previous comments from Nick above.

I know v2 at best - won't stop me asking though will it :wink:

I really do hope it can be squeezed in as it would be a major step up from the ACE editor. Even though I'd probably have to rewrite some bits of uibuilder :unamused: Well worth it though.

Just to be clear - the action is not with Dave and me here. Until there's a PR against the dev branch we have nothing to look at.

1 Like

Hi all, there is no PR (yet) as I am still making sure everything is good to go & minimise impact.

For example, JSONata was not possible - I had to write a tokenizer and then I had to integrate the snippets and generate a hover provider for it - I am quite pleased with the results but it took weeks of research and playtime to get it right.

Then there was getting the nodejs types to import and disable the unnecessary DOM types/intellisense.

So, I am dogfooding this branch pretty much everyday & I have found a few doozies - though they are now few and far between now (so I am much happier than before).

uibuilder works :slight_smile: - though I just realised all the efforts I went through to remove DOM types was now a bit of a wasted effort (since it will greatly improve the situation for client side js in uibuilder and template node - DOH!)

@knolleary @dceejay I am close to raising PR but knowing how busy you guys are, I dont want to give you a huge headache so trying to cover all (most) bases - unfortunately as there are only a one or two users who will test & feedback I must do most of the testing myself & be sure it is worthy.

Lastly, I just realised - the post Nick made about raising a PR was Jul 24th - OMG - time really does fly.

2 Likes

I couldnt leave it like that. I have re-added the DOM types & after some serious research in the hundreds of open and closed issues, I managed to find a way of toggling DOM suggestions. So, by default, DOM suggestions are disabled & NODEJS/Node-red server side types are "added" (this is defaulted for the function node). In ui_builder, to have the fantastic client side JS suggestions, you will need to pass a flag in the createEditor options. Unfortunately, there is no VUE lang for monaco (its in the issues as a feature request :crossed_fingers:) so will need to set HTML lang for vue files. I will see if this can be intelligently handled.

But all in all, I am much happier with the whole package.

Lots of tidy up --> add notes/TODOs --> lots more testing --> PR (I hope to have this raised in next few days)

1 Like

There must be some changes to uibuilder.html though to use the monaco editor instead of ACE? I know that I have some ACE-specific code in there.

nope, it all works automagically :slight_smile:

In a nutshell, when the users sets the settings.js to use monaco, all the calls to createEditor etc create a monaco editor instead of an ACE editor & I proxy all the commonly used ACE methods to the monaco instance. This maintains compatibility across all existing nodes (that I have tried out anyhow).

Yes, you did, most nodes call the RED apis but you had needs due to flexibility of uibuilder. So i proxied those 1 or 2 calls also.

Essentially, as it is currently written, it just works in place of ACE. If there are any nodes out there doing deeper calls into ACE, then that can be an issue. but so far, i have seen, uibuilder was the only one using something out of the norm.

2 Likes

Wow! Amazing work Steve.

If you need/want me to put those changes into uibuilder itself though, now I've finally got v3 across the line, I'm in a better position to do so. I know that Lena was working on some improvements for me, making the code more in line with the Node-RED native ACE use, but unfortunately she isn't in a position to complete those right now.

1 Like

Julian, I have found a reliable way to determine clientside vs serverside JS editor so there is nothing for you to do - it just works

That said...

in uibuilder, you have a function that attempts to determine the editor type called fileType (link) essentially, you attempt sanitise the editor type required for the file before setting the ACE mode.

In this case, you end up passing text for many types that are actually supported by monaco. e.g. in, SCSS looks like this (your function passed in "text" for the mode)...

But if I force the type (mode) to "scss", it looks like this...

preparation suggestion...

If ACE gracefully defaults to a plain mode when it doesnt recognise the requested type (mode), perhaps you could modify the fileType function & let the default return be the actual file extension (or "text" if empty) - then it will be ready for when (if) monaco lands.

PR getting closer :wink:


EDIT...
ACE also supports SCSS mode btw.

1 Like

One thing that has held me back for some time is the poor mobile experience of Monaco.

So I have spend the last couple of days on that (debugging the monaco source, alternative mobile browsers, etc) then... bingo :partying_face: - changing the soft keyboard to a coders keyboard ("Codeboard Keyboard for coding" for android) & everything works :sweat_smile:

On top of that, I added some browser / device detection to "slim down" the capabilities somewhat for limited mobile devices (nothing too drastic, all the good stuff left turned on)


NOTE: Sorry I own zero apple products
testers very welcome


2 remaining tasks before I raise a PR

  1. See if I can do a better job of compiling the monaco code (parcel adds all sorts of hashes to the names)
  2. Final testing

1 fly in the ointment

Monaco support for IE 11 ended in FEB 2020
Is this a show stopper?

:crossed_fingers:

2 Likes

IE11 is out of service from the middle of next year so I don't think you need to worry about this.

but we do.... we know we have folk still using it.

I hate IE with a passion - it is the reason we cant have nice stuff

image

1 Like