From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: dired-do-find-regexp failure with latin-1 encoding Date: Sun, 29 Nov 2020 20:51:28 +0200 Message-ID: <83eekckndb.fsf@gnu.org> References: <87blfhjr4q.fsf@gmx.net> <83k0u5mjvf.fsf@gnu.org> <877dq5jp51.fsf@gmx.net> <83im9pmh0v.fsf@gnu.org> <106736d6-1732-3f24-15c5-af7bcfd688c6@yandex.ru> <83blfhmdho.fsf@gnu.org> <247a8edb-7b70-ad32-1ba1-43b5458a82b0@yandex.ru> <838sakmccw.fsf@gnu.org> <83o8jgkrxo.fsf@gnu.org> <83im9okrcc.fsf@gnu.org> <9dcc71f4-1d76-1436-67c9-89d7711af42c@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30524"; mail-complaints-to="usenet@ciao.gmane.io" Cc: stephen.berman@gmx.net, emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Nov 29 19:52:15 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kjRny-0007ps-GR for ged-emacs-devel@m.gmane-mx.org; Sun, 29 Nov 2020 19:52:14 +0100 Original-Received: from localhost ([::1]:46798 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kjRnx-00077e-I6 for ged-emacs-devel@m.gmane-mx.org; Sun, 29 Nov 2020 13:52:13 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59394) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kjRnP-0006cm-Cl for emacs-devel@gnu.org; Sun, 29 Nov 2020 13:51:40 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:38372) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kjRnO-0006oJ-Hm; Sun, 29 Nov 2020 13:51:38 -0500 Original-Received: from [176.228.60.248] (port=3366 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kjRnN-0002Wr-Rc; Sun, 29 Nov 2020 13:51:38 -0500 In-Reply-To: <9dcc71f4-1d76-1436-67c9-89d7711af42c@yandex.ru> (message from Dmitry Gutov on Sun, 29 Nov 2020 19:44:57 +0200) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:260024 Archived-At: > Cc: stephen.berman@gmx.net, emacs-devel@gnu.org > From: Dmitry Gutov > Date: Sun, 29 Nov 2020 19:44:57 +0200 > > > Then I think injecting LC_ALL=C into the environment when running Grep > > in this case makes the results more useful? And we can then avoid > > using -a? > > I'm not so sure. LC_ALL=C seems more problematic than -a: > > $ grep ф test.txt > фыва > $ grep -a ф test.txt > фыва > $ LC_ALL=C grep ф test.txt > (nothing) I guess this regression in Grep happened when they "internationalized" the DFA code, sigh... It almost sounds like we should develop our own replacement for Grep, one that doesn't suffer from these problems.