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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 44604 in the body.
You can then email your comments to 44604 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Fatih Aydin <fataydin138 <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 27.1; gpg error when language environment is set to Turkish
Date: Thu, 12 Nov 2020 19:44:35 +0000

[Message part 1 (text/plain, inline)]

When I set Turkish as the language environment, I started to have problems
 with gpg.
I have tried to;
- Change lanuage environment of OS (locale.conf) instead of changing it in
 Emacs, nothing changed.
- Set another languages to see if they also cause problem (Polish and
 Arabic), they were okay. Only Turkish is the problematic one.
The problems I have observed:
- I get this error message when I run package-install:
Error while verifying signature archive-contents.sig:
Command output:gpg: Signature made Thu 12 Nov 2020 01:05:03 PM +03
- When I run org-decrypt-entry, nothing happens. (in English, it works)
In GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.22, cairo
 version 1.17.3)
 of 2020-08-28 built on juergen
Windowing system distributor 'The X.Org Foundation', version 11.0.12009000
System Description: Arch Linux
Recent messages:
Making completion list... [2 times]
Quit
Importing package-keyring.gpg...done
Contacting host: elpa.gnu.org:443 [2 times]
Package refresh done
Failed to download ‘gnu’ archive.
Quit
Type "q" in help window to restore its previous buffer, C-M-v to scroll
help.
Quit
Configured using:
 'configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib
 --localstatedir=/var --with-x-toolkit=gtk3 --with-xft --with-wide-int
 --with-modules --with-cairo --with-harfbuzz 'CFLAGS=-march=x86-64
 -mtune=generic -O2 -pipe -fno-plt' CPPFLAGS=-D_FORTIFY_SOURCE=2
 LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now'
Configured features:
XPM JPEG TIFF GIF PNG RSVG CAIRO SOUND GPM DBUS GSETTINGS GLIB NOTIFY
INOTIFY ACL GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS LIBSYSTEMD JSON
PDUMPER LCMS2 GMP
Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix
Major mode: Lisp Interaction
Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t
Load-path shadows:
None found.
(shadow sort mail-extr emacsbug sendmail help-mode mm-archive message
dired dired-loaddefs format-spec rfc822 mml mml-sec epa derived
gnus-util rmail rmail-loaddefs text-property-search time-date mailabbrev
gmm-utils mailheader mm-decode mm-bodies mm-encode mail-utils gnutls
network-stream warnings url-http mail-parse rfc2231 rfc2047 rfc2045
mm-util ietf-drums mail-prsvr url-gw nsm rmc puny url-cache url-auth url
url-proxy url-privacy url-expand url-methods url-history url-cookie
url-domsuf url-util mailcap epg epg-config finder-inf package easymenu
browse-url url-handlers url-parse auth-source cl-seq eieio eieio-core
cl-macs eieio-loaddefs password-cache json subr-x map url-vars seq
byte-opt gv bytecomp byte-compile cconv cl-loaddefs cl-lib misearch
multi-isearch tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel term/x-win x-win term/common-win x-dnd tool-bar
dnd fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode elisp-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core term/tty-colors frame minibuffer cl-generic
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote threads dbusbind
inotify lcms2 dynamic-setting system-font-setting font-render-setting
cairo move-toolbar gtk x-toolkit x multi-tty make-network-process emacs)
Memory information:
((conses 16 75203 12839)
 (symbols 48 8692 1)
 (strings 32 25959 2065)
 (string-bytes 1 776904)
 (vectors 16 14300)
 (vector-slots 8 207058 16916)
 (floats 8 27 261)
 (intervals 56 3977 2464)
 (buffers 1000 17))
Date: Thu, 12 Nov 2020 22:42:24 +0300

[Message part 2 (text/html, inline)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Fatih Aydin <fataydin138 <at> gmail.com>
Cc: 44604 <at> debbugs.gnu.org
Subject: Re: bug#44604: 27.1;
 gpg error when language environment is set to Turkish
Date: Fri, 13 Nov 2020 10:12:02 +0200

> From: Fatih Aydin <fataydin138 <at> gmail.com>
> Date: Thu, 12 Nov 2020 19:44:35 +0000
> 
> When I set Turkish as the language environment, I started to have problems
>  with gpg.
> I have tried to;
> - Change lanuage environment of OS (locale.conf) instead of changing it in
>  Emacs, nothing changed.
> - Set another languages to see if they also cause problem (Polish and
>  Arabic), they were okay. Only Turkish is the problematic one.
> The problems I have observed:
> - I get this error message when I run package-install:
> Error while verifying signature archive-contents.sig:
> Command output:gpg: Signature made Thu 12 Nov 2020 01:05:03 PM +03
> - When I run org-decrypt-entry, nothing happens. (in English, it works)
> In GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.22, cairo
>  version 1.17.3)

