Enhance filters with NESTED IF-then-ELSE-DO structures
Presently, filters are essentially serial operations and are highly limited. The order of execution nature of filters is also limiting.
A NESTED IF-then-ELSE-DO capability could reduce the NUMBER of filters and eliminate much of the problem of order-of-execution.
For example, for a single sender, I might want to divide email by subject. I might also want to concatenate messages and/or print them OR send them to something like Google Drive
One suggestion I read was the ability to save ATTACHMENTS to disk - this could be included, of course The message BODY and/or attachments could be saved or printed!
Thunderbird would become SO much more powerful if it had such a tool to MANAGE and ORGANIZE and PROCESS mail!
Chosen solution
I am a bit of the choir here Paul. I really do not grasp JavaScript. I am more at home with IBM Skeletons and JES2 with some nice JCL in an MVP environment. I made a leap to Desktop / Server about the time OOP became popular and really have drifted further and further away for cutting code over the last two decades. Now I limit myself to a little scripting and macro writing. Ohh and playing on the Thunderbird support forum.
Read this answer in context 👍 0All Replies (5)
Seen the filtaquilla add-on? I think probably not. https://addons.mozilla.org/en-US/thunderbird/addon/filtaquilla/
It even allows javascript filter actions. Blog posting about the add-on http://mesquilla.com/extensions/filtaquilla/
No, I hadn't seen it, but neither does it come close to my suggestion. I have installed it.
I don't see JavaScript as a good END USER language. It shouldn't be that difficult to incorporate its own, far simpler, and function-specific language. Message filtering is INTENDED for end users, so a filter language would have to target that segment.
Filtering is integral TO a mail client, so any filter language should also be integral to that client.
From my view, ONE filter 'program' could eliminate all other filters, OR would execute sub-filters.
I rather liked a table (array, if you're not an Assembly Language programmer) structure, where table matches contain the "DO" to the corresponding routine.
But the only languages I've written approximating scripting languages are on legacy systems (Tandem TACL, UNIVAC (pre-UNISYS) VS/9 EDT, Stratus VOS command language (very weak and clumsy compared to the other two), and some REXX on OS/390).
Google filter problems and you will find our end users have enough trouble with filters as it is, without giving them access to nested loops and for else or god help us while. Regular expressions are really not for end users either.
The current arrangement where filter are executed in the order they are created causes enough issues and the time I have spent with people who can not grasp the simple fact that they moved the message and therefore the next step of their filter will not execute because the message is no longer there to execute on would be huge.
Filters are a rabbit hole as they are, being above the ability of a significant number of folk as they stand. Without the added options that come with filtaquilla
While you might have issues with JavaScript. It is the language that the Thunderbird user interface is written in, so accessing interface and mail objects is fairly simple from JavaScript all that is needed is the correct scope.
However, to borrow your table analogy, individual filters are the rows with the Do.
My filters undertake a full management of my mail. moving incoming mail to folders, marking it read etc. I have had to add some custom headers for things not in the basic list. like list-post and x-yahoofilteredbulk
What I do not do is try and filter mail based on content. only mail metadata really the header fields that are not encrypted by S/Mime.
I SO wish I didn't have to agree with you, Matt, and thanks for your time.
Unfortunately for me it is QUITE apparent (I DID have SOME encounter with REAL "end users" at work - but most of my experience was with other techs - and THEY could be slow enough!!) what I WANT (and unless I win the lottery and get to PAY someone for custom software, will never get) is a superuser option.
I have an extensive list of filters and, yes, they put things into MANY subfolders.
Also, sadly, I never related to C-like languages. Assembly was like my native tongue and I managed the ones I mentioned quite well. Have no idea why the C-like stuff turns me off so.
Anyway, again thank you for your time. You made me realize why my idea couldn't be a good idea unleashed on the general public!
I still can't fathom WHY most people (including 99% of the mainframe programmers I knew) are clueless when it comes to IT. It was always so simple...
My only (very very very dimly) hopeful alternative relates to a common macro at the CA DMV (systems no longer in operation) used by programmers I enhanced significantly, but which operated 'as usual' when invoked (as everyone did) without parameters, if you see my point.
BIG SIGH as I think of that Google search and all you guys have to put up with - without a dreamer like me!!! Mea culpa.
Chosen Solution
I am a bit of the choir here Paul. I really do not grasp JavaScript. I am more at home with IBM Skeletons and JES2 with some nice JCL in an MVP environment. I made a leap to Desktop / Server about the time OOP became popular and really have drifted further and further away for cutting code over the last two decades. Now I limit myself to a little scripting and macro writing. Ohh and playing on the Thunderbird support forum.