It’s also about the long term vision for Macros: is it desirable to make them more powerful, to give more power to the average user that doesn’t have time to learn scripting, or not?

https://github.com/notepad-plus-plus/notepad-plus-plus/issues/4809#issuecomment-3239606439

How come it seems like the people will all these grand ideas for how the code should be changed have no ability to do it?

I already found some raw initial algorithms for making the user’s menu-command IDs constant

Great.

if other people want to work with the C++ part.

Why not YOU?

But if enough people will agree that macros become much more powerful by including any Run/Macro/Plugin commands, then N++ code could be changed, for the better.

It’s also about the long term vision for Macros: is it desirable to make them more powerful, to give more power to the average user that doesn’t have time to learn scripting, or not?
(IMO, it makes it easier even for those who know scripting)

I already found some raw initial algorithms for making the user’s menu-command IDs constant - if other people want to work with the C++ part.

I’m not sure he’s noticed how much I abuse the macro system

I don’t think you are abusing it; you’re simply working around the current limitations.
That’s normal: any software has limitations; no software is perfect from the get-go. It evolves.

shouldn’t sParam be "" ?

That would be better, yes. They ignore the sParam unless it’s one of the string-related actions, but for consistency’s sake, it should just be "". (I copy/pasted the line from a different macro, and didn’t notice it has the sParam="0" for that one)

The menu ID for a command should be kept constant.

That would be the easiest, from the hacker perspective. But since we are breaking the macro “contract” by trying to include non-recorded actions in a macro, we’re already past the edge into unsupported behavior; I am doubtful that storing/allocating a “constand commandID” in the XML would be implemented just to support a few hackers who aren’t following the intended behavior of macros.

I believe that the “official position” is that if you are doing something that doesn’t work with a recorded macro, you should instead switch to something like NppExec or PyhonScript plugins, instead of trying to use the macro system. I’m not sure he’s noticed how much I abuse the macro system, nor the fact that I have a FAQ explaining it. ;-) And I am really not sure I want this pointed out to him, lest he close the security gaps in the macro system.

I have just performed an equivalent one where I created 2 Run-menu actions, then manually included the second one in a macro; tested fine; then deleted the first Run-menu action and restarted N++.
When calling my macro, it, predictably, failed for the reasons you mentioned (in fact, it crashed N++).

A question in your step 3 above:

<Macro name="Do BC" Ctrl="no" Alt="no" Shift="no" Key="0">
        <Action type="2" message="0" wParam="20002" lParam="0" sParam="0" />
        <Action type="2" message="0" wParam="20003" lParam="0" sParam="0" />
    </Macro>

shouldn’t sParam be "" ? based on https://npp-user-manual.org/docs/config-files/#attributes-for-the-action-tag
Same in your example in https://community.notepad-plus-plus.org/topic/25400/faq-automating-notepad/2?_=1756438181968

Now to the main part:

It is 100% repeatable: it renumbered the macros every time one was inserted or deleted from the sequence, invalidating the wParam value used.

Same happens when Run-menu items are inserted/removed from that menu; I guess similar thing happens with plugin menu.

This pinpoints the core issue and also a possible solution/ fix to N++ code that deals with menu ID (re)assignments:
The menu ID for a command should be kept constant.

(Up until that command is removed by the user.)

What do you think ?

I think your experiment was not sufficient.

1. Start with three recorded macros (A,B,C, which just type the character of the name), restart
2. Use NppUISpy! to see that those macros are 20001, 20002, 20003
   
3. Manually edit a new macro called “Do BC” which calls B and C

   <Macros>
       <Macro name="Trim Trailing Space and Save" Ctrl="no" Alt="yes" Shift="yes" Key="83">
           <Action type="2" message="0" wParam="42024" lParam="0" sParam="" />
           <Action type="2" message="0" wParam="41006" lParam="0" sParam="" />
       </Macro>
       <Macro name="A" Ctrl="no" Alt="no" Shift="no" Key="0">
           <Action type="1" message="2170" wParam="0" lParam="0" sParam="A" />
       </Macro>
       <Macro name="B" Ctrl="no" Alt="no" Shift="no" Key="0">
           <Action type="1" message="2170" wParam="0" lParam="0" sParam="B" />
       </Macro>
       <Macro name="C" Ctrl="no" Alt="no" Shift="no" Key="0">
           <Action type="1" message="2170" wParam="0" lParam="0" sParam="C" />
       </Macro>
       <Macro name="Do BC" Ctrl="no" Alt="no" Shift="no" Key="0">
           <Action type="2" message="0" wParam="20002" lParam="0" sParam="0" />
           <Action type="2" message="0" wParam="20003" lParam="0" sParam="0" />
       </Macro>
   </Macros>
   

4. Restart and use NppUISpy to see the new macro is 20004. (Verified the macro worked, typing BC)
   
5. Edit shortcuts.xml, delete macro “A”, save, Exit Notepad++, restart Notepad++
6. See that NppUISpy now lists B as 20001 and C as 20002 and “Do BC” as 20003
   
7. Run “Do BC” and see it type C a number of times: it’s running 20002 to get “C”, then it runs 20003, which recursively calling itself until it hits an internal recursion limit

I tried this multiple times, in various combinations. It is 100% repeatable: it renumbered the macros every time one was inserted or deleted from the sequence, invalidating the wParam value used.

Like with the LF vs CRLF, I think you happened to be in the “lucky” circumstance where your experiment happened to work. In general, you cannot rely on the the menuCmdID for any given macro staying the same if you change the number or order of macros. Telling other people that it’s okay to rely on that is to tell them to invite disaster.

Hence, the FAQ will continue to state that if you change the number of Macros (Run commands, or add/remove/update plugins), you should always check to make sure the menu command ID hasn’t changed, otherwise your macro will quite possibly not do what was intended, once circumstances change.

@PeterJones Moreover, it continued to work even after I deleted another menu entry in Macro , located before the one I’m using one, plus experimtentally added then deleted several other saved macros and saved Run-menu actions and also after uninstalling a plugin and then after reinstalling it. Everytime restarting N++.

So it appears to me that in principle, Macro involving Run-menu actions should be recordable: the fact that the menu ID is dynamic does not affect the saved macro. Perhaps the same is true if the macro involves other macros and plugin actions.
The only case I can think of where the dynamic nature of a menu-command ID can ruin the saved macro is that it involves a plugin script and then you uninstall that plugin.
What do you think ?

Thank you for the detailed documentation, anyway.

I’m going to give a try to manually editing my macro and will report here.

I have read the manual on Macros, as well as the FAQ pages in the community about Macro and haven’t seen Run actions mentioned specifically.

Sorry, I had thought it would be obvious that the “How to Cheat the Macro System” section of the FAQ would be applicable to anything that needs dynamic menu entries, including Plugins, saved Run-menu commands, or calling other Macros from your macro, even though the FAQ previously only mentioned Plugin commands. However, since it apparently wasn’t obvious, I have clarified the FAQ now: the same method can be used to playback saved Run-menu actions in a Macro, or to playback other saved Macros in a macro.

But, because they don’t have fixed menu command IDs, Plugin commands, saved Run-menu actions, and saved Macros will never be macro-recordable; you will always have to manually edit a macro to be able to playback any dynamic-ID commands.

Are macro supposed to be able to record Run actions at all?

I can’t answer that but one of our regulars did some investigations a short time ago. Read his post here on what he found out.

In essence there is no definitive list of non-recordable commands.

Terry