[feature req.] Menu entry (command for shortcut) to Run the script in the current tab about pythonscript

[Ekopalypse]

You can already do this by creating a script with the following content

exec(editor.getText())

One thing that may not be obvious is that PS is basically a long-running REPL.
So the global namespace can get messy when testing things. Might want to think about a 2nd script that uses its own namespace.

[alankilborn]

For me, a namespace is like a container that ensures that the functions/methods and variables/constants used do not collide with existing ones.
exec(importNppAll + editor.getText(), ns, ns)
Now the code is executed in its own scope and has no access to the global scope offered by the main runtime

I take a bit of a different approach, as I often want/need multiple scripts to act "cooperatively". So, I don't do the same namespace stuff @Ekopalypse is doing in the exec line he showed.

A bit of a problem occurs when I'm going to publish a script. To make sure it has no hidden dependencies on something external to it, I do final testing in a clean testbed version of Notepad++ + PythonScript.

[victorel-petrovich]

Even better if you didn't even need to save that script in in the PythonScript user-script directory.

[alankilborn]

It would be so much more convenient to press a shortcut and run the script that is open in the active tab.

Ok ... but then the script will act on the text of its own source code data, which may not be all that useful. The typical scenario is that you develop a script and then want to run it so that it acts on real data in a different tab.

[alankilborn]

@Ekopalypse

REPL

What is this term? I'm not familiar...

[victorel-petrovich]

@Ekopalypse

exec(editor.getText())

That's very simple solution, thanks ! Seems to work as wanted.

So the global namespace can get messy when testing things. Might want to think about a 2nd script that uses its own namespace.

I take "script" to mean a file with any valid sequence of Python statements & definitions. Thus I'm sure you know that a script in itself won't create its own namespace. You must have meant using local-scope creating constructs like functions or classes.

So that aside, is there any difference between your solution and how PythonScript itself interprets a script that is saved properly inside user-script directory?

@alankilborn

Ok ... but then the script will act on the text of its own source code data

Hmm. Indeed. I was thinking of other kinds of scripts (that for ex output something in the console, or do other actions) and thought the feature would be as useful as the Run in Menu of N++.

On the other hand, such a feature is intended for the testing/exploratory phase (before you decide you'll keep this script in "collection").
So what if it acts on it's own text? You can undo.
Just tried it with the script for deleting lines in slopy-selection (courtesy of yours) ; it works, it demonstrates it can do the job :)

REPL
What is this term? I'm not familiar...

I almost rushed to explain... You're divulging a bit your age :)

[Ekopalypse]

@alankilborn

What is this term? I'm not familiar...

It expands to read->eval->print->loop and is what you get when you run Python from a command shell or what runs when PS initializes the Python runtime in the background.

I take "script" to mean a file with any valid sequence of Python statements & definitions. Thus I'm sure you know that a script in itself won't create its own namespace. You must have meant using local-scope creating constructs like functions or classes.

I meant namespace. For me, a namespace is like a container that ensures that the functions/methods and variables/constants used do not collide with existing ones.
E.g

    ns = {}
    ns["__name__"] = "__main__"
    importNppAll = "from Npp import *\r\n"
    exec(importNppAll + editor.getText(), ns, ns)

Now the code is executed in its own scope and has no access to the global scope offered by the main runtime (REPL).

So that aside, is there any difference between your solution and how PythonScript itself interprets a script that is saved properly inside user-script directory?

To be honest, I've never checked it out in detail, but I think it basically does the same thing.

Ok ... but then the script will act on the text of its own source code data

If the script needs to be tested against an actual buffer then I use both views Npp provides and the respective editor1 and editor2 objects.

[alankilborn]

then the script will act on the text of its own source code data

So what if it acts on it's own text? You can undo.

My point was that scripts are often designed to work on data that is not represented well by Python source code data. Thus, running a script on its own source may not be helpful in working on the script.

Ways around this:

• Put some representative data that the script will act on inside a triple-quoted string in the script's source (temporarily, for debugging the script). This data can be "free form".

• @Ekopalypse 's editor1 / editor2 technique, although with this one, you often have to remember to change all the editor1 to editor later (not a big deal with N++'s Replace All obviously). I say "often" because sometimes scripts are designed such that they work with data in both views.

