Viewing 5 posts - 1 through 5 (of 5 total)
  • Author
  • #21025

    I’m often working with the excellent Cell Selection Mode in EmEditor, and I’m also often using the also excellent filtering feature in EmEditor in this mode.

    Doing this, I have noticed a workflow-disrupting detail that can best be described as a bug, or at least “unintended undesirable behavior” in connection with filtering out rows.

    To be more specific, the cell (column number) having focus after having filtered away a certain row depends on the lengths of the values inside the cells of the row that was just filtered away. Or, put in another way: After having filtered away a row, a cell in a “random” column will be focused/selected (i.e. getting the mint-green “cell cursor”), instead of focus staying inside the same column as previous.

    I have put together a simple PoC for you to better be able to analyze this problem:

    Create a CSV document containing only the following two rows, and open this document in CSV mode (“Comma separated”, Cell Selection Mode):


    Add a negative filter for the value “filter_this” in column 2, thus removing the first line from view.

    For extra clarity, here is what this filter looks like when exported to a tsv file:
    on filter_this 1 N 0 -1

    Also, if it matters, I’m performing this filtering by invoking the following macro (using a keyboard shortcut) while having the “filter_this” cell active:
    document.Filter(document.selection.Text, document.selection.GetActivePointX(eePosCell), eeFindKeepPrevious | eeFindNegative);

    As you will see, the first row will now be filtered away (just as expected), and the active cell (in the remaining row 2) will still be column 2, i.e. the same column that was active when we invoked the filter (just as expected).

    Now, do it all again, but with the only difference that the value of the first cell on the first line is first changed from “1” to “123”. That is, like this:


    The active cell after the filtering (i.e. step 3 above) will now consistently be in column 3 instead (i.e. NOT the same column that was active before the filtering), which is very workflow-breaking (i.e. requiring the user to localize which random column he has just been moved too before being able to continue work with e.g. filtering out more values or similar).

    So, it would be really great if this behavior could be changed to be consistent (staying in the same cell column) instead of “random” like now, could you possibly please fix this?

    (my guess would be that the previous “character column number” is currently used instead of the “cell column number” to decide the new active cell after the filtering, so in that case simply make sure to use the “cell column number” for this instead as long as you’re in Cell Selection Mode when the filtering occurs)


    Any chance to fix this soon, or at least acknowledge this bug report in any way?

    Please also let me know if you need any clarification of the problem.


    Yet another two months have passed, and this bug still makes my job harder every day. :-(

    Any chance to fix it anytime soon?

    Yutaka Emura

    Hello LifeTimer,

    This will be fixed on the next version.

    Thanks for your patience!


    Thanks, looking forward to it then!

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