Re: Patch: Support for non-ascii characters in imap group names

[Ted Zlatanov <tzz@lifelogs.com>]

On Sun, 21 Mar 2010 21:26:12 +0100 Martin Stjernholm <mast@lysator.liu.se> wrote: 

MS> Ted Zlatanov <tzz@lifelogs.com> wrote:
>> I haven't seen it (which is probably my fault as I was not paying
>> attention), can you please resend and CC me?

MS> Sure, it's attached below. For me it makes the startup time go down from
MS> 5 minutes or more to 10-20 seconds when I start up Gnus with my ~140
MS> imap groups over a slow mobile network. The thing is that
MS> nnimap-retrieve-groups is very sensitive to high latency. The patch
MS> doesn't remedy that, but it cuts down the number of groups it polls.

The patch looks good and did not break anything for me so I added it.
We're still in CVS land so I didn't commit your changes individually but
as one big patch to avoid 3 separate commits.

>> Interesting.  It sounds like we should get rid of the variable in code
>> completely and always use an accessor function with a "decoding"
>> parameter (so we can get the encoded or the unencoded name).  I don't
>> like the current hidden behavior.  Do you agree?

MS> You're right, using the variable instead in situations where the
MS> encoding isn't relevant is arguably a sort of micro-optimization. It
MS> shouldn't be a significant performance hit to use the function instead.
MS> Or if it is, the right solution would be to optimize in imap.el by
MS> keeping the decoded mailbox name in a variable.

MS> I don't really see the point with adding a "decoding" parameter though.
MS> The utf-7 encoding is just for transport in the imap protocol, and I
MS> can't see any reason why higher code would be interested in that. If
MS> anything, it'd be reasonable to change imap-current-mailbox (and
MS> possibly other variables) to contain decoded mailbox names instead, but
MS> that'd of course have compatibility implications which probably don't
MS> make it worth the hassle.

Only nnimap.el and imap.el use it directly so I think it's OK to change
it.  mail-source.el and nnir.el also may need a slight adjustment for
their use of imap-mailbox-*.  It would simplify the code a little and
make the variable more sensible IMO (but if anyone else disagrees,
please speak up).  If you or anyone else is interested in doing it as
you propose, keeping the decoded variable and encoding it on the fly, go
ahead.

Ted