MacroInspect which comments macros

Alan Kilborn

Python normalizes \n to the newline sequence

Assuming you mean “Python normalizes \n to \r\n on Windows”, yes, this is true but only when writing to a file, which your code is not doing (you are writing to an untitled tab, e.g. new 2).

Perhaps you have a macro that shows where this selection fails?

OK.
I saw this:

            <!-- IDC_FRCOMMAND_BOOLEANS  [IDF_MATCHCASE, IDF_FINDINFILES_RECURSIVE_CHECK, IDF_FINDINFILES_PROJECT3_CHECK] -->
            <Action type="3" message="1702" wParam="0" lParam="546" sParam="" />
            <!-- IDC_FRCOMMAND_EXEC  [IDD_FINDINFILES_FIND_BUTTON] -->
            <Action type="3" message="1701" wParam="0" lParam="1656" sParam="" />

and I saw PROJECT3 in it, and that is irrelevant to a FINDINFILES. But really, I think it is just a boolean (for “direction”) that doesn’t affect the search but got in there as part of the “loose” N++ code handling the booleans when a macro is recorded. Maybe it is another good reason to filter it out or flag it somehow – so dumb users like me don’t think it is relevant. Again, not sure how much further you want to take your script.

Maybe helpful as a reference, here’s what I had in my old “disassembler” code as to what options are relevant to what search actions:

I think you can figure out that “ww” is whole-word and “mc” is match-case. “pp” had me confused for a moment, but I think it is presearch-purge.

Maybe a N++ issue should be raised that sometimes irrelevant search options are being recorded into the booleans? What do you think?

mpheath

@Alan-Kilborn said in MacroInspect which comments macros:

Assuming you mean “Python normalizes \n to \r\n on Windows”, yes, this is true but only when writing to a file, which your code is not doing (you are writing to an untitled tab, e.g. new 2).

Reading and write to files, Python does normalize though the editor methods do not so may need to harmonize EOLs which I may have solved locally and can post a revised update. shortcuts.xml can be read from editor and read from file so both need to be \r\n literally so editor.addText() adds \r\n literally.

… and I saw PROJECT3 in it, and that is irrelevant to a FINDINFILES. But really, I think it is just a boolean (for “direction”) that doesn’t affect the search but got in there as part of the “loose” N++ code handling the booleans when a macro is recorded. Maybe it is another good reason to filter it out or flag it somehow – so dumb users like me don’t think it is relevant. Again, not sure how much further you want to take your script.

Ah, the extra constants that perhaps should not be there in the comments as I mentioned earlier. How far? not more than what is needed is what I hope for.

Maybe helpful as a reference, here’s what I had in my old “disassembler” code as to what options are relevant to what search actions:

An interesting table, this might be useful for filtering with a blacklist. Certainly a great effort into making the table. Well done.

Maybe a N++ issue should be raised that sometimes irrelevant search options are being recorded into the booleans? What do you think?

I consider good to fix the problem at the source. Ideally, the script should just do as is done already without doing excessive filtering. It tires me just to think of having to do more when it should not be needed if the booleans were concise and correct … or perhaps I am not so young anymore.

Will see what can be done with the script within reason. I like doing things based on interest though sometimes it can feel like torture and the filtering implementation reminds me of the latter.

Alan Kilborn

Maybe a N++ issue should be raised that sometimes irrelevant search options are being recorded into the booleans? What do you think?

I consider good to fix the problem at the source. Ideally, the script should just do as is done already without doing excessive filtering. It tires me just to think of having to do more when it should not be needed if the booleans were concise and correct … or perhaps I am not so young anymore.

I will follow-up and put an issue in on this.

mpheath

To All, I have updated the gist with revision 6.

Revision 5:

Fixed root path for portable and installed.

Revision 6:

Fixed EOL to be CRLF.

Alan Kilborn

@Alan-Kilborn said:

I will follow-up and put an issue in on this.

Issue is CREATED.

mpheath

@Alan-Kilborn This table is a whitelist or a blacklist? If a whitelist then perhaps could replace the range() with predefined flags in a list like is in your table. Could you paste the table as text in a codebox so it can be copied as text? Then will try 2 pass reading to get the 16** numbers to know which list of booleans to bitwise and append to the comment. Just need to test this concept and it may work more to users satisfaction.

Alan Kilborn

        'numeric_value_to_relevant_options' : {
        #          ww  mc  pp  bm   sub  hid  sel   wrp   bwd   dot
            1    : 1 | 2 |                          256 | 512 | 1024,             # find_next
            1608 : 1 | 2 |                          256 | 512 | 1024,             # replace
            1609 : 1 | 2 |                    128 | 256 | 512 | 1024,             # replace_all
            1614 : 1 | 2 |                    128 | 256 | 512 | 1024,             # count
            1615 : 1 | 2 | 4 | 16 |           128 | 256 | 512 | 1024,             # mark
            1633 :             16 |           128 | 256 | 512       ,             # clear_marking
            1635 : 1 | 2 |                                      1024,             # replace_in_open_tabs
            1636 : 1 | 2 |                                      1024,             # find_in_open_tabs
            1641 : 1 | 2 |                                      1024,             # find_in_active_tab
            1656 : 1 | 2 |          32 | 64 |                   1024,             # find_in_files
            1660 : 1 | 2 |          32 | 64 |                   1024,             # replace_in_files
        #                                     prj1  prj2  prj3
            1665 : 1 | 2 |                    128 | 256 | 512 | 1024,             # replace_in_projects
            1666 : 1 | 2 |                    128 | 256 | 512 | 1024,             # find_in_projects
        },

I’d use the 1701 msg’s numeric data as the key to looking into this dict to get a relevant_options_val. Then I’d take the previous 1702 msg’s numeric data and AND it with ~relevant_options_val to calculate unneeded_options.

mpheath

To All, I have updated the gist with revision 7.

Added dictionary provided by @Alan-Kilborn to improve IDC_FRCOMMAND_BOOLEANS processing with valid boolean lists.

Let me know of issues.

Alan Kilborn

Such a minor quibble it isn’t worth mentioning, but if you end up doing any more changes maybe throw in a change that would remove all & strings from the comment?, e.g.:

            <!-- &amp;Save -->
            <Action type="2" message="0" wParam="41006" lParam="0" sParam="" />

And, I know it messes with the “purity” of the algorithm, but consider changing:

            <!-- IDC_FRCOMMAND_BOOLEANS  [IDF_WHICH_DIRECTION] -->
            <Action type="3" message="1702" wParam="0" lParam="512" sParam="" />

to something like:

            <!-- IDC_FRCOMMAND_BOOLEANS  [forward_direction] -->
            <Action type="3" message="1702" wParam="0" lParam="512" sParam="" />

mpheath

To All, I have updated the gist with revision 8.

Replace constant IDF_WHICH_DIRECTION with alternative IDF_FORWARD_DIRECTION to make it more meaningful with the action.
Use html.unescape() on type2 values to resolve entities. Example & will change to &.

@Alan-Kilborn OK, XML comments do not require escapes with entities. -- can be a problem with XML comments so will be reduced to single - if exist.

Replacing IDF_WHICH_DIRECTION is OK so as to avoid user confusion with which direction. The json will inherit the change so the file needs to be removed to get the alternative value of IDF_FORWARD_DIRECTION. Or, just edit the values in the json file to your liking.