Forum Replies Created
- Posts
Excellent, and yes, the TSV filter export/import format would be great!
Thanks a lot for being so responsive to customer suggestions, as usual, it really makes my lifetime license of EmEditor feel like a good choice every time!
No, I use 32-bit color (and as you could also see on the other icons in that screenshot, they were absolutely not 16 colors-only).
Yes, 100% is used (and most importantly, this setting has absolutely not been touched either before, during or after the update), and I have now sent a screenshot excerpt (which also includes the 100% settings screen) to your email as per your request above.
Unfortunately, that solution would not work since I have 500+ different files that I work with regularly. :-( That method would also eliminate the above-mentioned flexibility with regularly being able to update all these different filters for the different files by just adding more filter-levels in them and then quickly being able to save the filter automatically to the right file (instead of browsing manually to the correct file among the 500+ filter export files that will be required).
So pretty please, with sugar on top, couldn’t you possibly implement macro commands just for the following?
import_and_apply_filter_from_file(path)
export_current_filter_to_file(path)
I’m quite sure it’s not just me that would find good use for this flexibility, after all? I really love the flexibility of the filter functionality in EmEditor, but this is a roadblock that I just can’t seem to get past without having this little extra functionality added to the macro actions first. :-/
That depends on what you mean by that. :-)
What I want is to be able to tell a macro to “import the (previously exported) filter file at the following path right now, and apply this filter”.
In other words, I want to automate the action of going into the advanced filter dialog, pressing the “Import…” button, selecting a certain path, clicking “Open…” and then clicking the “Filter” button.
The reason for this is that I want to be able to create “default filters” for arbitrarily many different files in my computer, in a generic way. As soon as I open any file in my computer, my macro will find the correct filter file for this specific file (based on its path), and then immediately import and execute this filter.
The reason for not storing the entire filter inside the macro itself is that the filters need to be possible to update often and fast, and by several different users, and that creating new such default filters for new files should be as simple as exporting a filter to the corresponding path for that file, rather than recording a macro for it, and with the corresponding automation implemented in EmEditor of also the export filter operation, this will also be as simple as the press of a hotkey for my macro!
So, my goal is the have on hot-key in EmEditor for “apply the default filter for the currently open file”, and another hot-key for “save the current filter as the default filter for the currently open file”, and for this to be possible I need to be able to automate the above mentioned functionality.
Is there also any way to automatically highlight the matching parenthesis to the one that the cursor is currently at (i.e. without actually jumping to it)?
This is a very common and useful feature in many popular code editors, and I would really love to be able to use it in EmEditor too!
In the last few versions of EmEditor, I have found fewer “completely new features” than in previous versions (although of course the improvement and “polishing” of existing features is also very welcome!), so maybe this would be a good time to consider adding this “Navigation points” feature (let’s not confuse them with your excellent “bookmarks” feature at all, let’s call this entirely new feature for example “Navigation points” instead!)?
It really shouldn’t be that massive implementation-wise, but it would mean a LOT efficiency-wise for many users, including me. And again, several popular editors have had this for ages, for example all Borland/Embarcadero code editors (Delphi, C++ Builder etc) and also the popular IntelliJ suite, plus many, many more.
So pretty please with sugar on top, couldn’t you consider this for an upcoming feature update? :-)
I have a pretty good guess for why you fail to reproduce it. :-)
When entering the filter strings manually, it is impossible to enter a raw TAB character (since this will only cause the GUI focus to change to the next control), BUT when doing it from a macro it can be done, without the TAB character being escaped!
More specifically, I do like this (which is part of my normal workflow):
I first select some text containing (among other things) a TAB character, and then execute a macro constituted by the following line:
document.Filter(document.selection.Text, 0, eeFindKeepPrevious | eeFindNegative);
You will then clearly see an unescaped TAB character in the filter list inside the EmEditor GUI, and it will also tag along to the export file in case of a filter export, in turn messing up the structure of the TSV file produced by such an export, and consequently making these lines of the export file impossible to re-import.
So, the solution would then seemingly be to make sure that special characters like TAB are automatically escaped also when using macros to add filter levels containing them.
Super, and thanks for being so responsive with feature suggestions!
I’ve tested it now and it works fine for me!
PS.
The launch info post you are referring to above first mentions version 14.8.0 beta 1 (also in its URL), but the actual download links inside it (and even the about box inside the actual downloaded software) says “14.7.901 beta 1”. The new features are there though, so it’s seemingly not just the wrong download URL.Hello Mr Emura,
Yes, they are indeed very much in common use in the world of web applications and web server logs, so it would be really great if you could support this!
Thanks for considering this!
After a quick test I can confirm that the following one-line macro now indeed seems to accomplish exactly what I was after:
document.Filter(document.selection.Text, -1, eeFindKeepPrevious | eeFindNegative);
Thanks a lot!!!
Thanks again for your reply Mr Emura,
First of all, I am much aware of the delicate balance between functionality and simplicity in situations like this (I’m a developer myself), so I do indeed understand your hesitation about more functional but at the same time more complex solutions, just so you know.
About the “refresh” operation, it was apparently just a bad choice of words from my side (I didn’t know there was already another macro operation with that name). So let’s call it “ForceFilterExecution()” instead in my example above. All I meant was that one solution to the performance problem would be to make the default behavior of the “Filter()” command to never perform any filtering until the macro completely exits, and then offer a new macro function called something like “ForceFilterExecution()” that people could execute from the macro if they really need it to perform the filtering in the middle of the macro after all.
As a developer, I do understand though that there would be users that don’t know about this that would complain and report it as a bug etc. Therefore it might be best to just keep the “eeFindContinue” flag too, and make these two flags possible to use in the same call. As long as the “eeKeepPreviousFilterLevels” flag is included you keep any currently existing advanced filter levels, and as long as the “eeFindContinue” flag is included you don’t perform the filtering right after the call, but otherwise you do, just like it is currently implemented (a more descriptive name for the “eeFindContinue” flag would then perhaps be “eePostponeFiltering” or something like that).
The core problem with the current design is that both of these separate aspects (that is “keep pre-existing filter levels” and “perform filtering immediately after the Filter() call”) are forced into one single flag, which leaves some combinations of these two aspects impossible to implement, while still being possibly desirable (as in my exact situation for example).
Finally, you ask the following:
Can you please describe why you need the “eeKeepPreviousFilterLevels” flag instead of the eeFindContinue flag?
To answer this as efficiently as possible, I reply with the following counterquestion: If I want to make a macro that adds a new filter level to the currently existing filter levels at the point when the macro is executed (i.e. just like I describe that I want to do in my original post in this thread), how could I do this by only using the “eeFindContinue” flag? The first “Filter()” call in the macro will always clear all the current filter levels (since that flag only instructs what to do with the subsequent “Filter()” calls, but not the previous filter levels), while the “eeKeepPreviousFilterLevels” flag is able to specify also what to do with filter levels that already existed when the macro was executed.
Again, the real world situation I need to work with is the following:
I’m working with e.g. a web server log file, and I would then like to be able to select a certain string on some line in the text file, and then use a hotkey to execute a macro of mine that would add the selected string as a negative filter level in the Advanced Filter (and also immediately apply this newly extended advanced filter), thus removing all lines containing that string in the currently displayed file contents (that is, in addition to any previously filtered out lines, which should also remain removed). I would then continue to manually inspect the resulting contents, after which I would want to be able to repeat the same procedure again and again until all “uninteresting” log entry types have been removed, leaving me only with the few interesting “needle in the haystack” lines of interest.
Or to put it even more simply, I need to be able to:
- Add a new advanced filter level.
- Manually inspect the resulting filtered contents.
- Add a new advanced filter level on top of the existing ones (by calling my macro).
- Manually inspect the resulting filtered contents.
- Add a new advanced filter level on top of the existing ones (by calling my macro).
- Manually inspect the resulting filtered contents.
- Add a new advanced filter level on top of the existing ones (by calling my macro).
- … etc
But since there is seemingly currently no way to instruct the macro to keep any pre-existing macro levels when I call the “Filter()” function the first time in a macro, this is currently impossible. With the “eeKeepPreviousFilterLevels” flag it would be possible to do exactly that though!
In summary, a solution that would both close this functional void in the macro API while at the same time prevent any performance problems is to:
- Add a “eeKeepPreviousFilterLevels” flag.
- Keep the “eeFindContinue” flag (possibly even rename it to “eePostponeFiltering”, in order to make it more clear that it only controls that aspect and not the aspect of keeping pre-existing filter levels in any subsequent call), and also make it possible to use it in the same “Filter()” call as the “eeKeepPreviousFilterLevels” flag, as described in more detail above in this post.
And again, the core problem with the current design is that both of these separate aspects (that is “keep pre-existing filter levels” and “perform filtering immediately after the Filter() call”) are forced into one single flag, which leaves some combinations of these two aspects impossible to implement, while still being possibly desirable (as in my exact situation for example).
Thanks for the explanation! I understand what you’re saying, but luckily there are several good solutions for it, where the best one is probably to never actually refresh the filter until a macro exits completely (or, in the most likely quite rare special-cases where it is really needed, a special “ForceFilterRefresh()” method that you can provide is called explicitly from within the macro).
It would be really great if you could do either that, or just implement the “eeKeepPreviousFilterLevels” flag (in addition to “eeFindContinue” that is), as you so kindly offered in your last post, because otherwise the “incremental filtering” that I need won’t be possible to implement at all with macros, which would be a real shame, and something that probably many other people than me would miss too in the long run.
Thanks again, really looking forward to the next update now! :-)
Oh, and also please note that in order to get this to work in a coherent fashion, you might need to add another flag along the lines of “eeKeepPreviousFilterLevels”, since it will otherwise be impossible for a macro to know if it should keep any pre-existing filter levels when executing its first Filter() command. Actually, it would be more logical to completely switch out the “eeFindContinue” flag for such a “eeKeepPreviousFilterLevels” flag, which would then solve this problem without having to increase the total number of flags at all.
Here follows an example to make clear what I mean. Imagine that you want to make two different macros:
1.
A macro that will add two new levels to the currently pre-existing advanced filter levels.2.
A macro that will clear any current pre-existing advanced filter levels, and then add two new filter levels.As far as I can see, it is impossible to make this distinction using the current flags? Both of these macros would just consist of two lines like follows:
document.Filter("FirstLevelFilterString", -1, eeFindContinue); document.Filter("FirstLevelFilterString", -1);And this can only result in either the previous filter levels being cleared in both cases (which is the behavior of the current EmEditor version), or the previous filter levels being preserved in both cases, right?
If you instead were to switch out the “eeFindContinue” flag for a “eeKeepPreviousFilterLevels” flag, the two macros would instead be possible to implement as follows, and both of them would work according to their individual specification as stated above:
1.
document.Filter("FirstLevelFilterString", -1, eeKeepPreviousFilterLevels); document.Filter("FirstLevelFilterString", -1, eeKeepPreviousFilterLevels);2.
document.Filter("FirstLevelFilterString", -1); document.Filter("FirstLevelFilterString", -1, eeKeepPreviousFilterLevels);As far as I can see, there also wouldn’t be any other negative consequences or losses of functionality from dropping the “eeFindContinue” flag and replacing it with the “eeKeepPreviousFilterLevels” flag. Right? Or am I somehow mistaken?
I see. The problem is that this design of the Advanced Filter macro interface makes is impossible to perform incremental filtering (i.e. adding one filter level at the time while viewing the results inbetween), doesn’t it?
What I want to be able to do is to filter out all the lines containing some certain string, then review the results, then filter out all the lines containing some other certain string in these, then review the result, then… See what I mean?
This would either require some macro operation of the kind “document.FilterAddLevel(…)” (which would preserve the current advanced filter, while still executing it as soon as the given new filter level has been added to it) or another command like “document.FilterExecute()” which could be used inbetween “Filter()”-calls that have the “eeFindContinue” flag set, right? Because as it is right now, either the filter is reset, or not executed at all if I try to add filter levels incrementally like this, which in both cases makes it impossible to perform incremental filtering?
Or is there some clever solution that I’m missing?
I just created a macro in order to accomplish what I described in my original post in this thread that I wanted to do, using the calls you mention here above (and also by looking more in the help for additional flags etc). I now have a macro containing only this line:
document.Filter(document.selection.Text, -1, eeFindContinue | eeFindNegative);and I have also connected a shortcut key combination for this.
When selecting some text and then calling this macro from the shortcut key though, the filter level is indeed added to the Advanced Filter dialog, but it is still not applied to the text contents I’m currently working with?
How can I “execute”/apply the filter from the macro too? (as you can understand, it’s of course not much use to be able to create the filter from a macro if I still have to go into the Advanced Filter dialog manually to press the Filter button afterwards)
PS.
Lately, your forum has been VERY slow when processing login requests. It can take 10-60 seconds to complete a login, and many times it just times out completely. Today I had a very hard time logging in at all, getting only timeouts for very many tries until it finally let me in on like the tenth try or so. Please take a look at this if possible.Thanks!
Oh, and you might want to make the macro recording functionality correctly record Advanced Filters operations too by the way. One of the other things I tried before to get hold of the macro calls for the advanced filter was to record a macro when I applied advanced filters, but all it got was recorded mouse clicks and keystrokes.
Excellent!
But where can I find a reference documentation for the macro functionality of EmEditor? I tried to download the PDF manual but it was not there, and I also tried to look in the online help (https://www.emeditor.com/help/macro/document/index.htm), but I cannot find any mention of the “Filter” functions there either?
