Forum Replies Created
- Posts
It might affect filtered content only.
Here is some simple PoC CSV data (two rows):
col_1,col_2,col_3 col_1,col_2,col_333- Open those two rows in cell selection mode (CSV) inside EmEditor.
- Try to edit any cell – it will work as intended/expected.
- Now filter out the string “col_333” in column 3 (which in turn will make the second row disappear from view).
- Then try to edit any of the cells on the remaining row.
- You will now see the described behavior.
(and no, I don’t have any plugins, and neither any active macros when this happens)
Any chance to comment on this?
Is it by design (and in that case why?), or could it be fixed in an upcoming version?
Yet another two months have passed, and this bug still makes my job harder every day. :-(
Any chance to fix it anytime soon?
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.
Thanks!
I’d still recommend to implement “real” macro support for it though (e.g. by making the document.selection.SetActivePoint() method optionally be able to use relative visible line numbers instead of only absolute line numbers). :-)
Sorry if I was unclear. Yes, the eeGetLineView parameter to the document.GetLines() method does indeed return the number of visible lines. Unfortunately this is not the problem though.
The problem is that when I then want to use this number to move the cell cursor in the filtered document data, it turns out that the document.selection.SetActivePoint() method only uses absolute line numbers (i.e. the line numbers that are listed to the left in EmEditor, contrary to the target line’s number in the order of visible lines from the top of the document), and these absolute line numbers do not change when filtering the data, which in turn means that the result returned from document.GetLines(eeGetLineView) is sadly of no use at all for knowing how to make document.selection.SetActivePoint() position the cell cursor on the last visible line of the filtered document.
Allow me to completely rephrase the question for you though, and you will most likely stumble upon this problem yourself when answering this question if nothing else:
Could you please tell me how to write a macro in EmEditor that performs the simple operation of selecting all visible cells in the current column (except the header line) in an arbitrarily filtered document in Cell Selection Mode?
Thanks for your reply!
Unfortunately, this is not a solution for the problem. :-(
Even though it works when only rows at the very end of the file has been filtered away, it does not work if any other rows higher up in the document has been filtered away also.
Example:
Unfiltered document contents:
col1,col2,col3 1,2,3 aaa,bbb,ccc aaa,bbb,ccc 11,22,33 111,222,333 xxx,yyy,zzz xxx,yyy,zzz xxx,yyy,zzz xxx,yyy,zzz xxx,yyy,zzzAfter filtering the last rows (e.g. filtering away “xxx”):
col1,col2,col3 1,2,3 aaa,bbb,ccc aaa,bbb,ccc 11,22,33 111,222,333As mentioned above, the selection macro in my first post (modified with your suggestion of the eeGetLineView parameter to the document.GetLines() method) does indeed work now, BUT, if we also filter away some other lines, e.g. the ones containing “aaa”, we get the following visible document contents:
col1,col2,col3 1,2,3 11,22,33 111,222,333And if we then try to run the macro, the selection is cut short and does not cover the full column (the last line is not selected, and the more lines we filter away, the more lines will not be selected at the bottom).
The problem is apparently that the SetActivePoint() method uses absolute line numbers (i.e. ignoring that rows have been filtered away), while the document.GetLines() method always returns a total count of lines (visible or not). So we would either need the SetActivePoint() method to also be able to use relative line numbers (i.e. after filtering), or need some completely other method to return the absolute line number of the last visible (non empty) line (for example named “document.GetLastVisibleLineNumber()”), in order to be able to perform this simple operation of selecting the contents of a column?
Here is the full macro code, modified with your suggested eeGetLineView parameter, for reference:
document.selection.SetActivePoint(eePosCell, document.selection.GetActivePointX(eePosCell), 2, false); document.selection.SetActivePoint(eePosCell, document.selection.GetActivePointX(eePosCell), document.GetLines(eeGetLineView) - 1, true);Ok, I see, thanks for your reply.
It would be very useful with the possibility to perform multi-line searches also on filtered text contents like this though, so in that case I would very much like to suggest such a feature to be added to EmEditor, for example called “Search Filtered”.
I understand that it would require that the filtered contents are first copied to their own memory buffer before they can be regexp-searched (i.e. an initial CPU + memory hit for each such search operation), but that would absolutely be worth it (and as long as it’s not a giant file, it would also practically be negligible to begin with), but that wouldn’t be a problem at all as long as the user knows this and has chosen this special kind of search to begin with.
Any chance you can add such a feature?
The filtering capabilities of EmEditor are extremely useful, but being unable to search the filtered data all-out like this unfortunately reduces the full potential of this otherwise excellent filtering quite a bit for more advanced usage. :-/
Ok, I will try to make my test case above even more easy then (NOTE: even though the description is a bit lengthy, the example itself is still very simple, the detailed description of it is just for maximum clarity), here:
Create a document containing the following exact contents:
Line with empty row after it (1) Line NOT having an empty row after it This line makes the above line not match the regexp Line with empty row after it (2) Last lineNow, perform a normal search in EmEditor (i.e. via the normal “Find” dialogue), using the following search term (which is a regexp that matches all lines that have an empty line right after them):
^.*\n\n(leave all checkboxes non-checked in the Find dialogue, except the “Use Regular Expressions” checkbox, and also leave all checkboxes non-checked in the “Advanced…” sub-dialogue of the Find dialogue, as is default.
Now execute the search (i.e. press “Find next”).
You will now see, that just as expected, the following three lines match the search (i.e. they will be highlighted one at a time when you press the “Find next” button):
Line with empty row after it (1)This line makes the above line not match the regexpLine with empty row after it (2)So far so good!
Now, filter away the line “This line makes the above line not match the regexp“, by using the following filter expression in EmEditor (i.e. in the Filter box in the toolbar):
This line makes the above line not match the regexpThe remaining displayed contents of the document after this will now be as follows:
Line with empty row after it (1) Line NOT having an empty row after it Line with empty row after it (2) Last lineAs you see, the line containing the string “Line NOT having an empty row after it” does now indeed HAVE an empty line after it, which makes the stage set for our last step, showing the bug / unexpected behavior:
Now perform the exact same search in the document as above again.
Contrary to expectation and correct regexp behavior, only the exact same lines matching the first search will match this second search, even though the line containing “Line NOT having an empty row after it” should now also match the search (again, because it now HAS an empty line after it).
As a programmer, I understand the problem. You run the regular expression on the entire contents of the original document, even though some of its lines are filtered out from view, and then only display the search matches that are located in lines that are not filtered out of view. BUT, this obviously doesn’t work with regular expression searches involving linebreaks (as in my example above).
This means that for this to work correctly, you must either allocate a contiguous buffer containing the contents of the current filtered data, to perform regexp searches on (which will of course involve both a memory and a CPU hit for really large files), or make a restriction (or at least clear and visible warning) that regexp searches whose hits (or lookaheads/lookbehinds) involve more than one row cannot be used at all if the contents of the current document are filtered.
Personally, I would prefer a compromise that makes such regexp searches of filtered data possible for documents that just aren’t really big (say, more than a couple of hundred megabytes or so?), and restrict it only for documents larger than that. (and I would also do the same thing for the green markings of multi-row hits by the way, since the memory usage for an extra flag per row as you mention will only be a problem at all for really big documents there too, which are, after all, not nearly as common as much smaller documents).
I hope this was clear enough to understand the issue/problem?
Ok, thanks, I understand about the green coloring then (although wouldn’t single-line matches take up much memory too if there are just more of them, i.e. would the memory problem really be that significant if the number of lines per match is just only somewhat reasonable? – perhaps there could be a max-limit for the number of rows in matches that will be green-colored, for example 5-10 lines per match or something?).
About the second issue (i.e. the failure to correctly search in filtered data), do you acknowledge this as a bug that will be fixed then you mean?
Thanks for the reply about the green-coloring! May I ask though what the purpose is for skipping the green-coloring if a search match contains a newline? Aside from being confusing in general with such an inconsistency, it’s actually even more useful to have the search-matches colored when using a (multi-line or non-multi-line) regexp than when searching for static strings (since the search results can be harder to anticipate with a regexp). Would you therefore consider implementing this coloring also in cases when newlines are included in the search-results?
Regarding your reply to the second issue though (“The Filter feature will not search for a newline”), I think you may have misunderstood my question? I’m not using the filter to for this search, I’m only filtering out some rows first and then use the regular search feature in EmEditor on the resulting remaining data, which then fails as described above. It therefore still seems to me that this is a (quite serious) bug, i.e. that multi-line searches fail when performing them on filtered data?
I just noticed that the “111” line does not display with a TAB before it in the post above, but it has a TAB in front of the “111” in my test data. It does not really matter though, since it still proves that the “ccc” line will still not be “found” after the “111” line has been filtered away.
Ok, thanks!
I’m a software developer myself, so I know about the necessity of prioritizing feature requests (especially time-consuming ones)… :-(
Still, adding a thread-local buffer if threads are already used (or if asynchronous I/O is used, mallocing and keeping track of separate buffers) shouldn’t hopefully be super time consuming after all, so hopefully it won’t at least have to be sent to the very back of the queue for “time consuming and complicated features to implement sometime in the future” queue. ;-)
Oh, and again please do note that the multi-tab thing for the Output Bar is completely superfluous if only the results can be dumped to separate (background) tabs in the editor instead, for which the code (except the background part) already seems to be implemented too?
Hmm, ok, but if you simply just removed the “no” option, doesn’t this mean that the currently running job is always terminated, thereby eliminating completely the possibility of running parallel External Tools that can present their results in separate new documents, right?
If that is the case, it is the exact opposite of what I needed. :-(
Wouldn’t it rather be quite easy to just enable the jobs to store their results in separate memory buffers, thereby enabling the possibility to run separate jobs and present their results in new individual documents as they finish, for anyone user having such needs?
Ok, thanks for the clarification!
Too bad about the tabs in the Output Bar though, I’d really need some efficient way to run several external tools at the same time and still get all their results. :-(
I just tried to instead solve this by choosing “Create New Document” as the output method of the External Tool. I immediately stumbled into three different problems with this though:
1.
I found a bug related to the “Create New Document” output method I think: If I start the first instance of the tool with one selection of text in the document (i.e., the tool in question gets its input from $(CurText)), and then start a second instance of the tool before the first one has completed its execution, I get the dialog discussed above about terminating the first instance. If I select “No” there, the second instance starts, and when it finishes, two new documents are opened in EmEditor with results, but both of them contain the results of the second instance, while the results from the first instance is gone. (the same happens if I run three parallel tools of this type, i.e. three tabs are then opened, but all of them just contain the results of the last started job out of the three)2.
The dialog that pops up each time asking me if I want to terminate the currently running job disrupts my workflow.3.
The fact that the new documents pop up in the foreground (that is, that they are created AND switched over to from the original document that I’m working in) completely disrupts the workflow too.In order to solve this, I would humbly ask you if it would be possible to:
A) Fix the bug that I mention above in point 1.
B) Make it possible to “remember the answer” of the “do you want to terminate the current tool job” dialog, so that it never pops up again.
C) Make it optional to output the results in a new document that will not be switched over to in the editor, i.e. a “background document” (just like you can open links into new tabs in web browsers, without actually switching over to that tab automatically at the same time).
Would this be possible?
