From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: Isearch interaction model Date: Sat, 10 Mar 2018 13:36:41 -0800 Message-ID: <4d42eab9-1d69-8a02-5f14-04315888f29e@dancol.org> References: <87po4slrg4.fsf@mail.linkov.net> <2854ae14-ad4a-2fa2-ff0f-652e1501819e@dancol.org> <87fu5jh14h.fsf_-_@mail.linkov.net> <87po4gvptz.fsf@mail.linkov.net> <87h8prwmaq.fsf@mail.linkov.net> <87d10echr9.fsf@mail.linkov.net> <87o9jvy6e6.fsf@mail.linkov.net> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1520717909 23098 195.159.176.226 (10 Mar 2018 21:38:29 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 10 Mar 2018 21:38:29 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 Cc: Emacs developers To: Juri Linkov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Mar 10 22:38:25 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eumC7-0005wf-2P for ged-emacs-devel@m.gmane.org; Sat, 10 Mar 2018 22:38:23 +0100 Original-Received: from localhost ([::1]:52064 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eumE9-0000i3-Uu for ged-emacs-devel@m.gmane.org; Sat, 10 Mar 2018 16:40:30 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53245) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eumAk-00067P-DF for emacs-devel@gnu.org; Sat, 10 Mar 2018 16:36:59 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eumAh-0007xt-Ac for emacs-devel@gnu.org; Sat, 10 Mar 2018 16:36:58 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:34306) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eumAh-0007vi-0D for emacs-devel@gnu.org; Sat, 10 Mar 2018 16:36:55 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject; bh=2CzIxp3qdlU/+b2s88rnvzA5UCCLx9YzU9dixskMkDk=; b=bxBH1RX/Msu6Zq7PSrt6f6d0QPcl6LgqoDCgea3zVfbKz1preN6lxGhYDdXRJ25N8mpSVx1JLG0idPHDMmQ+deFUltR6BKKkgQqd/vM0FqzYw0WoVkwTjJ3NL7bh3pUbeGdXauwO33NPc2ynB9MY//TdI9KtGwIT2RF+nrveOOW9FW2vmx4ujLNyEq/NgYeZIjoG8+COwIvIep1uZoeZ6Whnr3A8REePsv8wYMQ3Ma5X2uq++BCSDCR9rxosNH4sTabK/LLiWAQh99KM77oO2oEQWxuXYcgPIZ59IMaku2rP7S3ri8ny4xeFEIMwgQBOfdn3q4zMXZ1xaCiRjnNrmQ==; Original-Received: from [172.92.145.124] (helo=[192.168.86.27]) by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1eumAZ-0006a5-0Q; Sat, 10 Mar 2018 13:36:47 -0800 In-Reply-To: <87o9jvy6e6.fsf@mail.linkov.net> Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2600:3c01::f03c:91ff:fedf:adf3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:223601 Archived-At: On 03/10/2018 01:20 PM, Juri Linkov wrote: >> But people _do_ switch from regex to literal mode and back. That's why M-r >> is a convenient isearch binding for doing exactly that, and on prevision >> occasions when this topic has come up for discussion, others have indicated >> that they use this M-r binding. > > I can't imagine the usefulness of switching from regex to literal mode > when the search string contains a complex regexp. > >>> But it you want to share string and regexp histories, it's easy to implement >>> by another layer of indirection like for query-replace history variables: >>> >>> (defcustom query-replace-from-history-variable 'query-replace-history >>> (defcustom query-replace-to-history-variable 'query-replace-history >> >> Sure. It's possible to make this behavior customizable. > > But then perhaps search-ring-yank-pointer and regexp-search-ring-yank-pointer > need similar indirection, or code could be smart enough to detect such > indirection and compute the right pointer depending on where such variables > point to. I really think you're over-thinking this problem. Let's just try a unified history and see whether it causes problems in practice. I suspect it'll feel perfectly natural, and we won't need complex indirection layers.