Tagged: ,

Viewing 11 posts - 1 through 11 (of 11 total)
  • Author
    Posts
  • #22371
    LifeTimer
    Participant

    Similar to the other bug report I filed the other day, I just found another way in which the filter doesn’t work as expected anymore after I updated EmEditor. I have no idea if this problem is only in the recent version of EmEditor or has been there for much longer than that, but what I do know it that I have never seen this problem before either, and I’m a heavy user of the filter functionality in EmEditor

    Here is a proof of concept for reproduction of the bug:
    โ€”โ€”โ€”โ€”โ€”โ€”โ€”โ€”โ€”โ€”โ€”โ€”โ€”โ€”โ€”โ€”โ€”โ€”โ€”โ€”โ€”โ€”โ€”โ€”โ€”โ€”

    Input CSV file (only containing one column, but the bug behavior does not appear if loaded as normal text file, so it must be loaded as CSV):

    something here
    TEST\something.exe
    TEST\something.exe

    Source code of the macro that is executed on it (with a shortcut key, while CSV mode is active, and either the cell cursor is only placed on the entire middle “TEST\something.exe” cell, OR any arbitrary substring is selected inside this cell):

    if(document.CellMode)
    {
    	document.Filter(document.selection.Text, document.selection.GetActivePointX(eePosCell), eeFindKeepPrevious | eeFindNegative);
    }
    else
    {
    	document.Filter(document.selection.Text, 0, eeFindKeepPrevious | eeFindNegative);
    }

    The expected result is that only line 1 should remain visible, but what happens is that ALL lines remain visible.

    My guess is that the following has something to do with:

    1.
    The “Use Escape Sequence” option is automatically used in the created filter now (but not before?), which then chokes on the “\s” embedded in this string.

    2.
    No matter if I select any substring inside the cell before executing the macro with my shortcut key for it, the entire text of the cell is still reported in “document.selection.Text” in the macro code, which has not been the case previuosly, which I thus assume is a bug too?

    Could you possibly please take a look at this as soon as possible, since it is currently breaking my entire workflow and use case for EmEditor?

    #22374
    Yutaka Emura
    Keymaster

    All macros that have :

    Filter( document.selection.Text ...

    are affected. Please wait until v17.1.2 is released. I also recommend you updating EmEditor every time a new version is released.
    Thanks!

    #22381
    LifeTimer
    Participant

    Hello Mr Emura, thanks for your reply.

    Will the 17.1.2 version come very soon? Otherwise, could you possibly release a beta, or even send me a temporary custom build as you’ve done before, where this and my other reported filter problem are fixed?

    The reason for the hurry is that these problems affect my daily work very severely, and I might otherwise have to downgrade to an older version of EmEditor in the meanwhile (is this easily done, or will there be problems for the older versions to read the settings of the later versions or similar if I have to downgrade like that?).

    #22382
    Yutaka Emura
    Keymaster

    Hello LifeTimer,
    v17.1.2 was just released!

    #22383
    LifeTimer
    Participant

    Excellent! I have now upgraded and will let you know of any other problems I may find.

    Once again, EmEditor proves to have the best and fastest support of all software I have ever owned – thanks a lot as usual!

    #22384
    LifeTimer
    Participant

    Sorry, I just tried now, and the problem with filtering away lines containing backslashes still isn’t fixed completely – such lines still remain in some cases. :-(

    Here is a proof of concept for reproduction of the bug:
    โ€”โ€”โ€”โ€”โ€”โ€”โ€”โ€”โ€”โ€”โ€”โ€”โ€”โ€”โ€”โ€”โ€”โ€”โ€”โ€”โ€”โ€”โ€”โ€”โ€”โ€”

    Input text file:

    aaaaa
    C:\some\path\some_file.exe
    aaaaa
    C:\some\path\some_file.exe
    aaaaa

    TSV export data file contents for the filter mentioned below in the instructions:

    on something -1 EN 0 -1

    Source code of the macro that is used (i.e. the exact same line hiding macro as above, and still executed with a shortcut key, while the entire contents of some line should be selected in the document), but please see more instructions below too though:

    if(document.CellMode)
    {
    	document.Filter(document.selection.Text, document.selection.GetActivePointX(eePosCell), eeFindKeepPrevious | eeFindNegative);
    }
    else
    {
    	document.Filter(document.selection.Text, 0, eeFindKeepPrevious | eeFindNegative);
    }

    Steps for reproduction of the bug:

    1.
    Open the text file, select a line containing “aaaaa” and then run my the above line hiding filter macro. All such lines are now hidden, as expected.

    2.
    Close and re-open the text file, select a line containing “C:\some\path\some_file.exe” and then run the same line hiding filter macro. All such lines are now hidden also this time, as expected.

    3.
    Close and re-open the text file, and then apply the filter described by the TSV filter export file above to it (nothing will happen at this point since there are no matches in the filter, as expected). Select a line containing “aaaaa” and then run my line hiding filter macro. All such lines are now hidden, as expected.

    4.
    Now, close and re-open the text file, and then again apply the filter described by the TSV filter export file above to it (nothing will happen at this point since there are no matches in the filter, as expected). Now, select a line containing “C:\some\path\some_file.exe” and then run the same line hiding filter macro. All such lines NOW REMAIN, CONTRARY to what is expected, and CONTRARY to what happens in the exact same situation with the “aaaaa” lines in step 3 here above!

    So, to be clear, the bug is what is described in step 4 here above, and it is of course very strange that it only happens during these particular conditions (both in regards to the previously applied filter levels AND to backslashes in the filtered data), rather than always (e.g. in the described step 1, 2, and 3 here above)?!

    Please, if possible, let me know as soon as possible what your findings are in regards to this, since this is still crippling my daily work.

    Thanks a lot as usual!

    #22385
    Yutaka Emura
    Keymaster

    I reproduced the issue, and will look into it.

    Thanks,

    #22390
    Yutaka Emura
    Keymaster

    I’ve fixed this issue, and the next version will include this fix. To work around this, you might want to enable “Match Case” when escape sequences or backslashes are included in a search string.
    Thank you,

    #22392
    LifeTimer
    Participant

    Great, thanks a lot!

    Any chance of getting my hands on an alpha/beta/special build now right away, since this problem is affecting my daily work so much?

    Changing the filter parameters as you mention above would require me to rewrite multiple macros that I use, and also changing the already existing (many and large!) exported filters that I use, which would require a huge effort. :-(

    I promise to report any other bugs, as usual, so that they all can be fixed in the next official release. :-)

    #22394
    Yutaka Emura
    Keymaster
    #22396
    LifeTimer
    Participant

    Thanks a lot!

    That seems to have solved the filter problems completely as far as I can see here, but yes, as usual I will report any bugs I may find, filter-wise or otherwise!

Viewing 11 posts - 1 through 11 (of 11 total)
  • You must be logged in to reply to this topic.