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: Tue, 06 Mar 2018 23:47:36 +0200 Organization: LINKOV.NET Message-ID: <87po4gvptz.fsf@mail.linkov.net> References: <87po4slrg4.fsf@mail.linkov.net> <2854ae14-ad4a-2fa2-ff0f-652e1501819e@dancol.org> <87fu5jh14h.fsf_-_@mail.linkov.net> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1520374249 5288 195.159.176.226 (6 Mar 2018 22:10:49 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 6 Mar 2018 22:10:49 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) Cc: Daniel Colascione , Emacs developers To: Davis Herring Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Mar 06 23:10:45 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 1etKnA-000054-BS for ged-emacs-devel@m.gmane.org; Tue, 06 Mar 2018 23:10:40 +0100 Original-Received: from localhost ([::1]:58603 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1etKpB-00072N-96 for ged-emacs-devel@m.gmane.org; Tue, 06 Mar 2018 17:12:45 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55063) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1etKoO-00071w-Tm for emacs-devel@gnu.org; Tue, 06 Mar 2018 17:11:57 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1etKoM-0001I0-90 for emacs-devel@gnu.org; Tue, 06 Mar 2018 17:11:56 -0500 Original-Received: from sub3.mail.dreamhost.com ([69.163.253.7]:36122 helo=homiemail-a100.g.dreamhost.com) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1etKoM-0001HR-34 for emacs-devel@gnu.org; Tue, 06 Mar 2018 17:11:54 -0500 Original-Received: from homiemail-a100.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a100.g.dreamhost.com (Postfix) with ESMTP id C237731A078; Tue, 6 Mar 2018 14:11:50 -0800 (PST) Original-Received: from localhost.linkov.net (m91-129-110-147.cust.tele2.ee [91.129.110.147]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by homiemail-a100.g.dreamhost.com (Postfix) with ESMTPSA id A8F9431A073; Tue, 6 Mar 2018 14:11:49 -0800 (PST) In-Reply-To: (Davis Herring's message of "Thu, 1 Mar 2018 17:19:52 -0700") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x (no timestamps) [generic] [fuzzy] X-Received-From: 69.163.253.7 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:223389 Archived-At: > I think the answer is to have one history which records the mode used f= or > each search, so that it is reused correctly. (When it makes sense, the > user can change the search mode after selecting the history element.) I still don't see how this unified history should work. Suppose we have a history variable like (setq isearch-history '(((search-string "word") (mode word)) ((search-string "regexp") (mode regexp)))) Then after typing =E2=80=98C-M-s M-p=E2=80=99 (in regexp search mode) wha= t should it do? Possible variants: 1. Take a previous history item with the same search mode, i.e. the string "regexp", skipping the last used search "word". 2. Take the last history item "word" and toggle the current search mode from regexp mode to word mode. 3. Take the last history item and adapt it to the current search mode, so turn the search string "word" into the regexp "\". 4. Take the last history item and do nothing more. Then what to do when the last search string is a regexp and the current search mode is not regexp mode?