From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gregory Heytings Newsgroups: gmane.emacs.devel Subject: Re: Simple isearch concerns Date: Fri, 09 Apr 2021 15:25:08 +0000 Message-ID: <940751cee5acf0f913df@heytings.org> References: <20210403001539.x4rb55dvh46rmhb3.ref@Ergus> <20210403001539.x4rb55dvh46rmhb3@Ergus> <878s5wmsjp.fsf@mail.linkov.net> <87mtubz4ls.fsf@mail.linkov.net> <8735w22s9b.fsf@mail.linkov.net> <3ec7e2e58a3733a48ae9@heytings.org> <878s5tc0rn.fsf@mail.linkov.net> <3ec7e2e58a49d4f0ec99@heytings.org> <878s5t9p1i.fsf@mail.linkov.net> <9ff81b52fad2911cc740@heytings.org> <87im4w1tgw.fsf@mail.linkov.net> <9ff81b52fa878cb35a86@heytings.org> <87pmz4zgn5.fsf@mail.linkov.net> <83eefk802u.fsf@gnu.org> <871rbjdea4.fsf@mail.linkov.net> <8335vz91en.fsf@gnu.org> <940751cee594ef1cf8a4@heytings.org> <83zgy77hep.fsf@gnu.org> <940751cee566285b8519@heytings.org> <83wntb7eli.fsf@gnu.org> <940751cee50d69f2231d@heytings.org> <83r1jj7bhg.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="38237"; mail-complaints-to="usenet@ciao.gmane.io" Cc: spacibba@aol.com, emacs-devel@gnu.org, juri@linkov.net To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Apr 09 17:26:28 2021 Return-path: Envelope-to: ged-emacs-devel@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 1lUt1g-0009qJ-N5 for ged-emacs-devel@m.gmane-mx.org; Fri, 09 Apr 2021 17:26:28 +0200 Original-Received: from localhost ([::1]:52662 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lUt1f-0002EM-OB for ged-emacs-devel@m.gmane-mx.org; Fri, 09 Apr 2021 11:26:27 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36562) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lUt0T-0001Q1-Ro for emacs-devel@gnu.org; Fri, 09 Apr 2021 11:25:13 -0400 Original-Received: from heytings.org ([95.142.160.155]:35546) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lUt0S-0005AH-0Q; Fri, 09 Apr 2021 11:25:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20210101; t=1617981909; bh=UswvBKLKPKHREnosA8In+TO75v1mHfWIGFLEwSiVqPQ=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=DgvOTrgcm0Bq0srw4IabtFbDgCBtjg1FnNqBWKCxsujMoLOOuVEoFymS9aqOIiQ7K ttGf89v9nzenbzXTxoXyE52sG7P7pNxOFy+aRimNR2ktCAvJL8zyJGH+dVc7iKtPwU 1IQUbpGzkSqNyDfce7XkkVo/KjA/f0mtLgSApVehMh1+gbXy28O5gyx4SLK8ypoJcC 5eTvxr0ypnXzrJ8yvOhKBbbsm9gG9+fR60BGMMLNaLnonHDuSgiuMjGFxHoWG5TU1i MOpfKZKeKyxomOzaLKRYfzL9r+U7jtr8rSbBTA1P58aK4gsjWHrBZ6zdj8gE6k+YBT PGAethXsZdMxQ== In-Reply-To: <83r1jj7bhg.fsf@gnu.org> Received-SPF: pass client-ip=95.142.160.155; envelope-from=gregory@heytings.org; helo=heytings.org X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:267724 Archived-At: > > After the first "M-s M->", why do you keep pressing "M-x M->"? why not > C-s? > Why would it not be possible to jump to the last occurrence in the buffer when searching forward? >> How on earth could such a behavior be considered a feature? > > That's not the scenario I had in mind. > > But if you want the above to be useful, why not ask whoever implemented > that the question about the rationale? And since when are we fixing a > buggy behavior by modifying it in weird unexpected ways? > I don't understand your questions. This is not the behavior of isearch-{beginning,end}-of-buffer, this would be the behavior if the search direction did not change. The actual behavior is what one would expect, M-s M-< and M-s M-> have the exact same effect after C-s and C-r, with point after the occurrence and before the last occurrence respectively. Do I understand correctly that what you would have wanted is the following: 1. M-s M-< after C-s: point after the first occurrence (search direction forward) 2. M-s M-> after C-s: point after the last occurrence (search direction forward) 3. M-s M-< after C-r: point before the first occurrence (search direction backward) 4. M-s M-> after C-r: point before the last occurrence (search direction backward) What we have now is 1 and 4, but not 2 and 3, what we have instead is: 2. M-s M-> after C-s: point before the last occurrence (search direction backward) 3. M-s M-< after C-r: point after the first occurrence (search direction backward) Is this subtle nuance really important? Isn't the most likely search direction one would want to use at BOB forward, and at EOB backward? The other options are at BOB backward and at EOB forward, but this means wrapping, that is, doing what one could have done immediately with 1 and 4 above...