Re: Recent nnir update broke search on office365

[Eric Abrahamsen <eric@ericabrahamsen.net>]

Katsumi Yamaoka <yamaoka@jpl.org> writes:

> On Sun, 01 Feb 2015 14:22:44 +0800, Eric Abrahamsen wrote:
>> `default-process-coding-system', which is bad because:
>
>> 1. That variable doesn't exist in xemacs
>
> How about simply making it a user option (the default is utf-8)?
> utf-8 is available in XEmacsen[1].
>
>> 2. It's probably just the wrong thing to do.
>
> I think so.  The most reasonable solution might be to use
> `default-buffer-file-coding-system' that is used for text
> encoding, however the value of it is unreliable.  I don't know
> how, but on Cygwin `(set-language-environment "Japanese")' sets
> it to `japanese-shift-jis-unix' even though the locale is set to
> ja_JP.UTF-8, for instance.  So is `default-process-coding-system'.
>
> [1] XEmacs 21.4 users need to load Mule-UCS: (require 'un-define)

There's also a variable `network-coding-system-alist' (nil on my
system). As far as I can tell, the "real" encoding system used for
talking to the imap server ought to be produced by a call that looks
like this:

(find-operation-coding-system 'open-network-stream name work-buffer host
service parameters)

Where the other arguments are produced inside of `open-protocol-stream'
aka `open-network-stream'. I tried eval'ing that while edebugging, and
it produced nil, which either means I did it wrong, or just that some
default value is being used instead -- perhaps just the buffer coding
system of the process buffer?

But even if we figure out a reliable way to find the right coding
system, there's still the issue of the imap servers and their various
coding quirks. I'm still surprised that searching for non-ascii terms is
such a difficult thing to do.

Eric