dont use Notepad.save()

Notepad is the “class name”.
notepad is the instantiated object name.
You call functions on an instantiated object.
So, yes, you want it in your code, just as I wrote it before: notepad.save()

Same for Editor and editor.

Your second post …, well, thanks, but that will need some more time.

try to find some insight to extend my running python script

@Alan-Kilborn mentioned the right command if it really just is a save action.

But in general, you can edit shortcuts.xml, and look for your macro name (in my instance, it was blah). There will be a list of <actions> as described in my previous manual link. For type=0 and type=1, the scintilla.iface file will map message=# to the appropriate command – then you can search for that same text in the PythonScript docs to find the editor-object method name. For type=2, the mapping of built-in menu commands can be found in menuCmdID.h, though you have to do a little math: for example, IDM_FILE_SAVE maps to (IDM_FILE + 6), where IDM_FILE and IDM are defined near the top of the .h; putting that together, ((40000 + 1000) + 6) = 41006, so set type="2" wParam="41006" in the macro definition will map to IDM_FILE_SAVE – you would then look through the notepad object methods in the PythonScript docs to get the equivalent command.

find some insight to extend my running python script with the missing link (it’s just the saving of the active document …).

notepad.save() ?

So I will have to forget the macro-script-approach (since your workaround sketched actually is a little fragile) and try to find some insight to extend my running python script with the missing link (it’s just the saving of the active document …).

And, yes, these conflicts and non-conflicts did arise when I filtered the Plugin commands to find my Python scripts written before!

Now that I describe it, this problem sounds familiar.

Found it. issue #5374 – it was apparently closed/fixed in v7.6.6… so apparently this is a regression; I will need to experiment with v7.6.6 vs 7.9.5, and maybe even bisect it back to the original, to figure out when it came back (or whether I was wrong about it being fixed in v7.6.6)

But even then, I cannot replicate those results

I take it back. When I was cleaning things up after my experiment, I replicated it.
I deleted the shortcut from the blah macro, and deleted the blah macro. Then I went to my PerlMonksQuestion PythonScript entry, where I had assigned the Ctrl+E shortcut for the script.

In the shortcut mapper view, it originally said “No shortcut conflicts for this item”:

But if I Modify that line’s shortcut, it claims it is conflicting with itself:

If I Clear it and modify it again to re-add the Ctrl+E, it finds no conflict.

If I clear it there, and assign Ctrl+E to some other Plugin Command entry, the same thing happens (it claims CONFLICT on that keystroke if I Modify that same entry).

More experiments show: It’s caused when I filter the view – and then, only when the number in the far-left column changes. If I go to ShortcutMapper’s Main menu tab in a brand new unzip of v7.9.5 (no additional plugins, etc) and filter by new, then edit Move to New Instance to add Ctrl+E, it says no conflict. If I then Modify the Move to New Instance while still filtered, it claims a conflict with itself at #167. If I cancel the Modify (so it’s still Ctrl+E) and remove the filter, and scroll down to #167 Move to New Instance and Modify, it does not say it’s conflicting with itself.

Now that I describe it, this problem sounds familiar. If I get a chance, I may have to do some searching here and in the issues list, and see if I can find something similar (or if anyone beats me to it, feel free to link to the resulting discussion and/or issue).

It appears, the macro simply ignores the call of the script when getting saved!

Correct. Macro recording does not record calls to plugin menus, including calls to pythonscript entries. This is because the macro recorder can record three basic actions, per the docs: editor commands (essentially keystrokes inside the editor panes), most built-in Notepad++ menu actions, and search/replace actions.

Honestly, though, anything you can do in a macro can be translated into PythonScript commands. So if you’ve already got a PythonScript that you’re running, why not just expand it – or write a wrapper PythonScript – to include the other commands that you had been trying to send with a macro? (There should even be examples in the Forum of calling one pythonscript from another.)

The macro system is good for automating built-in actions in a linear fashion. If you want anything else – loops, conditionals, calling non-built-in actions, etc – then a scripting plugin like Python Script is your best bet. That said, there is a caveat: the reason why the Macro recorder doesn’t like plugin actions is because they don’t have fixed IDs – as you add or remove plugins, the command-id for the menu actions change. However, if you are 100% sure that you will not be adding or removing plugins or plugin menu entries, you can sometimes get away with cheating. If you have a plugin like NppUISpy, you can look at what Command ID is currently assigned to a given PythonScript entry. If you make note of that entry, you can then go edit %AppData%\Notepad++\shortcuts.xml to add a type=2 action to the recorded macro, where it the wParam value is the Command ID that you manually looked up. But that’s fragile, because lots of things can influence that. (Which is why the Macro Recorder doesn’t try, because it would give you a false sense of security.)

With respect to Ctrl.-E … The Shortcut Mapper erratically announces a “CONFLICT FOUND!” (when re-opening the mapper) although it says “No conflict …” directly after assigning that shortcut.

Did you try to assign that keystroke to both the PythonScript and to the macro? But even then, I cannot replicate those results. If I assign Ctrl+E to a script, and then go and try to assign it to a macro as well, it tells me that there’s a conflict immediately.

… the ShortcutMapper main menu will also tell you where this conflict is, so after CONFLICT FOUND suddenly starts appearing – even if you didn’t expect it to – look at the entry that it tells you, because that’s what’s causing the conflict. If you need help debugging that, you could paste us a screenshot or two – one showing the conflict, and the other showing us the entry that the conflict points to.