From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Spencer Baugh via Users list for the GNU Emacs text editor Newsgroups: gmane.emacs.help Subject: Re: search-backward returning matches which end after point Date: Wed, 28 Aug 2024 09:45:42 -0400 Organization: Jane Street Capital Message-ID: References: Reply-To: Spencer Baugh Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24577"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) To: help-gnu-emacs@gnu.org Cancel-Lock: sha1:47B8OSEIne+0Y805kAD8TU0oZZ4= Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Wed Aug 28 15:46:33 2024 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1sjJ0L-0006Hj-17 for geh-help-gnu-emacs@m.gmane-mx.org; Wed, 28 Aug 2024 15:46:33 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sjIzn-0006vt-ME; Wed, 28 Aug 2024 09:45:59 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sjIzj-0006qc-4g for help-gnu-emacs@gnu.org; Wed, 28 Aug 2024 09:45:55 -0400 Original-Received: from ciao.gmane.io ([116.202.254.214]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sjIzh-0002dS-G1 for help-gnu-emacs@gnu.org; Wed, 28 Aug 2024 09:45:54 -0400 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1sjIzf-0005LR-P4 for help-gnu-emacs@gnu.org; Wed, 28 Aug 2024 15:45:51 +0200 X-Injected-Via-Gmane: http://gmane.org/ Received-SPF: pass client-ip=116.202.254.214; envelope-from=geh-help-gnu-emacs@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.help:147840 Archived-At: Stefan Monnier via Users list for the GNU Emacs text editor writes: >>> You could write a `while + looking-at` loop to do that, but if you want >>> something faster, you'll need to change the C code. >>> I don't expect it would be a difficult change, tho (it should not require >>> any significant change in the regexp engine, for example). >> I'm happy to do that, if this is an addition which is likely to be >> accepted into Emacs. > > It's hard for me to judge. OT1H it should be rather unintrusive, but > OTOH it's unsatisfying because doing the same in the other direction > (i.e. when searching forward) is much harder. > >> Should the API be a new flag in >> search-backward/re-search-backward/looking-back? Or should it maybe >> be a new special variable? > > Or new functions? It's a toss-up (I'm rather against special variables). > >> In my case this is tricky though because the thing I'm searching for >> *can* contain a newline, so it's not totally trivial to determin what >> small step is correct to take... > > A common other approach is to do a `search-forward` after the > `search-backward` to detect when `search-backward` went "too far". Oh, clever, that would indeed work for me. Could we update easy-mmode-define-navigation to use this technique, so it reliably goes to the start of the current "thing"? Again happy to make that patch. That would more directly satisfy my use case anyway, which is just "getting reliable next/prev navigation commands".