bug#44604: 27.1; gpg error when language environment is set to Turkish

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Fatih Aydın <fatihaydin138@gmail.com>,
>   fataydin138@gmail.com,
>   44604@debbugs.gnu.org
> Date: Mon, 16 Nov 2020 22:26:02 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I think we need a new infrastructure for solving this.
> 
> Looks that way -- we're using the same functions to handle human-input
> text (i.e., commands like `M-u') as API/protocol text (comparing DIRECT
> and direct by downcasing), and that's problematic.
> 
> So we'd have to add a bunch of functions to handle stuff like this, but
> it seems like a rather daunting task.
> 
> Or we could do something simple, like having a buffer-local variable
> that says "the characters in this buffer are protocol data" and which
> would make the locale the "C" locale?  Hm...  there'd probably be some
> messy fallout from that, too.

I thought about something rather simple: a global variable, let's name
it overriding-case-table, that will be heeded to by the various case
conversions ('downcase' etc.) in preference to any other case-table.
Then commands that need strict ASCII case rules could bind that
variable, or we could use with-case-table macro, without fear that
different buffers will behave in different ways.

I didn't look at the code yet, so maybe this simple idea is not
workable.  But if it is, it should be very simple to implement.