GNU bug report logs - #44604
27.1; gpg error when language environment is set to Turkish

Previous Next

Full log

Message #50 received at 44604 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: fatihaydin138 <at> gmail.com, 44604 <at> debbugs.gnu.org
Subject: Re: bug#44604: 27.1; gpg error when language environment is set to
 Turkish
Date: Tue, 17 Nov 2020 05:30:17 +0200

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: Fatih Aydın <fatihaydin138 <at> gmail.com>,
>   fataydin138 <at> gmail.com,
>   44604 <at> debbugs.gnu.org
> Date: Mon, 16 Nov 2020 22:26:02 +0100
> 
> Eli Zaretskii <eliz <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.