GNU bug report logs - #40702
28.0.50; (what-cursor-position) barfs on non-ASCII char

Previous Next

Package: emacs;

Reported by: Dima Kogan <dima <at> secretsauce.net>

Date: Sat, 18 Apr 2020 21:37:01 UTC

Severity: normal

Tags: fixed

Found in version 28.0.50

Fixed in version 28.1

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Štěpán Němec <stepnem <at> gmail.com>,
 Dima Kogan <dima <at> secretsauce.net>, 40702 <at> debbugs.gnu.org
Subject: Re: bug#40702: 28.0.50; (what-cursor-position) barfs on non-ASCII char
Date: Wed, 30 Sep 2020 05:45:05 +0200
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> I'm not sure if `encode-coding-string/char` should accept a nil argument
> nor how it should treat it, so maybe it's a bug in `what-char-position`
> which should not pass a nil argument here.  So maybe the patch below
> is a good fix?

With

LANG=C LANGUAGE= LC_CTYPE="C" LC_NUMERIC="C" LC_TIME="C" LC_COLLATE="C" LC_MONETARY="C" LC_MESSAGES="C" LC_PAPER="C" LC_NAME="C" LC_ADDRESS="C" LC_TELEPHONE="C" LC_MEASUREMENT="C" LC_IDENTIFICATION="C" LC_ALL=C ./src/emacs -geometry -0+0 -Q  

I can reproduce the bug Dima is seeing, and Stefan's patch fixes the
problem, and seems otherwise unproblematic, so I've pushed it to Emacs
28.

There may be other, more general problems when running under the "C"
locale, but...

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




This bug report was last modified 4 years and 294 days ago.

Previous Next


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