Thanks as usual for being so responsive!
About the methodology you mention above, of always returning an error if trying to write an empty filter, it is indeed a good safety precaution for the situation I mention, but unfortunately it might also have unintended side-effects in other situations.
One such situation is the functionality that I mentioned above that I’m implementing, i.e. automatic “default filters” for a large bunch of files on my disk (every file will have a corresponding filter export file in a certain directory, which will be imported by a macro based on the directory and filename of the currently edited file in EmEditor). In some cases I will therefore want to empty this default filter for a certain file, and if exporting an empty filter has been made completely impossible, as you suggest above, there will be no way to reset such a default filter once it has been exported with any contents at any one point. :-(
If the EmEditor macro capabilities include the possibility to delete arbitrary files on disk (I’m not aware if it does this though?) I could of course just make my macro delete the exported file completely as soon as I try to export an empty filter, BUT, as long as there is also no way for me to inspect if the current filter is empty from a macro (for example by the kind of method I suggest above, querying the current number of items in the filter) I cannot even do that, since the macro would in this case never be able to tell if the filter is empty or not. :-(
So, if you choose to implement the “impossible to export empty filter” functionality (and if it is at the same time possible to somehow delete arbitrary files from disk from EmEditor macros), please do indeed consider adding at least the possibility to query the current number of items in the currently applied filter from inside macros, so that I can implement an “empty filter” special case myself for the situation of wanting to “clear” an exported filter file.
If there is not a possibility to delete arbitrary files from within EmEditor macros though, I cannot see any other way of solving this except somehow making it possible to export empty filters after all, possibly by using some kind of special flag to the export command (for example FORCE_EMPTY_FILTER_EXPORT or similar).
In my opinion, being able to query the number of items in the current filter from macros would make the absolutely cleanest solution though, since the macro developer can then be responsible himself for any extra security measures he might want to implement in order to avoid unintentionally writing an empty filter over an existing filter export file.