MacroInspect which comments macros

Alan Kilborn

Getting better all the time…

One minor thing I noticed that I thought a bit odd was that the output file tab had LF line endings rather than the more traditional CRLF, but this is hardly important.

A “second pass” might be worth it for the “booleans”, because you could (a) be more specific about them (e.g. is it “in selection” or is it “project 1”?), and (b) you could filter out or flag irrelevant options (e.g. “search direction” is meaningless for a file-level search operation, but it can be encoded in the booleans).

mpheath

OK, bug squashing time. Just committed revision 5 though let’s works towards revision 6.

@Alan-Kilborn said in MacroInspect which comments macros:

One minor thing I noticed that I thought a bit odd was that the output file tab had LF line endings rather than the more traditional CRLF, but this is hardly important.

Python normalizes \n to the newline sequence though may need to set the new tab to use CRLF.

A “second pass” might be worth it for the “booleans”, because you could (a) be more specific about them (e.g. is it “in selection” or is it “project 1”?), and (b) you could filter out or flag irrelevant options (e.g. “search direction” is meaningless for a file-level search operation, but it can be encoded in the booleans).

a) There is no 1or2 AFAIK. This is the purpose of find_in_files_mode which is the boolean flag to select which one of the pairs of constants to display. It determines this based on a previous action containing FINDINFILES. Perhaps you have a macro that shows where this selection fails?

b) It is a odd constant I agree. IDF_WHICH_DIRECTION is forward direction though not displayed if backwards if I have that correct. Seems poorly named and knowing if backwards seems more important.

Alan Kilborn

@mpheath said:

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.