From: Drew Adams <drew.adams@oracle.com>
To: Juri Linkov <juri@linkov.net>
Cc: Live System User <nyc4bos@aol.com>, 29321@debbugs.gnu.org
Subject: bug#29321: Isearch hit count
Date: Sun, 4 Nov 2018 19:09:52 -0800 (PST) [thread overview]
Message-ID: <5e02cd23-2e0b-41c6-8c66-0e4901cba2fa@default> (raw)
In-Reply-To: <87tvkwe9ty.fsf@mail.linkov.net>
> > I was thinking about this request, and thinking along these
> > lines: Where we count, push (match-# . buffer-position)
> > to an alist variable. The variable would get reinitialized
> > when counting gets reinitialized (e.g. for a new search
> > string, direction change, or startup of Isearch).
> >
> > That alist could be used to go to any given match, either
> > during the current Isearch or later. If they wanted, users
> > could even save copies of the alist for different searches,
> > for subsequent reuse.
>
> A mapping from search parameters (search string, direction, etc.)
> to the matches and buffer-positions invalidates too quickly.
> Even using point-markers doesn't help when a user deletes
> a large region with former matches.
I don't see why. Sure, if someone edits the buffer during
an Isearch recursive edit and then resumes searching it is
possible that some things might be thrown off a bit. But
in general I think the position will be mostly accurate
(obviously different ends of the match would be recorded,
depending on the current search direction).
And even if the position recorded were sometimes off a bit,
resuming search from that position should put you where you
wanted to be almost all of the time. IOW, it would move you
very near, even if not always exactly to, the relevant search
occurrence. So searching from there would be right on, or
maybe one occurrence away from, the desired occurrence.
It's possible I'm not understanding you, however. I don't
see a real problem here, but that doesn't mean there isn't
one. Maybe you can elaborate a bit about the problem, or
maybe give an example.
> > I was thinking of binding a key during Isearch to move to
> > an occurrence by its match number. `M-g' perhaps. With
> > a numeric prefix arg it would move to that number. With
> > no prefix arg it would prompt for the number (with
> > completion requiring a match against the alist).
>
> I understand that in addition to relative counting like
> 'C-u 42 C-s' would do, you propose absolute counting like
> 'C-s M-g 42 RET'. But a question: shouldn't 'M-g'
> exit the search since it's a global prefix key.
Yes, I was talking about moving to an absolute match
number - what you see in the prompt, not N matches
forward or backward.
I don't really care what key would be used - `M-g' was
just a suggestion.
As you know, I personally don't have a problem with
Isearch co-opting a key that currently ends Isearch,
depending on the key. I have no problem with Isearch
using `M-g' for that (so that if you wanted to stop
Isearch and do `goto-char' you would need to do
`RET M-g c' instead of just `M-g c'.
In what I suggested you could do `C-u 42 M-g' during
Isearch, provided `isearch-allow-prefix' is non-nil.
You could alternatively do `M-g 42 RET' (replying to
a prompt for reading the number), regardless of the
value of `isearch-allow-prefix'.
(BTW, to use your `C-u 42 C-s` during Isearch, wouldn't
option `isearch-allow-prefix' also need to be non-nil?
Or didn't you intend that to be used also during Isearch?)
next prev parent reply other threads:[~2018-11-05 3:09 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-16 19:27 bug#29321: Isearch hit count Charles A. Roelli
2018-10-27 20:55 ` Juri Linkov
2018-10-27 21:31 ` Drew Adams
2018-10-27 22:25 ` Drew Adams
2018-10-27 22:58 ` Drew Adams
2018-10-27 23:23 ` Drew Adams
2018-10-28 0:02 ` Drew Adams
2018-10-28 0:35 ` bug#29360: " Drew Adams
2018-10-28 22:34 ` bug#29360: Add full-buffer choice for `isearch-lazy-highlight' Juri Linkov
2018-10-28 22:57 ` Drew Adams
2018-10-28 3:35 ` bug#29321: Isearch hit count Drew Adams
2018-10-28 22:38 ` Juri Linkov
2018-10-29 0:22 ` Drew Adams
2018-10-29 23:31 ` Juri Linkov
2018-10-30 2:43 ` Drew Adams
2018-10-30 3:19 ` Drew Adams
2018-10-30 3:47 ` Drew Adams
2018-10-30 4:02 ` Drew Adams
2018-10-30 23:07 ` Juri Linkov
2018-10-30 23:35 ` Drew Adams
2018-10-30 23:43 ` Drew Adams
2018-10-31 21:30 ` Juri Linkov
2018-10-31 22:07 ` Drew Adams
2018-11-01 22:22 ` Juri Linkov
2018-11-01 23:46 ` Drew Adams
2018-11-02 12:51 ` Live System User
2018-11-04 0:04 ` Juri Linkov
2018-11-04 0:11 ` Juri Linkov
2018-11-04 1:22 ` Drew Adams
2018-11-04 22:50 ` Juri Linkov
2018-11-05 3:09 ` Drew Adams [this message]
2018-11-04 19:13 ` Live System User
2018-11-22 22:03 ` Juri Linkov
2018-11-24 12:55 ` Charles A. Roelli
2018-11-04 16:47 ` Drew Adams
2018-11-04 22:59 ` Juri Linkov
2018-11-05 2:41 ` Drew Adams
2018-11-10 14:27 ` Charles A. Roelli
2018-11-10 20:45 ` Juri Linkov
2018-11-11 9:49 ` Charles A. Roelli
2018-11-11 20:02 ` Juri Linkov
2018-11-13 21:48 ` Drew Adams
2018-11-14 22:36 ` Juri Linkov
2018-11-15 8:02 ` Live System User
2018-11-15 21:16 ` Juri Linkov
2018-11-20 23:43 ` Juri Linkov
2018-11-15 21:15 ` Charles A. Roelli
2018-11-15 21:58 ` Juri Linkov
2018-11-16 20:03 ` Charles A. Roelli
2018-11-17 21:59 ` Juri Linkov
2018-11-20 23:52 ` Juri Linkov
[not found] <<m2ineavxaz.fsf@aurox.ch>
2017-11-16 22:25 ` Drew Adams
2017-11-19 17:12 ` Charles A. Roelli
[not found] <<<m2ineavxaz.fsf@aurox.ch>
[not found] ` <<1585f8e7-72a7-497c-9879-8bf1dda3f28f@default>
[not found] ` <<m2a7ziw5uf.fsf@aurox.ch>
2017-11-19 19:06 ` Drew Adams
2017-11-20 19:25 ` Charles A. Roelli
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=5e02cd23-2e0b-41c6-8c66-0e4901cba2fa@default \
--to=drew.adams@oracle.com \
--cc=29321@debbugs.gnu.org \
--cc=juri@linkov.net \
--cc=nyc4bos@aol.com \
/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.