GNU bug report logs - #40940
27.0.91; project-query-replace-regexp stops too early

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: simenheg <at> runbox.com, monnier <at> IRO.UMontreal.CA, 40940 <at> debbugs.gnu.org
Subject: Re: bug#40940: 27.0.91; project-query-replace-regexp stops too early
Date: Fri, 01 May 2020 18:45:55 +0300

> Cc: simenheg <at> runbox.com, monnier <at> IRO.UMontreal.CA, 40940 <at> debbugs.gnu.org
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Fri, 1 May 2020 18:27:45 +0300
> 
> On 01.05.2020 09:57, Eli Zaretskii wrote:
> > I see no reference to either case-fold-search or
> > case-fold in isearch-no-upper-case-p.  So why would we need to update
> > its doc string?
> 
> Sorry if that was unclear: I think we'd need to update the docstring of 
> fileloop-initialize-replace. Which doesn't offer any hints that the 
> logic of isearch-no-upper-case-p will be employed.

Ah, okay.  Agreed.

> > Does that really work in the case in point?  Unless I'm missing
> > something, if case-fold-search is t by default, this patch would cause
> > the search to be case-insensitive even if the FROM regexp includes
> > upper-case characters.  But in that case, perform-replace will
> > internally decide to be case-sensitive, and we have the same failure
> > on our hands.  This is why the patch I proposed explicitly examined
> > the FROM regexp for upper-case characters.  Whereas yours doesn't.
> 
> Since we bind search-upper-case to nil in this patch, perform-replace 
> won't try to alter the value of case-fold-search internally.

But that's contrary to how query-replace works, isn't it?

Previous Next

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