Quick Survey: When running script in leojs, where should the 'vscode' object be accessible?

[Félix]

Not sure what to decide for this so I thought of doing this quick survey! :)

When running scripts, (CTRL+B) Leo offers the g, c and p variables. I obviously want to expose the vscode API from it's base object "vscode".

Should it be top-level along with c, g and p? or, be located at:

g.vscode

or 

g.app.vscode

Thanks! 

Félix

[Thomas Passin]

Leo's g, c, and p objects all belong to Leo, not Python or PyQt.  if the vscode object belongs to the codebase outside of leojs, I think that g.app.vscode would be more appropriate and easier to use as a reminder of who vscode belongs to.

[Edward K. Ream]

Interesting question. All three choices, vscode, g.vscode and g.app.vscode are feasible.

g.vscode seems like the worst choice.

I tend to agree with Thomas. g.app.vscode is most explicit. Furthermore, g.app is likely the best place for a "pointer" to vscode.

A default/automatic binding to vscode doesn't seem like it would be all that useful. Any code can bind vscode to g.app.vscode easily enough. I might change my mind if you envision scenarios in which there are lots of usages of g.app.vscode.

Edward

[Félix]

Thanks to you both!! 

g.app.vscode also felt right to me, so I'm glad this is a shared view!

Félix

[Félix]

I thought I'd share this :)

Just a small example script that is possible to run in leojs, (with also having the vscode API available in g.app.vscode)

Incredibly, when executing the script, the global objects you'd expect to see in javascript ,(console, fetch, ect...) are available, as shown below!

Hoping to release a beta before the autumn starts!

Félix

@language javascript

const vscode = g.app.vscode;

g.es("hahahaha");

// 'await' for doCommandByName required only if other code in script is 'awaited'.

await c.doCommandByName('insert-headline-time');

const userInput = await vscode.window.showInputBox({

placeHolder: 'Enter something', // Placeholder text in the input box

prompt: 'Please enter some text:', // Prompt message above the input box

});

if (userInput === undefined) {

g.es('User canceled the input.');

} else {

g.es('User input:', userInput);

}

try {

const apiUrl = 'https://jsonplaceholder.typicode.com/users';

const response = await fetch(apiUrl);

g.es("about to call");

if (!response.ok) {

throw new Error('Network response was not ok');

}

const data = await response.json();

g.es("got it!!", JSON.stringify(data));

} catch (error) {

g.es("oh no!");

console.error('Fetch error:', error);

}

[Thomas Passin]

That's very nice!  What is the scope of variable defined in a script like this?  For example, you wrote const userInput = await vscode.... where I would have expected let userInput = .... If the script were to be run again, then userInput might want to take on a different value which would be disallowed by the const.  If each script got a new namespace each time it executed, though, there would be no problem.

[Félix]

The script local namespace is destroyed after it's finished. 

[Félix]

Works on vscode on the web too! 😂

[Edward K. Ream]

On Sun, Sep 3, 2023 at 8:33 PM Félix <felix...@gmail.com> wrote:

I thought I'd share this :)

Just a small example script that is possible to run in leojs, (with also having the vscode API available in g.app.vscode)

Incredibly, when executing the script, the global objects you'd expect to see in javascript ,(console, fetch, ect...) are available, as shown below!

That's very cool. And being able to run Leo from the browser is beyond cool :-)

Hoping to release a beta before the autumn starts!

That's "approximately" Sept. 22, according to NOAA, hehe.  I can barely contain my excitement.

Edward