From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.devel Subject: Re: Isearch interaction model Date: Sun, 04 Mar 2018 00:50:27 +0200 Organization: LINKOV.NET Message-ID: <87po4kn58s.fsf@mail.linkov.net> References: <87po4slrg4.fsf@mail.linkov.net> <2854ae14-ad4a-2fa2-ff0f-652e1501819e@dancol.org> <87fu5jh14h.fsf_-_@mail.linkov.net> <6a3f7332ddb16531fd4dcdd5ec49f846.squirrel@dancol.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1520117393 26881 195.159.176.226 (3 Mar 2018 22:49:53 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 3 Mar 2018 22:49:53 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) Cc: Emacs developers To: dancol@dancol.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Mar 03 23:49:49 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 1esFyO-000649-7T for ged-emacs-devel@m.gmane.org; Sat, 03 Mar 2018 23:49:48 +0100 Original-Received: from localhost ([::1]:42227 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1esG0P-0003H6-1v for ged-emacs-devel@m.gmane.org; Sat, 03 Mar 2018 17:51:53 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55463) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1esG08-0003Fn-CM for emacs-devel@gnu.org; Sat, 03 Mar 2018 17:51:44 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1esG01-0003Qz-PQ for emacs-devel@gnu.org; Sat, 03 Mar 2018 17:51:35 -0500 Original-Received: from hapkido.dreamhost.com ([66.33.216.122]:47735) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1esG01-0003Pq-1v for emacs-devel@gnu.org; Sat, 03 Mar 2018 17:51:29 -0500 Original-Received: from homiemail-a76.g.dreamhost.com (sub3.mail.dreamhost.com [69.163.253.7]) by hapkido.dreamhost.com (Postfix) with ESMTP id BFE958549B for ; Sat, 3 Mar 2018 14:51:26 -0800 (PST) Original-Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 757AB45807B; Sat, 3 Mar 2018 14:51:24 -0800 (PST) Original-Received: from localhost.linkov.net (m91-129-97-206.cust.tele2.ee [91.129.97.206]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by homiemail-a76.g.dreamhost.com (Postfix) with ESMTPSA id 67ED4458079; Sat, 3 Mar 2018 14:51:23 -0800 (PST) In-Reply-To: <6a3f7332ddb16531fd4dcdd5ec49f846.squirrel@dancol.org> (dancol's message of "Thu, 1 Mar 2018 16:26:38 -0800") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x [fuzzy] X-Received-From: 66.33.216.122 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:223251 Archived-At: >>> We have a search history because it's often the case that we want to >>> repeat something we've recently done --- look up the same word, find >>> the same function, and so on. It doesn't make sense to me that the >>> exact mechanism we use to search for a particular thing should >>> affect its recency or the way in which we recall it. >> But "repeating" a search for \_ as a non-regexp search is useless. > > It is. That's why we'll store the search flags along with the history > entry. A long time ago (years and years), I posted a proof-of-concept of > this model to emacs-devel. > >> >>> It's very easy already to casually switch between literal and regex >>> isearch with M-r. Why should this distinction affect the way in which >>> we recall that search? >> I think the answer is to have one history which records the mode used >> for each search, so that it is reused correctly. (When it makes sense, >> the user can change the search mode after selecting the history element.) >> > > Yep. One of the main questions to decide is how to attach search parameters to the search string in the search history in a backward-compatible way. We can't do this by adding text properties with search parameters to the search string because text properties on strings can't be saved in the desktop file or by other history saving libraries. I see no way other than introducing a new incompatible history variable that will keep previous searches with parameters in the same format as is used currently by the search stack in isearch-cmds.