From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Isearch interaction model Date: Sun, 04 Mar 2018 17:39:27 +0200 Message-ID: <83po4ju9xs.fsf@gnu.org> References: <87po4slrg4.fsf@mail.linkov.net> <2854ae14-ad4a-2fa2-ff0f-652e1501819e@dancol.org> <87fu5jh14h.fsf_-_@mail.linkov.net> <6a3f7332ddb16531fd4dcdd5ec49f846.squirrel@dancol.org> <87po4kn58s.fsf@mail.linkov.net> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1520177875 761 195.159.176.226 (4 Mar 2018 15:37:55 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 4 Mar 2018 15:37:55 +0000 (UTC) Cc: dancol@dancol.org, emacs-devel@gnu.org To: Juri Linkov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Mar 04 16:37:50 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 1esVht-0007in-1s for ged-emacs-devel@m.gmane.org; Sun, 04 Mar 2018 16:37:49 +0100 Original-Received: from localhost ([::1]:45256 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1esVjt-0006vK-Ql for ged-emacs-devel@m.gmane.org; Sun, 04 Mar 2018 10:39:53 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40382) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1esVjn-0006um-Ut for emacs-devel@gnu.org; Sun, 04 Mar 2018 10:39:48 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1esVjj-0002YJ-6C for emacs-devel@gnu.org; Sun, 04 Mar 2018 10:39:48 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:38266) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1esVjj-0002Y3-1z; Sun, 04 Mar 2018 10:39:43 -0500 Original-Received: from [176.228.60.248] (port=3127 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1esVji-0005Uq-CE; Sun, 04 Mar 2018 10:39:42 -0500 In-reply-to: <87po4kn58s.fsf@mail.linkov.net> (message from Juri Linkov on Sun, 04 Mar 2018 00:50:27 +0200) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:223257 Archived-At: > From: Juri Linkov > Date: Sun, 04 Mar 2018 00:50:27 +0200 > Cc: Emacs developers > > >> 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. Aren't we over-engineering this stuff? IMNSHO, separate histories could be just fine, since it's easy enough to change the Isearch mode after you have the previous search string in the minibuffer. And if you remember your previous searches, you most probably also remember whether you searched for a string as a symbol or a word or whatever. By contrast, breaking back-compatibility for this reason sounds gross to me.