JXA-Build in Atom

This was briefly discussed at the end of this thread.

Well I have now update the init script again, this time with a full JXA Build process in Atom! Here’s a brief list of features:

Commands:

jxa:execute - builds your project and executes it. All errors are displayed in View>Developer>Developer Tools
jxa:compile -  builds your project into a *.scpt file
jxa:compileApp - builds your project into a *.app

Building

You will notice I use the word “build” a lot. This is because the script also implements a command include. You can use include as follows:

include(“my/directory/myFile.js”)

When a project is “built” the above statement will be replaced with the contents of myFile.js.

It is also compatible with relative file paths such as:

include("…/…/other/directory/myFile.js")

How to use:

  1. Install atom
  2. Open atom
  3. GoTo Atom > Init script…
  4. GoTo https://github.com/sancarn/JXA-Compile/blob/master/src/init.js
  5. Copy my code and paste it in your init.coffee.
  6. Rename init.coffee to init.js
  7. Close atom
  8. Open atom
  9. Open a JXA script in Atom.

Now press cmd+shift+p to bring up the command pallet and type, for example, jxa:execute. The currently open JXA file should be executed.

See it in action:

I made a little youtube video demonstrating the current capabilities of JXA-Build:

Note: In this video I also use a custom keymap which can be found here

Currently known bugs

For some reason when I use keymap to map the commands to keys e.g.:

'.editor':
  'cmd-k':'jxa:compile'
  'shift-cmd-k':'jxa:compileApp'
  'cmd-u':'jxa:execute'

the commands don’t execute the first time they are called. This may lead to nothing happening when using your keyboard shortcut. Example.

EDIT: This is a bug created by how Atom interprates keyboard shortcuts. See here for details.

Conclusions

If you find any more bugs please don’t hesitate to contact me.

##I would strongly advise saving before using any scripts.

I just noticed compile errors are currently not supported. So please be advised, save scripts before attempting to compile/execute scripts.

Finally, if anyone wants to include these commands in an atom package, you are more than welcome to! I myself am not comfortable enough with making packages yet… Which is one of the reasons why I made the include() commands in the first place! Otherwise I would just use node!

1 Like

Wow! This is awesome! :thumbsup:
Thanks for sharing!

I have been putting off installing Atom on a day-by-day basis now for months.
I think this may be the tipping point for me to "get it done now" :wink:

My thanks to @DanThomas and @sancarn for all that you guys have done and shared concerning JXA and Atom.

1 Like

A word of warning:

It can be fairly overwhelming at first... I guess this is true with many applications, but I didn't feel comfortable with how "Windows32" it feels. On the other hand it also feels like a "Mobile app" which is equally as weird. It is also annoying how you have to fully close and re-open atom when working on the init file... However, it is a very customisable editor which works on every OS. That's the main reason why I use it. :slight_smile:

Edit: Granted, the application's "theme" can be changed also, which makes it feel much less mobile-appy. E.G.

https://puu.sh/tw0Ez/467094e55d.png

jxa:execute - builds your project and executes it. All errors are displayed in View>Developer>Developer Tools

Thinking about it, it would be much nicer if this changed... I have seen some great implementations of "error logs" at the bottom of atom's text editor, which would likely be better... Needs thinking about.

Just found out that when a compile error occurs Atom hangs eternally. I will work on a fix for this!

2 Likes

The compile error occurring a freeze bug has been removed:
Latest version: https://github.com/sancarn/JXA-Compile/blob/master/src/init.js

The errors are now also displayed in the atom interface with the common Atom display dialog:

Bear in mind that if you use init, the error message will say “On line x” where x is NOT the lin in your unbuilt script, but rather the line in the built script.

So I'm guessing the line number is shown would be greater than my actual line number, right? Is the offset amount always the same?

The offset entirely depends on the included files.

If you include a 3 line file then the offset will be 3.
Include a 10 line file then the offset will be 10. (Provided that the file is included before the main routine.

If you build classes / pseudo-classes stick the include at the end of the script and you’ll have no offset (assuming the classes don’t have errors of course)

1 Like

Oh I should also mention that you can always look in the _transpiled.js file:

As you can see, the line numbers are correct here.

When the errors are fixed the _transpiled.js file will be removed again.

1 Like