From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Word Delimited Query Replace Date: Sat, 18 Oct 2008 22:08:55 -0400 Message-ID: References: <878wsl27pv.fsf@jurta.org> <87tzb9sn9m.fsf@jurta.org> <87ljwlo6xc.fsf@jurta.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1224382146 24240 80.91.229.12 (19 Oct 2008 02:09:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 19 Oct 2008 02:09:06 +0000 (UTC) Cc: emacs-devel@gnu.org To: Juri Linkov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Oct 19 04:10:11 2008 connect(): Connection refused Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1KrNk9-0008Qo-Ah for ged-emacs-devel@m.gmane.org; Sun, 19 Oct 2008 04:10:09 +0200 Original-Received: from localhost ([127.0.0.1]:48536 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KrNj4-0000yH-Ab for ged-emacs-devel@m.gmane.org; Sat, 18 Oct 2008 22:09:02 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KrNiz-0000y2-TP for emacs-devel@gnu.org; Sat, 18 Oct 2008 22:08:57 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KrNiy-0000xq-HR for emacs-devel@gnu.org; Sat, 18 Oct 2008 22:08:56 -0400 Original-Received: from [199.232.76.173] (port=53585 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KrNiy-0000xn-Bd for emacs-devel@gnu.org; Sat, 18 Oct 2008 22:08:56 -0400 Original-Received: from ironport2-out.pppoe.ca ([206.248.154.182]:6113 helo=ironport2-out.teksavvy.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KrNiy-0004cr-4W for emacs-devel@gnu.org; Sat, 18 Oct 2008 22:08:56 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiUFAOcy+khMCpQ6/2dsb2JhbACBcr8Ig2yBCg X-IronPort-AV: E=Sophos;i="4.33,441,1220241600"; d="scan'208";a="28565196" Original-Received: from 76-10-148-58.dsl.teksavvy.com (HELO pastel.home) ([76.10.148.58]) by ironport2-out.teksavvy.com with ESMTP; 18 Oct 2008 22:08:55 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 34A157F20; Sat, 18 Oct 2008 22:08:55 -0400 (EDT) In-Reply-To: <87ljwlo6xc.fsf@jurta.org> (Juri Linkov's message of "Sun, 19 Oct 2008 02:29:19 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:104619 Archived-At: >>> Currently, M-s w is broken, and I'll will try to fix it. But even >>> after it is fixed, I think it would be good to provide two ways to run >>> word replacement from isearch, exactly as we already provide two ways >>> to run regexp replacement: >>> regexp search/replace: C-M-s M-% and C-s C-M-% >>> word search/replace: M-s w M-% and C-s C-u M-% >> >> I'd rather discourage the second alternatives. After all, C-s C-M-% is >> rather odd since it'll use the string you searched as a regexp, so if >> you were searching for the string "a*b" the replacement will not apply >> to what isearch matched. > IMHO, it would be worse when the user habitually types C-u M-% to run > word replacement or C-M-% to run regexp replacement and these keys do not > do what the user wants. They still do what the user wants outside of isearch. But the new "query-replace from isearch" only works with M-% (which is one of the advantages I see in this M-%: it provides the same featureset while using fewer keys: the global M-% and C-M-% can be used for anything else now). As it happens, it seems that the problem you found is due to your setting isearch-allow-scroll=t which caused the C-u to be eaten without passing it to the query-replace, whereas with isearch-allow-scroll=nil the C-u exits isearch and is then passed to query-replace correctly. So I guess your change is OK: in the case that C-u is eaten by isearch-allow-scroll=t, then the C-u will be passed on to query-replace, and if it's not, then your change makes no difference and the C-u exits isearch. > We could provide these keys only as a back-up for the case we the user > intuitively types it, and discourage them simply by not advertising in > the documentation. Yes, it's probably OK, Stefan