From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Karl Fogel Newsgroups: gmane.emacs.devel Subject: Re: PATCH: isearch-yank-until-char Date: Mon, 26 Aug 2019 17:21:19 -0500 Message-ID: <87o90b600w.fsf@red-bean.com> References: <87tvakfnv4.fsf@red-bean.com> <87lfvvjxjs.fsf@mail.linkov.net> <87sgq1r9rb.fsf@red-bean.com> <87lfvt6m1e.fsf@mail.linkov.net> <877e7256uc.fsf@red-bean.com> <604cbbef-7e25-486a-a97a-9bc1adf23928@default> <871rx87b9h.fsf@red-bean.com> <77205e15-f38a-46dc-9451-4030a318900a@default> <874l23ak8m.fsf@red-bean.com> <87k1az8vk5.fsf@red-bean.com> Reply-To: Karl Fogel Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="173504"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: Emacs developers To: Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 27 00:22:43 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1i2NNq-000j0i-7h for ged-emacs-devel@m.gmane.org; Tue, 27 Aug 2019 00:22:42 +0200 Original-Received: from localhost ([::1]:58086 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i2NNp-0001T0-5N for ged-emacs-devel@m.gmane.org; Mon, 26 Aug 2019 18:22:41 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47786) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i2NMb-00010d-Pa for emacs-devel@gnu.org; Mon, 26 Aug 2019 18:21:27 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1i2NMZ-0006oD-SB for emacs-devel@gnu.org; Mon, 26 Aug 2019 18:21:25 -0400 Original-Received: from mail-io1-xd29.google.com ([2607:f8b0:4864:20::d29]:46114) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1i2NMY-0006nn-L2 for emacs-devel@gnu.org; Mon, 26 Aug 2019 18:21:23 -0400 Original-Received: by mail-io1-xd29.google.com with SMTP id x4so41235178iog.13 for ; Mon, 26 Aug 2019 15:21:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:subject:references:reply-to:date:in-reply-to :message-id:user-agent:mime-version; bh=LzGk1zwRjYpa6Yp3YwlLSRsTITPSOpK6EY+YqHYhO1Y=; b=TAo9gsr93kW6G8isbtGNdaieP2ZPe4Ze9CYT4C6L7dr+MtDXxPxE0XgCweB4bGOh+l JklrrZoMvOBBWbJa1t7wdcC4X53JfMRT+YNYf2GQNaxh+U0YmhF9Q2KbMFtKJCWYLUxr Q2tETcJe6mFylazNqUpnulPMNhoJCwnLAeBC89M7TsX8SOwU+nCimeeQo75HwGL/HK8I 02Lt63EIZsZEcTA+cqPFCQHfayzPrgWP6m41yUtDEe1Zyc7x0bVDklM7buEfIdr9PA6j 73aAI3hSbjzSdEOtFCkbzIPSsBk2YeJlOOxwVOGJnYnDU4/tLicINl4cA8UpUr5X3uda TyNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:references:reply-to :date:in-reply-to:message-id:user-agent:mime-version; bh=LzGk1zwRjYpa6Yp3YwlLSRsTITPSOpK6EY+YqHYhO1Y=; b=TRsbdL8hhO1Ix4t3BFltusm68zaOyMiY04vQkvq2MW4c1z4Egd+QfxroA0WganpDua ZTod4b/4tN7vJ2VBTC+lB30nnGzsEH7XCSHYOaXikAiVXeJwWkY7VbhHJBHC/QXs4eoY XN4fPjr4g1rb0p3xAEvJ6JISfzXYIeqNbIE0oKy+MF0WVNVdx2j17Y75bFWO/35wbnwD rk4O/maGF4oQw5p5wsTVnHE324WAoEYUNlAEhtPZsf8jePQO8pi+yNKcIOCnyjerGsVj pA8GHHEeYjv5bd+vS1bUeIHQYrECgNVs1mqJxMIE/54AaujU2f6DSCUIBHbgYIz+Xwyg f6nQ== X-Gm-Message-State: APjAAAWU7naY7aZ4QExQ+4QJrSzVTl6P98RFbKc+xPEUh2Yacb+WNTt6 ziplhDDdf82wzAOKc8O2mStfG8SP X-Google-Smtp-Source: APXvYqxFK8qYRloEjf07mANEkjefX/LwHzyToCR7gfu1l3JJua0qD0/hiIZYuBHMuntxgXMc1H03vA== X-Received: by 2002:a5e:8e4a:: with SMTP id r10mr27701686ioo.100.1566858081390; Mon, 26 Aug 2019 15:21:21 -0700 (PDT) Original-Received: from kwork (74-92-190-114-Illinois.hfc.comcastbusiness.net. [74.92.190.114]) by smtp.gmail.com with ESMTPSA id n25sm11200947iop.3.2019.08.26.15.21.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 26 Aug 2019 15:21:20 -0700 (PDT) In-Reply-To: (Drew Adams's message of "Mon, 26 Aug 2019 14:57:41 -0700 (PDT)") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::d29 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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:239598 Archived-At: --=-=-= Content-Type: text/plain On 26 Aug 2019, Drew Adams wrote: >Can you give an example where you think case >insensitivity would be inappropriate for this, but >it would be appropriate for the search with the >updated search string? > >(Not that I'm arguing for case-insensitivity here. >I just wonder why case-sensitivity is always TRT.) TL;DR: by the end of this post, I'm going to come around to your way of thinking. So you can just skip ahead if you want :-). But below I'll lay it all out. It might be easier if I describe the situations in which I find this feature useful at all. This feature seems to be most useful in keyboard macros. Indeed, I'm not sure I've *ever* used it outside of a keyboard macro. Almost always, it's in a programming language buffer (or markup language, or some other kind of system in which syntactic signifiers -- some of which are one character long -- are thick on the ground). In almost all of those cases, the target char is not a letter anyway: it's some other kind of symbol that marks a boundary that's useful to the macro. In the few cases where it's been a letter, that letter's case is either not going to vary on other iterations of the macro or is not going to matter (both of which are knowable because of the syntax environment). However, the more I think about it, the less convinced I am by my own argument. In ~95% of the uses, one isn't matching a letter anyway, but even more importantly, one is almost always in a keyboard macro. So if case-sensitivity matters either way, one can just set `case-fold-search' manually before doing the macro. Meanwhile, hard-setting `case-fold-search' violates the Principle Of Least Surprise. So, this latest patch has that removed. Thank you for pushing back on this and making me think more carefully. Best regards, -Karl --=-=-= Content-Type: text/plain Content-Disposition: attachment; filename=isearch-yank-until-char-20190826-3.txt [[[ Add `isearch-yank-until-char' * lisp/isearch.el (isearch-yank-until-char): New function. (isearch-mode-map, isearch-menu-bar-yank-map): Add it. (isearch-forward): Document the new binding. * doc/emacs/search.texi (Isearch Yanking): Document the feature. * etc/NEWS: Mention the above. ]]] --- doc/emacs/search.texi +++ doc/emacs/search.texi @@ -262,11 +262,17 @@ Isearch Yank @kindex M-s C-e @r{(Incremental search)} @findex isearch-yank-line - Similarly, @kbd{M-s C-e} (@code{isearch-yank-line}) appends the rest + @kbd{M-s C-e} (@code{isearch-yank-line}) appends the rest of the current line to the search string. If point is already at the end of a line, it appends the next line. With a prefix argument @var{n}, it appends the next @var{n} lines. +@kindex C-M-. @r{(Incremental search)} +@findex isearch-yank-until-char + Similarly, @kbd{C-M-.} (@code{isearch-yank-until-char}) appends to +the search string everything from point until the next occurence of +a specified character (not including that character). + @kindex C-y @r{(Incremental search)} @kindex M-y @r{(Incremental search)} @kindex mouse-2 @r{in the minibuffer (Incremental search)} --- etc/NEWS +++ etc/NEWS @@ -1202,6 +1202,10 @@ highlight in one iteration while processing the full buffer. +++ *** New isearch bindings. +'C-M-.' invokes new function 'isearch-yank-until-char', which yanks +everything from point to the specified character into the search +string. + 'C-M-w' in isearch changed from 'isearch-del-char' to the new function 'isearch-yank-symbol-or-char'. 'isearch-del-char' is now bound to 'C-M-d'. --- lisp/isearch.el +++ lisp/isearch.el @@ -514,6 +514,9 @@ isearch-menu-bar-yank-map (define-key map [isearch-yank-kill] '(menu-item "Current kill" isearch-yank-kill :help "Append current kill to search string")) + (define-key map [isearch-yank-until-char] + '(menu-item "Until char..." isearch-yank-until-char + :help "Yank from point to specified character into search string")) (define-key map [isearch-yank-line] '(menu-item "Rest of line" isearch-yank-line :help "Yank the rest of the current line on search string")) @@ -705,6 +708,7 @@ isearch-mode-map (define-key map "\M-\C-d" 'isearch-del-char) (define-key map "\M-\C-y" 'isearch-yank-char) (define-key map "\C-y" 'isearch-yank-kill) + (define-key map [?\C-\M-.] 'isearch-yank-until-char) (define-key map "\M-s\C-e" 'isearch-yank-line) (define-key map "\M-s\M-<" 'isearch-beginning-of-buffer) @@ -998,6 +1002,8 @@ isearch-forward Type \\[isearch-del-char] to delete character from end of search string. Type \\[isearch-yank-char] to yank char from buffer onto end of search\ string and search for it. +Type \\[isearch-yank-until-char] to yank from point until the next instance\ + of a specified character onto end of search string and search for it. Type \\[isearch-yank-line] to yank rest of line onto end of search string\ and search for it. Type \\[isearch-yank-kill] to yank the last string of killed text. @@ -2562,6 +2568,21 @@ isearch-yank-word (interactive "p") (isearch-yank-internal (lambda () (forward-word arg) (point)))) +(defun isearch-yank-until-char (char) + "Pull everything until next instance of CHAR from buffer into search string. +Interactively, prompt for CHAR." + (interactive "cYank until character: ") + (isearch-yank-internal + (lambda () (let ((inhibit-field-text-motion t)) + (condition-case nil + (progn + (search-forward (char-to-string char)) + (forward-char -1)) + (search-failed + (message "`%c' not found" char) + (sit-for 2))) + (point))))) + (defun isearch-yank-line (&optional arg) "Pull rest of line from buffer into search string. If optional ARG is non-nil, yank the next ARG lines." --=-=-=--