• This one is longer, let me see if I can make my point: Put your script containing your exec call into a script file that you assign a keycombo to, e.g. RunCurrentPyFileAsPythonScript.py. I assign this to Ctrl+k. When I'm developing a script that I can test on its own source, I just use Ctrl+k to run it (with its tab active) and all is good. If I want to switch to a file with more generic data for testing the script, say a .txt file, I can make that file tab active and still press Ctrl+k. The logic of the Ctrl+k script detects that a non .py file is currently active, but still runs the previous .py file (because in the logic, I make it remember what that .py file was).

[alankilborn]

REPL. What is this term? I'm not familiar...

It expands to read->eval->print->loop

Ah, okay; that's so basic I didn't know it had (or needed) a name. :-)

---

You're divulging a bit your age :)

Hmm, probably older than you think: 57 (been doing this stuff since around 1983).

[victorel-petrovich]

@Ekopalypse
I see I misunderstood you on namespaces; I had assumed they are just same thing as "scope"/ local scope.
Your new solution is a bit too adanced for me. For now, I'll stick to always having my code in def main(): ... main(), even if temporary.
If it were possible to use your namespaces (or other?) trick to immitate the wrapping in def main(), that is, just to create a local scope (not ban accessing the global), then that could be convenient. (I'm sure it's possible somehow, but prob-ly not worth the time).

exec(editor2.getText()) is nice idea too, as alternative to letting it work in same file as the code (obviously with comments inside """...""", if needed )

[victorel-petrovich]

@alankilborn
By the way, it's quite convenient (if possible) to let it work on its own file / debug... you make a little change, a change in a var - and don't even need to move your eyes away to see the effect !

You're divulging a bit your age :)

Hmm, probably older than you think: 57 (been doing this stuff since around 1983).

Just to remove potential misunderstanding:
I had felt almost sure that you knew what a REPL is. So I thought: "You must be joking ! " (like, a sort of a joke from one old-timer to another one...). But then, by sharing that joke, you would have divulged that indeed you were an old-timer :) . That's why my "I almost rushed to explain... You're divulging a bit your age :) " .

[victorel-petrovich]

• @Ekopalypse 's editor1 / editor2 technique, although with this one, you often have to remember to change all the editor1 to editor later (not a big deal with N++'s Replace All obviously). I say "often" because sometimes scripts are designed such that they work with data in both views.

In those complex cases, I'd simply not execute it with this method (exec(editor...)).

This one is longer, let me see if I can make my point: Put your script containing your exec call into a script file that you assign a keycombo to, e.g. RunCurrentPyFileAsPythonScript.py. I assign this to Ctrl+k. When I'm developing a script that I can test on its own source, I just use Ctrl+k to run it (with its tab active) and all is good. If I want to switch to a file with more generic data for testing the script, say a .txt file, I can make that file tab active and still press Ctrl+k. The logic of the Ctrl+k script detects that a non .py file is currently active, but still runs the previous .py file (because in the logic, I make it remember what that .py file was).

Interesting.
Another way:
Just use this:

exec(editor1.getText())

Now just get the habbit of always having the running script in main (1) view.
When you can't test on its own file - have the .txt file in the 2nd view, and make THAT one active.
Ta-da! :)

[victorel-petrovich]

Closing this thanks to @Ekopalypse genius simple solution.

But I'll be happy to continue the chat here, of course, regardless of closure.

[alankilborn]

Closing this

Well, in the broader view, it still might be nice if there was a "Run active tab" menu entry... and closing this means that a PS developer won't see it and consider it.

[victorel-petrovich]

@alankilborn , I agree that could be nice for new users, but I thought, if they wanted such feature, they would search and find this thread (or others will point it out to them) and just use the above solution to easily get that menu entry (and shortcut).
Which is also a good little exercise in using PythonScript!

EDIT: Upon more thinking, I'd agree to a built-in "Run active tab" menu entry, if it implemented the version in my last comment #300 (comment). Or if it allowed us to specify the exact script/logic that goes behind that menu entry.
Because as you saw, there are at least 2 other possible versions (yours one, and the original), not to mention the one that adds custom namespace of @Ekopalypse .