Need a Script for OO 5.2

This version does seem to work without tripping the crash seen with the evaluation of this and rootItem.apply

(() => {
    'use strict';

    // OMNIJS CODE -----------------------------------------------------------
        
    const JSContext_OO = () =>
        rootItem.descendants.map(
            x => x.note = x.note + '\n'
        );

    // JXA CODE --------------------------------------------------------------

    return Application('OmniOutliner')
        .evaluateJavascript(
            '(' + JSContext_OO + ')()'
        );
})();

Perhaps the crashing is rooted in the difficulty of returning certain kinds of value ?

In any case, the pattern above is what we need if people are going to start adopting the omniJS interface, exchanging snippets and attaching things quickly and lightly to buttons and keystrokes.

(Not that replacing .map above with .forEach will create a crash, because of the different return type)

I’ve submitted a note to support:

Scripting interfaces (omniJS + AS + JXA)

The AS + JXA Application.evaluateJavaScript(strCode) method is excellent,
and:

  1. much improves the prospects for wider adoption of omniJS / ‘Omni Automation’ on macOS
  2. needs a twin on iOS

BUT (in the macOS build)

  • despite working well with simple return values, will immediately crash if we
    evaluate code like: this
  • or replace a top level .map expression with a .forEach expression
  • or use a top level item.apply() expression like:
(() => {
    'use strict';

    // OMNIJS CODE -----------------------------------------------------------
        
    const JSContext_OO = () =>
        rootItem.apply(x => x.note = (x.note + '\n'));

    // JXA CODE --------------------------------------------------------------

    return Application('OmniOutliner')
        .evaluateJavascript(
            '(' + JSContext_OO + ')()'
        );
})();

In the meanwhile:

  1. Just returning a JSON string would be enough for most purposes (combined with JSON.parse() in JXA)
  2. Scripters will need to be aware that they should take care (for the moment) to return only simple JSON-expressible values at the top level of their scripts (Arrays, simple dicts, numbers and strings etc.)

Thanks very much for writing this up! Crasher bug filed against the Mac app, feature request filed against the iOS one, including a crosslink to the crasher. Appreciated!

1 Like

Certainly a completely different formulation is needed – as you know, ‘the DOM’ is simply a particular API (to which, and with which, omniJS has no connection or integration whatsoever) – ‘the DOM’ has never been hand-waving tech-speak for ‘web stuff’ or ‘HTML stuff’, and if we use it as if it were, we simply will get more (entirely reasonable) queries about how people can use their favourite web-programming frameworks in omniJS code.

What’s more, if launching code from hyperlinks is what you really meant, then that has no necessary connection even to HTML – plenty of plain text editors provide active hyperlinks, and we can open links from the Bash prompt and from most scripting languages.

None of this has any connection with or access to the Document Object Model whatsoever. All you need is a reformulation in terms of the wide range of materials, from Tinderbox to TaskPaper, in which hyperlinks launching omniJS code can be usefully embedded.