Can you please show a recipe to reproduce the problem starting from
"emacs -Q"?  In particular, please describe how did you set the
Turkish language environment, given that your locale is en_US.UTF-8.

Thanks.

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

From: Fatih Aydin <fataydin138 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: "44604 <at> debbugs.gnu.org" <44604 <at> debbugs.gnu.org>
Subject: Re: bug#44604: 27.1;
 gpg error when language environment is set to Turkish
Date: Fri, 13 Nov 2020 09:10:41 +0000

[Message part 1 (text/plain, inline)]

I have changed my locale back to English before sending the bug report.
Okay I will write the recipe,
Steps to reproduce:
- Start Emacs
- Set language environment to Turkish. (doesn't matter how you do it:
customize menu or use set-language-environment or change LANG variable of
the system) To have the result without a reboot, use
set-language-environment function.
- Run package-install, you will get the error I mentioned. Also before that
error you will see some messages with 'unknown proxy direct' in it.

I have tested this on two different laptops with same OS and the same
internet connection. I got the same result.

Thank you.


On Friday, November 13, 2020, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: Fatih Aydin <fataydin138 <at> gmail.com>
>> Date: Thu, 12 Nov 2020 19:44:35 +0000
>>
>> When I set Turkish as the language environment, I started to have
problems
>>  with gpg.
>> I have tried to;
>> - Change lanuage environment of OS (locale.conf) instead of changing it
in
>>  Emacs, nothing changed.
>> - Set another languages to see if they also cause problem (Polish and
>>  Arabic), they were okay. Only Turkish is the problematic one.
>> The problems I have observed:
>> - I get this error message when I run package-install:
>> Error while verifying signature archive-contents.sig:
>> Command output:gpg: Signature made Thu 12 Nov 2020 01:05:03 PM +03
>> - When I run org-decrypt-entry, nothing happens. (in English, it works)
>> In GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.22,
cairo
>>  version 1.17.3)
>
> Can you please show a recipe to reproduce the problem starting from
> "emacs -Q"?  In particular, please describe how did you set the
> Turkish language environment, given that your locale is en_US.UTF-8.
>
> Thanks.
>

