From: Karl Fogel <kfogel@red-bean.com>
To: Drew Adams <drew.adams@oracle.com>
Cc: Emacs developers <emacs-devel@gnu.org>
Subject: Re: PATCH: isearch-yank-until-char
Date: Mon, 26 Aug 2019 16:29:30 -0500 [thread overview]
Message-ID: <87k1az8vk5.fsf@red-bean.com> (raw)
In-Reply-To: <eee52c32-b3ba-4c19-99d4-515f7210c5a4@default> (Drew Adams's message of "Mon, 26 Aug 2019 12:36:23 -0700 (PDT)")
[-- Attachment #1: Type: text/plain, Size: 2056 bytes --]
On 26 Aug 2019, Drew Adams wrote:
>OK.
>
>(But I can guess the outcome. It's OK; I can always
>just add the enhancement to isearch+.el. It won't be
>the first time.)
Well, I can't say what the outcome would be, but in any case that shouldn't be affected by the order in which we do these things.
>FYI, it doesn't do that in the parts that are doc.
>Those patch parts still speak of `C-M-c'.
Gah -- I rushed. Thank you for noticing that. New patch attached.
>> * Make the search for the character case-sensitive. (Seems like a
>> pretty obvious improvement, given the use cases: when the goal
>> character is a letter at all, one is either looking at that letter on
>> the screen *or* the letter is some known syntactic delimiter and its
>> case is therefore known as well even if the letter is off the screen
>> right now.)
>
>FWIW, I don't think that's really TRT.
>
>Personally, I have `case-fold-search' set to nil by
>default, so that behavior isn't a problem for me.
>But I don't think it should be part of this command.
>
>Users can toggle case-folding in Isearch easily.
>
>There's no reason to have this command make an
>assumption about whether its char-search should be
>case-sensitive. I don't think the either...or
>assumption you made above is good for the command
>to make. Better to let users control whether to
>search for the char case-sensitively.
When I think about the circumstances under which this command is actually used, which I tried to characterize above, I couldn't think of any in which case-insensitive matching would make sense -- speaking of just the char-match, of course, not the overall isearch. The overall isearch still obeys `isearch-case-fold-search'. When the user toggles case-folding in isearch, that should and does affect the isearch itself, but that isn't the same as the single-char match-and-yank-into-search-string we're talking about here. For the latter, case-sensitivity makes sense I think.
Can you say which part of the assumptions I gave above seems wrong to you?
Best regards,
-Karl
[-- Attachment #2: isearch-yank-until-char-20190826-2.txt --]
[-- Type: text/plain, Size: 4044 bytes --]
[[[
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,22 @@ 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)
+ (case-fold-search nil))
+ (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."
next prev parent reply other threads:[~2019-08-26 21:29 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-14 3:05 PATCH: isearch-yank-until-char Karl Fogel
2019-08-14 14:20 ` Eli Zaretskii
2019-08-14 16:41 ` Karl Fogel
2019-08-14 16:48 ` Drew Adams
2019-08-14 17:20 ` Eli Zaretskii
2019-08-14 17:22 ` Karl Fogel
2019-08-14 17:51 ` Eli Zaretskii
2019-08-14 17:59 ` Noam Postavsky
2019-08-14 20:39 ` Juri Linkov
2019-08-14 20:34 ` Juri Linkov
2019-08-16 4:53 ` Karl Fogel
2019-08-16 17:52 ` Juri Linkov
2019-08-25 2:14 ` Karl Fogel
2019-08-25 3:22 ` Drew Adams
2019-08-25 20:03 ` Juri Linkov
2019-08-26 1:14 ` Drew Adams
2019-08-26 5:20 ` Karl Fogel
2019-08-26 14:50 ` Drew Adams
2019-08-26 17:51 ` Karl Fogel
2019-08-26 19:36 ` Drew Adams
2019-08-26 21:29 ` Karl Fogel [this message]
2019-08-26 21:57 ` Drew Adams
2019-08-26 22:21 ` Karl Fogel
2019-08-26 22:43 ` Drew Adams
2019-09-04 16:47 ` Karl Fogel
2019-09-04 17:00 ` Eli Zaretskii
2019-09-12 17:44 ` Karl Fogel
2019-09-16 21:24 ` Drew Adams
2019-09-17 16:02 ` Karl Fogel
2019-08-26 21:46 ` Juri Linkov
2019-08-26 21:52 ` Karl Fogel
2019-08-26 22:03 ` Drew Adams
2019-08-26 22:19 ` Juri Linkov
2019-08-26 22:33 ` Karl Fogel
2019-08-26 22:40 ` Drew Adams
2019-08-27 21:31 ` Juri Linkov
2019-08-27 22:52 ` Drew Adams
2019-08-27 23:15 ` Drew Adams
2019-08-25 19:58 ` Juri Linkov
2019-08-14 22:26 ` Stefan Monnier
2019-08-15 18:24 ` Juri Linkov
2019-08-17 12:31 ` Stefan Monnier
2019-08-17 22:51 ` Juri Linkov
2019-08-16 5:11 ` Karl Fogel
[not found] <<87tvakfnv4.fsf@red-bean.com>
[not found] ` <<835zmzsuau.fsf@gnu.org>
2019-08-14 15:24 ` Drew Adams
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87k1az8vk5.fsf@red-bean.com \
--to=kfogel@red-bean.com \
--cc=drew.adams@oracle.com \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.