From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#29321: Isearch hit count Date: Sun, 4 Nov 2018 19:09:52 -0800 (PST) Message-ID: <5e02cd23-2e0b-41c6-8c66-0e4901cba2fa@default> References: <87o9bfqfc3.fsf@mail.linkov.net> <988284b2-58af-428d-9c6f-da56db0c6565@default> <874ld5elxb.fsf@mail.linkov.net> <3e52e081-ad81-41a6-a0d6-295790db82d4@default> <877ei049f6.fsf@mail.linkov.net> <2231d642-cb4a-4114-9896-be995e4c6460@default> <87r2g7kp8u.fsf@mail.linkov.net> <8629624d-6118-4b6b-b626-77801112326a@default> <76796f6d-4d0d-47d6-bea7-0944cf53cb18@default> <877ehx7qj9.fsf@mail.linkov.net> <2dca8e1b-2949-4b07-8467-27f873dd0f3d@default> <87a7msl9oz.fsf@mail.linkov.net> <87ftwjod61.fsf@aol.com> <87va5d7lc8.fsf@mail.linkov.net> <87tvkwe9ty.fsf@mail.linkov.net> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1541387357 10998 195.159.176.226 (5 Nov 2018 03:09:17 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 5 Nov 2018 03:09:17 +0000 (UTC) Cc: Live System User , 29321@debbugs.gnu.org To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Nov 05 04:09:13 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1gJVGD-0002bH-M8 for geb-bug-gnu-emacs@m.gmane.org; Mon, 05 Nov 2018 04:09:05 +0100 Original-Received: from localhost ([::1]:32953 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gJVIJ-0005c4-Tb for geb-bug-gnu-emacs@m.gmane.org; Sun, 04 Nov 2018 22:11:15 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40228) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gJVID-0005bz-7j for bug-gnu-emacs@gnu.org; Sun, 04 Nov 2018 22:11:10 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gJVIA-0005Au-HU for bug-gnu-emacs@gnu.org; Sun, 04 Nov 2018 22:11:09 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:58455) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gJVI6-00055m-Rp for bug-gnu-emacs@gnu.org; Sun, 04 Nov 2018 22:11:05 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gJVI6-0000Vt-Ic for bug-gnu-emacs@gnu.org; Sun, 04 Nov 2018 22:11:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 05 Nov 2018 03:11:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 29321 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 29321-submit@debbugs.gnu.org id=B29321.15413874061905 (code B ref 29321); Mon, 05 Nov 2018 03:11:02 +0000 Original-Received: (at 29321) by debbugs.gnu.org; 5 Nov 2018 03:10:06 +0000 Original-Received: from localhost ([127.0.0.1]:34479 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gJVHC-0000Ue-55 for submit@debbugs.gnu.org; Sun, 04 Nov 2018 22:10:06 -0500 Original-Received: from userp2130.oracle.com ([156.151.31.86]:41602) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gJVHA-0000U3-Uo for 29321@debbugs.gnu.org; Sun, 04 Nov 2018 22:10:05 -0500 Original-Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id wA534Tv3194203; Mon, 5 Nov 2018 03:09:57 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=nCr497+ooWKY4RpEgklT1HtAsvnk4P9xEVRTH9AXHMU=; b=AcoDLzlV6YnppQT+dnTzhQyEmq3J11GcVHYQo8CBmrbLVygMAQxZZ9K1UJeGfZT8r0Ul RBfVqRd1Sa7VsVMLRktLBtgaNNUtVujrJ4MmjDDNrdh7K8Km+S6RpDOw1Mz2zhyg/b6r RJ+riFny+XrT10XrJL9AhUKCvc7E0SnbpRfChCFY3+leX7uXWYLX2bvh4G2LEPYK+ARf DTRQONTL1MkVkdk+X4LhOqAssnk57/AQSRIIKbJrFRDm95f4bMjxkG/AjPYISHAn09dJ U+I9wMQ2sEZHmWY4mCeii7mRvH0VzpaWQorUBVI6VdjvADoNuJb0R36dv/LdScHsx6IU Gw== Original-Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp2130.oracle.com with ESMTP id 2nh33tm7y4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 05 Nov 2018 03:09:57 +0000 Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id wA539u3W016694 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 5 Nov 2018 03:09:56 GMT Original-Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id wA539rWj006411; Mon, 5 Nov 2018 03:09:53 GMT In-Reply-To: <87tvkwe9ty.fsf@mail.linkov.net> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4756.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9067 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1811050026 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:152041 Archived-At: > > 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. >=20 > 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). >=20 > 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?)