[Message part 2 (text/html, inline)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Fatih Aydin <fataydin138 <at> gmail.com>
Cc: 44604 <at> debbugs.gnu.org
Subject: Re: bug#44604: 27.1;
 gpg error when language environment is set to Turkish
Date: Fri, 13 Nov 2020 14:07:45 +0200

> From: Fatih Aydin <fataydin138 <at> gmail.com>
> Date: Fri, 13 Nov 2020 09:10:41 +0000
> Cc: "44604 <at> debbugs.gnu.org" <44604 <at> debbugs.gnu.org>
> 
> Steps to reproduce:
> - Start Emacs
> - Set language environment to Turkish. (doesn't matter how you do it: customize menu or use
> set-language-environment or change LANG variable of the system) To have the result without a reboot, use
> set-language-environment function.
> - Run package-install, you will get the error I mentioned. Also before that error you will see some messages
> with 'unknown proxy direct' in it.

package-install asks for a package.  Does it matter what package to
select here?  Which package did you try to install when you got the
error?

> I have tested this on two different laptops with same OS and the same internet connection. I got the same
> result.

Thanks, I will look into this soon if no one beats me up to it.

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

From: Fatih Aydin <fataydin138 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 44604 <at> debbugs.gnu.org
Subject: Re: bug#44604: 27.1;
 gpg error when language environment is set to Turkish
Date: Fri, 13 Nov 2020 14:19:00 +0000

[Message part 1 (text/plain, inline)]

No, the package doesn't matter, the error occurs before it asks for a
package.

When you run for the first time (without .emacs.d folder), before
package-install asks for the package name, it installs some files to
.emacs.d (.emacs.d/elpa/archives and .emacs.d/elpa/gnupg folders are
created). This is what normally happens, but with 'LANG=tr_TR.UTF-8' or
'current-language-environment=Turkish' it first prompts:

Emergency (url): Unknown proxy directive: DIRECT

Then the error report comes:

Error while verifying signature archive-contents.sig:

Command output:
gpg: Signature made Thu 12 Nov 2020 01:05:03 PM +03
gpg:                using RSA key C433554766D3DDC64221BFAA066DAFCB81E42C40
gpg: Good signature from "GNU ELPA Signing Agent (2019) <
elpasign <at> elpa.gnu.org>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the
owner.
Primary key fingerprint: C433 5547 66D3 DDC6 4221  BFAA 066D AFCB 81E4 2C40

Additional info: When I try to connect a website using eww, I again get
this message a few more times while the website is loading:
Emergency (url): Unknown proxy directive: DIRECT

On Fri, Nov 13, 2020 at 12:08 PM Eli Zaretskii <eliz <at> gnu.org> wrote:

> > From: Fatih Aydin <fataydin138 <at> gmail.com>
> > Date: Fri, 13 Nov 2020 09:10:41 +0000
> > Cc: "44604 <at> debbugs.gnu.org" <44604 <at> debbugs.gnu.org>
> >
> > Steps to reproduce:
> > - Start Emacs
> > - Set language environment to Turkish. (doesn't matter how you do it:
> customize menu or use
> > set-language-environment or change LANG variable of the system) To have
> the result without a reboot, use
> > set-language-environment function.
> > - Run package-install, you will get the error I mentioned. Also before
> that error you will see some messages
> > with 'unknown proxy direct' in it.
>
> package-install asks for a package.  Does it matter what package to
> select here?  Which package did you try to install when you got the
> error?
>
> > I have tested this on two different laptops with same OS and the same
> internet connection. I got the same
> > result.
>
> Thanks, I will look into this soon if no one beats me up to it.
>

[Message part 2 (text/html, inline)]

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Fatih Aydin <fataydin138 <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 44604 <at> debbugs.gnu.org
Subject: Re: bug#44604: 27.1; gpg error when language environment is set to
 Turkish
Date: Sat, 14 Nov 2020 17:39:11 +0100

Fatih Aydin <fataydin138 <at> gmail.com> writes:

> Additional info: When I try to connect a website using eww, I again get this
> message a few more times while the website is loading:
> Emergency (url): Unknown proxy directive: DIRECT

So it doesn't sound like this has anything to do with GPG, but is a
problem with whatever you're using as an HTTP(S) proxy?

Do you have a step-by-step recipe for reproducing this error, starting
from "emacs -Q"?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Fatih Aydin <fataydin138 <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 44604 <at> debbugs.gnu.org
Subject: Re: bug#44604: 27.1;
 gpg error when language environment is set to Turkish
Date: Sat, 14 Nov 2020 17:09:54 +0000

[Message part 1 (text/plain, inline)]

Yes, you are right Lars, I've also realized that this is an error from
proxy.el file.
I don't use any kind of proxy, the steps are really simple to produce this
error.

Step 1: Run 'emacs -Q'
Step 2: M-x and type 'set-language-environment'. Write the value 'Turkish'.
Step 3: M-x and 'eww'. Try to visit 'google.com' or any website you want.

That's all, you'll get a couple of 'Emergency (url): Unknown proxy
directive: DIRECT'
On step 2, I've tried a bunch of different languages, the only problematic
one is Turkish.

On Sat, Nov 14, 2020 at 4:39 PM Lars Ingebrigtsen <larsi <at> gnus.org> wrote:

> Fatih Aydin <fataydin138 <at> gmail.com> writes:
>
> > Additional info: When I try to connect a website using eww, I again get
> this
> > message a few more times while the website is loading:
> > Emergency (url): Unknown proxy directive: DIRECT
>
> So it doesn't sound like this has anything to do with GPG, but is a
> problem with whatever you're using as an HTTP(S) proxy?
>
> Do you have a step-by-step recipe for reproducing this error, starting
> from "emacs -Q"?
>
> --
> (domestic pets only, the antidote for overdose, milk.)
>    bloggy blog: http://lars.ingebrigtsen.no
>

[Message part 2 (text/html, inline)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Fatih Aydin <fataydin138 <at> gmail.com>
Cc: larsi <at> gnus.org, 44604 <at> debbugs.gnu.org
Subject: Re: bug#44604: 27.1;
 gpg error when language environment is set to Turkish
Date: Sat, 14 Nov 2020 19:51:22 +0200

> From: Fatih Aydin <fataydin138 <at> gmail.com>
> Date: Sat, 14 Nov 2020 17:09:54 +0000
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 44604 <at> debbugs.gnu.org
> 
> Step 1: Run 'emacs -Q'
> Step 2: M-x and type 'set-language-environment'. Write the value 'Turkish'.
> Step 3: M-x and 'eww'. Try to visit 'google.com' or any website you want.
> 
> That's all, you'll get a couple of 'Emergency (url): Unknown proxy directive: DIRECT'

The problem is in url-proxy.el: url-default-find-proxy-for-url returns
"DIRECT", but url-find-proxy-for-url tests for "^direct":

    (cond
     ((string-match "^direct" proxy) nil)

url-find-proxy-for-url binds case-fold-search to t, believing that
this would take care of the case difference, but that is false for
Turkish, because under the Turkish language-environment, we get:

  (downcase ?I) => ?ı

IOW, 'I' downcases into the dotless i.

Does anyone understand why url-proxy insists on using the likes of
"^direct" instead of "^DIRECT", i.e. why it doesn't match the case as
well?

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

From: Fatih Aydin <fataydin138 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 44604 <at> debbugs.gnu.org
Subject: Re: bug#44604: 27.1;
 gpg error when language environment is set to Turkish
Date: Sat, 14 Nov 2020 19:31:56 +0000

[Message part 1 (text/plain, inline)]

To make sure that it will solve the problem, I have applied the solution
you suggested.
Copied the source and changed '^direct' to '^DIRECT' and builded.

The proxy problem is solved, but the package-install gpg problem I
mentioned (Error while verifying signature archive-contents.sig:) is still
there.

Also I found another weird bug related to this:
with English language environment visit 'https://www.google.com.tr' using
eww, you will see the Turkish characters correctly.
with Turkish language environment, do the same thing, you will see weird
characters instead of Turkish characters.


On Sat, Nov 14, 2020 at 5:51 PM Eli Zaretskii <eliz <at> gnu.org> wrote:

> > From: Fatih Aydin <fataydin138 <at> gmail.com>
> > Date: Sat, 14 Nov 2020 17:09:54 +0000
> > Cc: Eli Zaretskii <eliz <at> gnu.org>, 44604 <at> debbugs.gnu.org
> >
> > Step 1: Run 'emacs -Q'
> > Step 2: M-x and type 'set-language-environment'. Write the value
> 'Turkish'.
> > Step 3: M-x and 'eww'. Try to visit 'google.com' or any website you
> want.
> >
> > That's all, you'll get a couple of 'Emergency (url): Unknown proxy
> directive: DIRECT'
>
> The problem is in url-proxy.el: url-default-find-proxy-for-url returns
> "DIRECT", but url-find-proxy-for-url tests for "^direct":
>
>     (cond
>      ((string-match "^direct" proxy) nil)
>
> url-find-proxy-for-url binds case-fold-search to t, believing that
> this would take care of the case difference, but that is false for
> Turkish, because under the Turkish language-environment, we get:
>
>   (downcase ?I) => ?ı
>
> IOW, 'I' downcases into the dotless i.
>
> Does anyone understand why url-proxy insists on using the likes of
> "^direct" instead of "^DIRECT", i.e. why it doesn't match the case as
> well?
>

[Message part 2 (text/html, inline)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Fatih Aydin <fataydin138 <at> gmail.com>
Cc: larsi <at> gnus.org, 44604 <at> debbugs.gnu.org
Subject: Re: bug#44604: 27.1;
 gpg error when language environment is set to Turkish
Date: Sat, 14 Nov 2020 21:48:57 +0200

> From: Fatih Aydin <fataydin138 <at> gmail.com>
> Date: Sat, 14 Nov 2020 19:31:56 +0000
> Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 44604 <at> debbugs.gnu.org
> 
> To make sure that it will solve the problem, I have applied the solution you suggested.
> Copied the source and changed '^direct' to '^DIRECT' and builded.
> 
> The proxy problem is solved, but the package-install gpg problem I mentioned (Error while verifying signature
> archive-contents.sig:) is still there.
> 
> Also I found another weird bug related to this:
> with English language environment visit 'https://www.google.com.tr' using eww, you will see the Turkish
> characters correctly.
> with Turkish language environment, do the same thing, you will see weird characters instead of Turkish
> characters.

The ELisp manual says:

     Some language environments modify the case conversions of ASCII
  characters; for example, in the Turkish language environment, the ASCII
  capital I is downcased into a Turkish dotless i (‘ı’).  This can
  interfere with code that requires ordinary ASCII case conversion, such
  as implementations of ASCII-based network protocols.  In that case, use
  the ‘with-case-table’ macro with the variable ASCII-CASE-TABLE, which
  stores the unmodified case table for the ASCII character set.

I guess we need to use this around forms that implement network
protocols.  At least this doesn't seem to help:

 M-: (with-case-table ascii-case-table (eww "https://www.google.com.tr")) RET

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

From: Fatih Aydın <fatihaydin138 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: larsi <at> gnus.org, 44604 <at> debbugs.gnu.org, Fatih Aydin <fataydin138 <at> gmail.com>
Subject: Re: bug#44604: 27.1;
 gpg error when language environment is set to Turkish
Date: Sun, 15 Nov 2020 20:52:49 +0000

[Message part 1 (text/plain, inline)]

Is there something I can do to help with the process of solving this
problem?
Also do you think that this will solved in the next release?

Eli Zaretskii <eliz <at> gnu.org>, 14 Kas 2020 Cmt, 19:49 tarihinde şunu yazdı:

> > From: Fatih Aydin <fataydin138 <at> gmail.com>
> > Date: Sat, 14 Nov 2020 19:31:56 +0000
> > Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 44604 <at> debbugs.gnu.org
> >
> > To make sure that it will solve the problem, I have applied the solution
> you suggested.
> > Copied the source and changed '^direct' to '^DIRECT' and builded.
> >
> > The proxy problem is solved, but the package-install gpg problem I
> mentioned (Error while verifying signature
> > archive-contents.sig:) is still there.
> >
> > Also I found another weird bug related to this:
> > with English language environment visit 'https://www.google.com.tr'
> using eww, you will see the Turkish
> > characters correctly.
> > with Turkish language environment, do the same thing, you will see weird
> characters instead of Turkish
> > characters.
>
> The ELisp manual says:
>
>      Some language environments modify the case conversions of ASCII
>   characters; for example, in the Turkish language environment, the ASCII
>   capital I is downcased into a Turkish dotless i (‘ı’).  This can
>   interfere with code that requires ordinary ASCII case conversion, such
>   as implementations of ASCII-based network protocols.  In that case, use
>   the ‘with-case-table’ macro with the variable ASCII-CASE-TABLE, which
>   stores the unmodified case table for the ASCII character set.
>
> I guess we need to use this around forms that implement network
> protocols.  At least this doesn't seem to help:
>
>  M-: (with-case-table ascii-case-table (eww "https://www.google.com.tr"))
> RET
>

[Message part 2 (text/html, inline)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Fatih Aydın <fatihaydin138 <at> gmail.com>
Cc: larsi <at> gnus.org, 44604 <at> debbugs.gnu.org, fataydin138 <at> gmail.com
Subject: Re: bug#44604: 27.1;
 gpg error when language environment is set to Turkish
Date: Mon, 16 Nov 2020 18:16:29 +0200

> From: Fatih Aydın <fatihaydin138 <at> gmail.com>
> Date: Sun, 15 Nov 2020 20:52:49 +0000
> Cc: Fatih Aydin <fataydin138 <at> gmail.com>, larsi <at> gnus.org, 44604 <at> debbugs.gnu.org
> 
> Is there something I can do to help with the process of solving this problem?

Since the problem is easily reproducible, I think we can take it from
here, thanks.

> Also do you think that this will solved in the next release?

If you mean 27.2, definitely not.  If you mean 28.1, the next major
release, I hope so.

I think we need a new infrastructure for solving this.

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

From: Fatih Aydin <fataydin138 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>,
 Fatih Aydın <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: Mon, 16 Nov 2020 20:53:00 +0000

[Message part 1 (text/plain, inline)]

To make things clear, the problem is not only with the network protocols.
In org-mode I've realized some variables like #TITLE:, :PROPERTIES: don't
work.
I guess no variable works if it has 'i' in it.

On Mon, Nov 16, 2020 at 4:16 PM Eli Zaretskii <eliz <at> gnu.org> wrote:

> > From: Fatih Aydın <fatihaydin138 <at> gmail.com>
> > Date: Sun, 15 Nov 2020 20:52:49 +0000
> > Cc: Fatih Aydin <fataydin138 <at> gmail.com>, larsi <at> gnus.org,
> 44604 <at> debbugs.gnu.org
> >
> > Is there something I can do to help with the process of solving this
> problem?
>
> Since the problem is easily reproducible, I think we can take it from
> here, thanks.
>
> > Also do you think that this will solved in the next release?
>
> If you mean 27.2, definitely not.  If you mean 28.1, the next major
> release, I hope so.
>
> I think we need a new infrastructure for solving this.
>

[Message part 2 (text/html, inline)]

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Fatih Aydın <fatihaydin138 <at> gmail.com>,
 44604 <at> debbugs.gnu.org, fataydin138 <at> gmail.com
Subject: Re: bug#44604: 27.1; gpg error when language environment is set to
 Turkish
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.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Fatih Aydin <fataydin138 <at> gmail.com>
Cc: larsi <at> gnus.org, 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:22:24 +0200

> From: Fatih Aydin <fataydin138 <at> gmail.com>
> Date: Mon, 16 Nov 2020 20:53:00 +0000
> Cc: Fatih Aydın <fatihaydin138 <at> gmail.com>, 
> 	Lars Ingebrigtsen <larsi <at> gnus.org>, 44604 <at> debbugs.gnu.org
> 
> To make things clear, the problem is not only with the network protocols.
> In org-mode I've realized some variables like #TITLE:, :PROPERTIES: don't work.
> I guess no variable works if it has 'i' in it.

Yes, any such text that needs to be downcased will cause similar
problem in this language environment.

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.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.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, 24 Nov 2020 06:16:14 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

> 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.

Yeah, that sounds like a better solution.  It basically means that all
code that does code conversion (for protocol reasons) will need to be
wrapped with that binding, and there's a lot of it in Emacs -- I'm
guessing there's more code that needs wrapping than needs to be
unwrapped.

Which is a pain.  But I guess just having interactive cases of
`downcase' and friends heed the case table, and otherwise ignore it,
isn't really workable either?  That'd be a lot less code to fix.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #56 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, 24 Nov 2020 17:20:47 +0200

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: fatihaydin138 <at> gmail.com,  44604 <at> debbugs.gnu.org
> Date: Tue, 24 Nov 2020 06:16:14 +0100
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > 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.
> 
> Yeah, that sounds like a better solution.  It basically means that all
> code that does code conversion (for protocol reasons) will need to be
> wrapped with that binding, and there's a lot of it in Emacs -- I'm
> guessing there's more code that needs wrapping than needs to be
> unwrapped.
> 
> Which is a pain.  But I guess just having interactive cases of
> `downcase' and friends heed the case table, and otherwise ignore it,
> isn't really workable either?  That'd be a lot less code to fix.

I think the use cases that need to heed the buffer's case-table are
more than just interactive invocations of those commands.  But we need
to audit the uses, because if it turns out the amount of those who do
need the buffer's case-table is significantly smaller, it is they
which would need to bind something, and not vice versa.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.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: Wed, 25 Nov 2020 07:19:18 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

> I think the use cases that need to heed the buffer's case-table are
> more than just interactive invocations of those commands.  But we need
> to audit the uses, because if it turns out the amount of those who do
> need the buffer's case-table is significantly smaller, it is they
> which would need to bind something, and not vice versa.

Yup.  I'm not sure where to start, though -- it sounds like a pretty
major headache whichever way we do this...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #62 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: Wed, 25 Nov 2020 17:24:18 +0200

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: fatihaydin138 <at> gmail.com,  44604 <at> debbugs.gnu.org
> Date: Wed, 25 Nov 2020 07:19:18 +0100
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > I think the use cases that need to heed the buffer's case-table are
> > more than just interactive invocations of those commands.  But we need
> > to audit the uses, because if it turns out the amount of those who do
> > need the buffer's case-table is significantly smaller, it is they
> > which would need to bind something, and not vice versa.
> 
> Yup.  I'm not sure where to start, though -- it sounds like a pretty
> major headache whichever way we do this...

It could be.  But maybe we will be able to find a simple solution.

I'm thinking about alternatives, but so far I have no better ideas.

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

From: Fatih Aydin <fataydin138 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 44604 <at> debbugs.gnu.org
Subject: Re: bug#44604: 27.1;
 gpg error when language environment is set to Turkish
Date: Tue, 1 Dec 2020 11:06:49 +0000

[Message part 1 (text/plain, inline)]

I will tell you an idea of mine, a new feature that can help users to solve
the problem. Maybe it's silly or not doable.
Let there be a new variable to define file types (according to extension)
and the lang. env. for those file types. For '.el' files, English lang.
env. can be assigned using that variable.
That means the user will have an option to say: 'Always evaluate .el files
using English language' to Emacs.

[Message part 2 (text/html, inline)]

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Fatih Aydin <fataydin138 <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 44604 <at> debbugs.gnu.org
Subject: Re: bug#44604: 27.1; gpg error when language environment is set to
 Turkish
Date: Wed, 02 Dec 2020 11:07:18 +0100

Fatih Aydin <fataydin138 <at> gmail.com> writes:

> Let there be a new variable to define file types (according to extension) and the
> lang. env. for those file types. For '.el' files, English lang. env. can be assigned
> using that variable.
> That means the user will have an option to say: 'Always evaluate .el files using
> English language' to Emacs.

That's not really the issue -- this is always about .el files, but it's
about how to handle text in different contexts.

For instance, you may have a mail buffer with code that's generating
mail headers, so you have a structure that contains

(("MY-NAME-IS" "ASIL"))

and you have code that's supposed to generate, from that, a header that
looks like:

My-name-is: Asıl

The code has to know that the former bit is a "protocol string" and the
latter bit is a "language string".

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Fatih Aydin <fataydin138 <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 44604 <at> debbugs.gnu.org
Subject: Re: bug#44604: 27.1;
 gpg error when language environment is set to Turkish
Date: Wed, 21 Apr 2021 14:42:47 +0300

[Message part 1 (text/plain, inline)]

 I keep encountering this problem with different packages, everything
functions incorrectly, as you can guess. Is there any progress?

On Wed, Dec 2, 2020 at 1:07 PM Lars Ingebrigtsen <larsi <at> gnus.org> wrote:

> Fatih Aydin <fataydin138 <at> gmail.com> writes:
>
> > Let there be a new variable to define file types (according to
> extension) and the
> > lang. env. for those file types. For '.el' files, English lang. env. can
> be assigned
> > using that variable.
> > That means the user will have an option to say: 'Always evaluate .el
> files using
> > English language' to Emacs.
>
> That's not really the issue -- this is always about .el files, but it's
> about how to handle text in different contexts.
>
> For instance, you may have a mail buffer with code that's generating
> mail headers, so you have a structure that contains
>
> (("MY-NAME-IS" "ASIL"))
>
> and you have code that's supposed to generate, from that, a header that
> looks like:
>
> My-name-is: Asıl
>
> The code has to know that the former bit is a "protocol string" and the
> latter bit is a "language string".
>
> --
> (domestic pets only, the antidote for overdose, milk.)
>    bloggy blog: http://lars.ingebrigtsen.no
>

[Message part 2 (text/html, inline)]

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Fatih Aydin <fataydin138 <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 44604 <at> debbugs.gnu.org
Subject: Re: bug#44604: 27.1; gpg error when language environment is set to
 Turkish
Date: Sun, 25 Apr 2021 20:58:11 +0200

Fatih Aydin <fataydin138 <at> gmail.com> writes:

> I keep encountering this problem with different packages, everything
> functions incorrectly, as you can guess. Is there any progress?

There's been no progress in handling the problem in general, but there's
really no reason to just work around the problem by using your proposed
change -- i.e., I changed the regexp from ^direct to ^DIRECT in Emacs
28, which should fix this specific bug.

The more general problem -- separating out handling human-directed text
from protocol-related text -- is a huge problem.  But since this
specific problem is fixed now, I'm closing this bug report.  But we
should probably open a more general thing for the general problem, or
take it to emacs-devel.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #81 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: 44604 <at> debbugs.gnu.org, fataydin138 <at> gmail.com
Subject: Re: bug#44604: 27.1; gpg error when language environment is set to
 Turkish
Date: Sun, 25 Apr 2021 22:03:07 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  44604 <at> debbugs.gnu.org
> Date: Sun, 25 Apr 2021 20:58:11 +0200
> 
> The more general problem -- separating out handling human-directed text
> from protocol-related text -- is a huge problem.  But since this
> specific problem is fixed now, I'm closing this bug report.  But we
> should probably open a more general thing for the general problem, or
> take it to emacs-devel.

Yes, it's a tricky problem, so maybe a general discussion will help
come up with ideas.

Previous Next

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