AquaMail Forum
English - Android => Development builds => Topic started by: Kostya Vasilyev on April 23, 2016, 12:40:56 am
-
https://www.aqua-mail.com/download/AquaMail-market-1.6.2-dev3.2.apk
---
+ Many bug fixes in message list, more or less related to Undo
+ Workaround for server search @zoho
+ Made unread badge work again on Sony + 6.0
+ Background (fill) color in rich text editor
---
+ Много исправлений в списке сообщений, более или менее связанные с функцией отмены
+ Обход ошибки поиска на сервере @zoho
+ Снова работает счётчик на иконке на Sony + 6.0
+ Цвет фона (заливки) в редакторе сообщений
-
I have experienced no issues with this release; from my perspective appears to be a RC candidate. :)
I do have a late request: any chance 'search headers' can be tweaked to handle sender email address (From: name <email>), specifically my email? At present it returns no results. If I switch to a full text search I get items I sent plus any forwards and replies that contain the target string.
Rational: AquaMail routinely crushes the hidden 'sent' label on Gmail messages when items are moved into folders. As one would expect these items no longer display as 'sent' in any Gmail aware client. This has been discussed before but deemed an unfortunate characteristic of Gmail's organizational methodology (eg: labels vs folders) in hybrid environments.
The only fix I have been able to devise is to expand every conversation under All Mail, identify the items that I sent (originated/forwarded/replied), individually tick each one and then perform a 'move to sent' operation. Since the move action is being initiated from All Mail the item simply acquires the 'sent' label and isn't actually moved to another folder (since AquaMail lacks a 'copy' function).
A search function that permitted quick identification of all items I sent would streamline the above process as 'select all' could be used on all items found followed by 'move to folder'. Still a work-around to restore the hidden 'sent' label but must less time consuming.
It should be noted that none of Google's properties can repair/restore the missing 'sent' label. Only AquaMail and other clients that permit moving/copying individual messages (vs entire conversations) to the sent folder.
Yes - this is a request born out of frustration and really unrelated to the current beta. Just needed a place to vent and didn't want to expose dirty laundry in the main forum threads. Thanks for listening. :)
-
Re: search headers
The actual IMAP server search command includes clauses for FROM, TO, CC, BCC and SUBJECT (and the condition is OR).
Re: Gmail labels
As I'd mentioned before, I don't have a solution for Gmail labels. Sorry (again).
-
Re: search headers
The actual IMAP server search command includes clauses for FROM, TO, CC, BCC and SUBJECT (and the condition is OR).
Re: Gmail labels
As I'd mentioned before, I don't have a solution for Gmail labels. Sorry (again).
Understand 'no solution' to Gmail labels; not asking for that. Looking for workarounds given current constraints and unintended side effects (eg: crushing labels).
Do you know the syntax for IMAP keyword searches in header fields? I have tried a ton of variations that include 'FROM' but no joy. Hoping to stumble upon some documentation but perhaps you know from experience. Or (typical of many Google offerings) they don't conform to specs.
-
Re: IMAP search syntax:
AquaMail sends "header searches" like this:
[IMAP.2270] I Sending: kman35 SEARCH CHARSET US-ASCII OR FROM {25+}
I Sending search literal
I Sending: (OR TO {25+}
I Sending search literal
I Sending: (OR CC {25+}
I Sending search literal
I Sending: (OR BCC {25+}
I Sending search literal
I Sending: SUBJECT {25+}
I Sending search literal
I Sending: )))
Where the {25+} indicates the following "search literal".
Official docs:
https://tools.ietf.org/html/rfc3501#section-6.4.4
In all search keys that use strings, a message matches the key if
the string is a substring of the field. The matching is
case-insensitive.
"Full text" search does this instead:
[IMAP.2270] I Sending: kman57 SEARCH RETURN (ALL) CHARSET US-ASCII TEXT {4}
[IMAP_RAW.2270] I Data is <12>:
I + go ahead
[IMAP.2270] I Sending search literal
So the criteria are different, as can be expected. Actual search in both cases is handled by the server.
Re: Gmail labels and Sent
My personal "workaround" is to not move any Sent messages, can't imagine why I'd want to.
The account (@gmail) has ~36,000 messages in Inbox and ~28,000 messages in Sent.
But that isn't what you wanted to hear, is it? :)
-
re: AquaMail sends "header searches" like this:
I'll play around some more with this additional information. Not immediately sure how it will help but sometimes takes a while for new info to ooze through the concrete that encircles my peanut brain. :)
re: My personal "workaround" is to not move any Sent messages, can't imagine why I'd want to.
Heavens no! I'm simply filing completed conversations from the inbox which I use as a task list. In most (albeit not all) cases when I move the conversation into a folder the hidden 'sent' label gets crushed. Really a very natural thing to do. I raised this before but another voice stated they didn't want to see messages in the 'sent' folder once moved into a storage folder. To me 'sent' and 'all mail' are parallel views of existing folder trees. It should not be an either/or decision. I think there is a perception I am doing weird/wacky things that are one-offs of how real people manage their mail. Really not the case but whatever ...
-
Re: I'll play around some more with this additional information
Those are actual IMAP commands used in the code. Not something you will (or can) enter in the app's UI.
I'm saying: there is but one way for the app to specify these (header related) criteria to the server, and then it does what it does, the app gets back the list of matches (as determined by the server) and loads and shows those messages.
Re: filing conversations
Perhaps there should be some setting to only "move" or "archive" the incoming type messages, leaving the sent messages untouched.
* when the move / archive is triggered from an incoming type folder.
-
re: Those are actual IMAP commands used in the code. Not something you will (or can) enter in the app's UI.
Yeah - that's what I thought but wanted to make sure there wasn't a way to enter them somewhere in the app before making a fool of myself. :)
re: there is but one way for the app to specify these (header related) criteria to the server
Perhaps tick-offs to indicate field(s) to search but that goes asymptotic pretty quickly with multiple fields, conditionals (AND, OR), groupings, etc. Massive overkill.
re: Perhaps there should be some setting to only "move" or "archive" the incoming type messages, leaving the sent messages untouched.
Seems like that could get weird quick if messages are subsequently refilled...possibly multiple times (eg: inbox->folderX->folderZ->folderW). Could you reliably maintain the hidden sent label through the conversations journey?
An alternative might be to enforce the sent label if the originating email address in identified in the header matches any of the accounts defined to Aquamail. Believe that is the way Gmail does it; you don't get a choice (happens automagically). Of course, that opens the door to complaints if someone retires an email address then complains all their sent mail "vanished". And you would need to handle mail sent from Aqua and other clients. Ugh ...
-
Re: Perhaps tick-offs to indicate field(s) to search but that goes asymptotic pretty quickly with multiple fields, conditionals (AND, OR), groupings, etc. Massive overkill.
Since 1.6.1 (previous stable) you can search on headers only or also include body text. That's the button on the right in the search bar (next to the "X" close).
Re: sent messages
An alternative might be to enforce the sent label if the originating email address in identified in the header matches any of the accounts defined to Aquamail.
And then it's have to be a special case too for messages visible in incoming type folders. Seems that no matter what, this gets messy quick.
-
re: you can search on headers only or also include body text.
Yes - I am familiar. But since it searches multiple fields it also catches incoming items (or any item where target string appears in any of the 5 fields that are searched). In this example I am only interested in searching the FROM address which would identify items that I sent regardless of mail client. The results are nearly identical as when doing a full text search albeit are returned more quickly.
-
Re: I am only interested in searching the FROM address
Oh. I'm finally starting to understand what you meant (it's not my fault for being tardy, it's the Jameson's).
-
Re: It's a strict form of "search by sender".
Yes, I finally understood.
Re: You could limit the search in the swiping action to "FROM" field.
You mean a whole new swipe icon / action? Or change the how the current one works?
-
Hmm... That's an interesting proposal, maybe it should include all "address" type fields, but no SUBJECT (it does now).
-
Re: "Find by sender" is linked to FROM (in my opinion). "Find by recipient" could be search in TO, BCC etc.
There is but one swipe action for "find by <sender / recipient> whatever you call it".
So you ARE proposing a third kind of search.
-
re: it's the Jameson's
I'm throughly outclassed being a Tincup slouch. Same effect...just takes a bit longer :)
-
This would be third way to search (I mean in the back-end code): 1) the current "full text search" 2) the current "headers search" and 3) this new "find by FROM only"
( although I think it would be useful to include CC / BCC here too )
-
I'm suggesting to keep the only swiping action called "Find by sender" in English, and transform its action to limit the search to FROM field.
That's all, without any other change ;)
This might be doable if starting from a blank sheet but the existing search function has been out there for awhile. Changing its focus would undoubted upset some while pleasing others. I happen to like the breadth of the current swipe search...although sometimes it doesn't exactly meet my need, just like any other type of 'canned' search.
A variation might be to include several different search options under 'swiping'. One might be a narrow version of 'Find by sender' encompassing only the FROM field while a second might have a broader focus. I think both have their place. Danger is if requests start rolling in for other variations. Not sure that would happen as long as a broader focus search remained. The search by sender is somewhat unique as it is a frequent point of interest in email.
-
re: although I think it would be useful to include CC / BCC here too
That would be 'search by recipient' which is different than 'search by sender'. The former should include TO/CC/BCC, the latter just FROM.
-
Re: That would be 'search by recipient' which is different than 'search by sender'. The former should include TO/CC/BCC, the latter just FROM.
Yes of course, but it's just not defined very well right now, esp. if you consider the translations.
-
re: esp. if you consider the translations
Dammit - we should all standardize on one language!! Some lost island variant that no one speaks so we all have the same learning curve. :)
-
Re: Dammit - we should all standardize on one language!
I humbly propose it should be *two* not one :)
Joking aside, the definition of "search by sender" is kind of fuzzy right now, is it really "sender" or "recipient" (anyone that a message was sent to, including CC / BCC).
-
re: the definition of "search by sender" is kind of fuzzy right now, is it really "sender" or "recipient" (anyone that a message was sent to, including CC / BCC).
Maybe skip the translations and simply list the raw field names which I believe are standardized:
- search by: FROM (sender)
- search by: TO/CC/BCC (recipient)
- search by: SUBJECT
- search by: DATE (today)
Just throwing out ideas to see what sticks. Not proposing any of the above as 'must haves' and promise not to whine if none of it materializes. Did I mention how useful 'search by sender' would be ...
(Sorry...getting late. Begging off for awhile; will pick this up later if there are additional posts)
-
I'm not opposed to the idea in general (of making search even more flexible, by "even more" I mean that even the current "full text" vs "headers only" seems quite useful to me).
However, I don't want to end up with a really messy UI, or with unexpected (from the existing users' point of view) changes.
-
re: although I think it would be useful to include CC / BCC here too
That would be 'search by recipient' which is different than 'search by sender'. The former should include TO/CC/BCC, the latter just FROM.
Exactly, that's what I expect: "search by sender" limited to FROM field.
Dave:
Thanks for mentioning that 'search by sender' is a very useful feature.
-
And "sender" vs. "recipients" is like I said kind of fuzzy if you consider the translations -- or even in one language, to me, the distinction is only there if I consciously think about it (but maybe that's just my pea sized brain).
-
re: My personal "workaround" is to not move any Sent messages, can't imagine why I'd want to.
Heavens no! I'm simply filing completed conversations from the inbox which I use as a task list. In most (albeit not all) cases when I move the conversation into a folder the hidden 'sent' label gets crushed. Really a very natural thing to do. I raised this before but another voice stated they didn't want to see messages in the 'sent' folder once moved into a storage folder. To me 'sent' and 'all mail' are parallel views of existing folder trees. It should not be an either/or decision. I think there is a perception I am doing weird/wacky things that are one-offs of how real people manage their mail. Really not the case but whatever ...
Being that "another voice", I would chime in.
I don't know if your work flow is "one off" or not. (Actually, I suspect not that many people do like you do.) But in any case, I don't think you are doing something wrong. It is your work flow, - and you are trying to adapt the tools you are using to it. I understand that.
Unfortunately, the "standard" general-IMAP-based tools, such as Aquamail, are not designed to deal with Gmail peculiarities that you are used to rely on.
I perfectly understand your need to move messages from "Sent" to a specific folder with the rest of the conversation. I frequently do that too. And I do not understand why Kostya "can't imagine why I'd want to":
My personal "workaround" is to not move any Sent messages, can't imagine why I'd want to.
So, in that regard, I think Kostya is wierd. ;)
Moreover, I think everybody who uses Aquamail not the way I do is weird and wacky. ;D 8)
In any case, I appreciate your reasonable attitude that includes listening to other opinions even when you disagree with them.
Now, back to your original question about the search (I understand how that would help in your workaround). Please, excuse my getting in the middle of the conversation, - but it seems to me that Kostya may have missed the actual problem you experience:
I do have a late request: any chance 'search headers' can be tweaked to handle sender email address (From: name <email>), specifically my email? At present it returns no results. If I switch to a full text search I get items I sent plus any forwards and replies that contain the target string.
From Kostya's post about headers search implementation, it looks like the header search should look for the "From:" field, but you are saying in your case it is not finding messages with you as the sender.
At first, that sounds strange. On another hand, the search for all sender/recipient headers for your address should return all messages, except those where your address was originally and Bcc:, and hence wouldn't show up at all, except for "Received" headers (which are not searched).
I just checked, - and seems to work in my case: it is not just the "From:"
So, I see two ways how the fact that you don't get anything found can be explained:
1. you are making some typo.
2. the header search is not working on your server
3. Aquamail doesn't like You and Your e-mail address. ;)
I'd suggest you to try searching for some other, more simple header that is definitely there. (Try just the "user" portion of user@domain)
However, it seems to me that even if this search worked for you, it wouldn't help you, as it should find messages sent to you as well, as explained above.
PS. Oops...
Warning - while you were typing 23 new replies have been posted. You may wish to review your post.
Sorry, I have to go now, and don't have time to review, - so I'll leave the post as is.... even though all of this might have been discussed.
-
Re: Moreover, I think everybody who uses Aquamail not the way I do is weird and wacky
That was *my* line!
Re: At present it returns no results.
Yes, I completely missed this and then the conversation moved in a different direction.
THANK YOU
So, Davey126, what *do* you do to make the server not find anything? :)
-
So, Davey126, what *do* you do to make the server not find anything? :)
He's searching for "From: user@server" instead of "user@server" ;)
You are right! Overspecification - that's what wana-be-geeks do. As a budding geek I tried to develop an equation describing the optimal curve for arcing the petrol hose to the fuel port on my first ride. Won't tell you where the nozel ended up but I decided to lay off the cigs for a few days. Sometimes eyeballing it is a better approach.:)
Tall tales aside, I did try different qualifiers and delimiters in an effort to narrow the search scope. Of course omitting these and just including the target string yields the expected results. Which doesn't produce what I am after: just the emails that I sent (or more generically outgoing mail).
Might be useful to reread post #2 in this thread for the rational behind this request. While searching for a specific sender or recipient is an interesting capability that might be appreciated by a wider audience, my immediate interest is confined to reapplying the hidden 'sent' label so these items appear in the appropriate folder. Baring that need the existing search capabilities which target multiple header fields would be adequate. I can always use the web client if more granularity is needed (although I always prefer to work from AquaMail!)
-
@str - enjoyed your post along with the more personal comments :) :)
@str, @paris geek, @mikeone - one can always count on a thought provoking and productive conversation when posting in this forum! Converging/diverging/reconverging discourse is what brings people to a higher place. A lesson not yet learned by those who seek the sword first. Oh yes, @kostya can play along too. He's coming along nicely, don't you think?
-
I guess from my point of view, we can summarize it like this:
It would be desirable to have even more flexibility in searching, specifically to limit searches to FROM only.
And as @Davey126 already wrote above, there might then be other users who are interested in other narrowed-down cases (e.g. searching by SUBJECT only), so could this be done without turning the UI into some sort of monster?
-
re: could this be done without turning the UI into some sort of monster?
Thoughts:
- post #26 offers one potential implementation that avoids messy input validation as it leverages swipes; just need to add a couple more choices to the dropdown (currently offers 10 options + none). Translations may be the biggest headache.
- another option: allow a single uppercase keyword followed by delimiter (eg: 'FROM:') to be entered as the first term the header search box. If Aqua detects a valid keyword has been entered (SUBJECT, FROM, TO, CC, BCC, etc) it could adjust/narrow the command string sent to the server:
[IMAP.2270] I Sending: kman35 SEARCH CHARSET US-ASCII OR FROM {25+}
I Sending search literal
I Sending: (OR TO {25+}
I Sending search literal
I Sending: (OR CC {25+}
I Sending search literal
I Sending: (OR BCC {25+}
I Sending search literal
I Sending: SUBJECT {25+}
I Sending search literal
I Sending: )))
A simple FAQ (possibly toast) could guide users to valid keywords and allowed syntax. In this scenario the UI remains largely untouched unless searching by header. A more advance presentation would allow picking keywords from a list. While convenient I think this adds unnecessary UI complexity for a feature arguably targeted at more advanced users. As a point of reference the browser Gmail client take this approach for more advanced searches (https://support.google.com/mail/answer/7190?hl=en (https://support.google.com/mail/answer/7190?hl=en)). Seems like a reasonable compromise and avoids building a complex search dialog.
Well - those are my silly ideas. Can't wait to see what you and others come up with! And yes, I do realize in the end nothing may change if the perceived benefits don't outweigh the added complexity.
-
Yes, #26 is the proposal to add a third kind of search.
-
Kostya,
I just have noticed that the Undo feature will not appear when using "Delete all".
-> You know, the option if the user long press on "Deleted" or "Spam" folder.
I think the Undo feature would be very useful especially for this case.
-
Yes, correct, no Undo for Delete all. But there should be a confirmation (unless turned off).
-
Yes, correct, no Undo for Delete all. But there should be a confirmation (unless turned off).
Yes, there appears a confirmation window if activated in settings (I assume that this option is / should be activated by default)
-
Yes, confirmation are enabled by default.
( it just has to do with Delete All dealing with too many messages, potentially some never seen by the app at all )
-
Yes, confirmation are enabled by default.
( it just has to do with Delete All dealing with too many messages, potentially some never seen by the app at all )
Okay, I understand. Thanks for your additional explanation.
-
- another option: allow a single uppercase keyword followed by delimiter (eg: 'FROM:') to be entered as the first term the header search box. If Aqua detects a valid keyword has been entered (SUBJECT, FROM, TO, CC, BCC, etc) it could adjust/narrow the command string sent to the server:
I don't have a strong opinion, but let me offer my thoughts, why that might not be a good idea.
1. While it could be a powerful way, it seems like a somewhat "bulky" for a mobile UI, where the paradigm is to minimize typing, especially where it must be so precise. And if it is not precise - that's a cause for frustration.
2. IIRC, in SMTP and IMAP specifications "From", "To", etc. are case insensitive.
So, here you create the case where it is different (at least for that small portion of Aquamail users who are familiar with those specs). Besides, with otherwise case-insensitive search, it could also be rather confusing.
For super-geeks: ;D
3. If one were to choose the specialized search language, - one can base it on e.g. Ovid search syntax (used for 20+ years in bibliographic engines):
http://resourcecenter.ovid.com/site/help/documentation/ospa/en/syntax.htm
So, it would be something like
Davey126.from. (in From:)
Davey126.to.cc. ( in To: or Cc:)
Davey126.from. or kmansoft.to. (From Davey126 or To kmansoft)
(Ducking out before it's too late.) 8)
-
- another option: allow a single uppercase keyword followed by delimiter (eg: 'FROM:') to be entered as the first term the header search box. If Aqua detects a valid keyword has been entered (SUBJECT, FROM, TO, CC, BCC, etc) it could adjust/narrow the command string sent to the server:
I don't have a strong opinion, but let me offer my thoughts, why that might not be a good idea.
1. While it could be a powerful way, it seems like a somewhat "bulky" for a mobile UI, where the paradigm is to minimize typing, especially where it must be so precise. And if it is not precise - that's a cause for frustration.
2. IIRC, in SMTP and IMAP specifications "From", "To", etc. are case insensitive.
So, here you create the case where it is different (at least for that small portion of Aquamail users who are familiar with those specs). Besides, with otherwise case-insensitive search, it could also be rather confusing.
All valid points IMO. I suggested case sensitivity to help distinguish keywords from the search argument but that could easily accomplished positionally where only the first word entered was considered as a potential search modifier. I don't think there is a need offer multiple keyword support (eg: this OR that) in the first iteration - or ever for that matter! As for typing most of the keywords are short (2-5 characters) and the longer search argument can be inserted via paste. Not ideal - but perhaps a reasonable compromise.
-
Q: Are the changes in 1.6.1.5-17 baked into 1.6.2-dev3.2? I'm (of course!) curious what's in the former but can wait for GA if relatively minor.
-
Re: changes in 1.6.1.5-17 baked into 1.6.2-dev3.2
Not yet.
Will be in 1.6.2-dev4, which I'm planning to post here (and as first Google Play "beta" for the 1.6.2 branch) later tonight. It's only 11pm :)
The most recent fix there is for a specific issue with Push mail + using it on Deleted folder.
-
Hi - there was an active discussion in the latter half of this thread regarding modification/extension of the embedded search function. Curious if that idea still has legs and if so, whether some portions might make the 1.6.2 development tree.
-
Won't happen in 1.6.2, I've still got a long to-do for this cycle.
I proposed a possible solution for your specific use case (and maybe other users'), but seems like you were not very interested?
-
Won't happen in 1.6.2, I've still got a long to-do for this cycle.
I proposed a possible solution for your specific use case (and maybe other users'), but seems like you were not very interested?
Thanks. Must have overlooked the suggestion (sorry). I'll look back and give it a whirl.
-
re: I proposed a possible solution for your specific use case (and maybe other users'), but seems like you were not very interested?
OK - I'm stumped. Looked back through the thread but could not find a specific workaround. Maybe my 'personal bias' filter is obscuring the obvious ...
-
Your specific use case seems to be: archiving conversations.
The issue: this also moves sent messages to archive folder.
My proposal was: a setting to "not include sent messages when archiving / moving conversations".
-
re: My proposal was: a setting to "not include sent messages when archiving / moving conversations".
That indeed would address the issue in post #2 if it allows archived messages to appear in both the 'sent' and target folders from an Aqua and Gmail client perspective. I suppose this could result in three copies of the a specific item residing in the Aqua database: 'All Mail', 'Sent' and the target folder. Will that create headaches for non-Gmail users and/or those with large databases?
Extending search flexibility then becomes a separate enhancement request to be weighted on its own merits.
-
Re: if it allows archived messages to appear in both the 'sent' and target folders from an Aqua and Gmail
It won't, what I had in mind was not touching (moving) sent messages at all.
-
Unfortunately, that won't do the trick. When I archive or file a conversation I expect the entire conversation to remain visually intact regardless of which mail client I use.
My current methodology is to allow a conversation to mature in the inbox then use a native Gmail property to archive/file the conversation. This preserves the labels and allow the appropriate portions of the conversation to appear in 'All Mail', 'Sent' and the names folder(s) in Aqua.
But sometimes I forget or the conversation resumes at some point after being archived/filed. If I then manage this conversation from within Aqua labels can (but don't always) become munged in a way where the conversation no longer appears under Sent. At some point this gets noticed and I then have to use a laborious process to reapply the 'sent' label without destroying the others. This can only be done in Aqua as none of the Gmail properties permit direct manipulation of the 'sent' label.
Hence the request for search function dedicated to FROM which will uniquely identify all items that I originated since I can no longer trust the sent folder/label.
Although I use conversations as an example the same thing can happen to an individual message - albeit much less likely.
I'm not trying to resurrect the earlier discussion or influence the 'priority' of this request. Just restating (consolidating) the background as it is spread over several posts in this thread.
-
Re: I'm not trying to resurrect the earlier discussion or influence the 'priority' of this request. Just restating (consolidating) the background as it is spread over several posts in this thread.
Thank you for clarifying.