Freron MailMate

Comments and changes to this ticket

• 

  benny November 28th, 2016 @ 09:18 AM

  • State changed from “new” to “accepted”

  Thanks for the report, but I don't think it's entirely correct. You are welcome to provide a reference if you think I'm wrong. According to RFC3986:

  URI producing applications should percent-encode data octets that correspond to characters in the reserved set unless these characters are specifically allowed by the URI scheme to represent data in that component. If a reserved character is found in a URI component and no delimiting role is known for that character, then it must be interpreted as representing the data octet corresponding to that character's encoding in US-ASCII.

  The above includes the use of +. I have not specified any special meaning for this character for the mlmt scheme and therefore LaunchBar should encode spaces as %20 (and even if I had given the + character special meaning then it would still be safe to encode a space as %20).

  Now, the implicit request is then that I do assign special meaning to the + character. I guess it's quite rare that users would search for something containing a + character and if they do then they would probably also be likely to search for other reserved characters which would need to be encoded. Also, if applications like LaunchBar assume unknown (query parts of) schemes behave like this then it's also the path of least resistance.

  It'll break backwards compatibility, but that's probably not an issue since the feature has only existed for a short time. My main concern is that I find the use of + redundant and I guess it only exists for historic reasons.

  I'll accept it as a feature request though. You can consider it a bug fix if you like ;)

• 

  benny November 28th, 2016 @ 09:23 AM

  • State changed from “accepted” to “fixcommitted”

• You flagged this item as spam.
  

  Ioa Petra'ka December 6th, 2016 @ 02:10 PM

  I must declare ignorance on whether it is an appropriate substitution for percent encoding. It is certainly something that I have seen done over the years in various tools, and browsers accept it as a substitute for space, so I think it would be a safe assumption to support it. I suppose percent encoding, on the sender side, an actual + as typed in by the user would be the way around needing to include the symbol in a search query. With search engines, the symbol is of course commonly used to force a keyword, such as "+mailmate mail clients", which LaunchBar encodes as:

   %2Bmailmate+mail+clients
  

  I've also mentioned this to the developer of LaunchBar, perhaps he might have a hidden preference I'm not aware of that will force %20 instead of +. In the meanwhile I will happily consider it a feature request. :)

• 

  benny December 7th, 2016 @ 09:57 AM

  In any case, it should already work in the latest public version (r5310).

• 

  benny December 21st, 2016 @ 09:56 AM

  • State changed from “fixcommitted” to “fixreleased”

  [bulk edit]