From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Ergus Newsgroups: gmane.emacs.devel Subject: Re: isearch region or thing at point. Date: Wed, 1 May 2019 02:13:10 +0200 Message-ID: <20190501001310.xvneubg4rl7c5dit@Ergus> References: <20190427001453.isjx247kc3lu5fe4@Ergus> <87a7gcp51i.fsf@tcd.ie> <20190429004135.rn5tp2gnmbjovrxj@Ergus> <87h8agy4yf.fsf@mail.linkov.net> <20190430162501.xmqh5r5h57sjjlq5@Ergus> <87h8af15kg.fsf@tcd.ie> <20190430231614.l423x6eqta5fbhor@Ergus> <874l6f132f.fsf@tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="34863"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: NeoMutt/20180716 Cc: Juri Linkov , emacs-devel@gnu.org To: "Basil L. Contovounesios" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed May 01 02:15:34 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hLcuH-0008nF-84 for ged-emacs-devel@m.gmane.org; Wed, 01 May 2019 02:15:29 +0200 Original-Received: from localhost ([127.0.0.1]:55871 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hLcuF-0001i4-RH for ged-emacs-devel@m.gmane.org; Tue, 30 Apr 2019 20:15:27 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:44579) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hLctD-0001fr-4B for emacs-devel@gnu.org; Tue, 30 Apr 2019 20:14:26 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hLcsC-0004F5-NJ for emacs-devel@gnu.org; Tue, 30 Apr 2019 20:14:16 -0400 Original-Received: from sonic301-20.consmr.mail.ir2.yahoo.com ([77.238.176.97]:43630) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hLcsC-0004EJ-2S for emacs-devel@gnu.org; Tue, 30 Apr 2019 20:13:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1556669597; bh=Jfe+Bhf3zAgA1e3WyDxAuNJaZPFoDk2xiceJ7P9qbIU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From:Subject; b=HqTmJgrutPHX+OeQ4lg+9du3ennRLv4l/GtVV3s7UbBl+z4SAhkpUzCWM6UtUrxi3uqjYMmUbuFRMr0o85GNUdAFOb38PHOLB66ou8oUVksLTx8Eyy6N5q7PS4l9zhq4rLl0bp5ZqM8np2WA09WvDTKo1mnClLy9y6iSM6PLl////af0rHp4RMsDxjWPepBgoA6fGfl1UdVMCorpzUuVFDPdLuVqtaWq8pbOCQKC/k43vl8QV0e9PSZmE4xyN4+Rsr6wrIPsP/2EWQkNIhQvyaphigSfjwfbeT8WOw5g9AYM2gyzMNA+FHfgogmxGp0eb9uDLCUWdwwkgkLey0Gc1Q== X-YMail-OSG: VUGjFcgVM1n5LiauIgJbknIVvXgnYUyhLY083Oavd1ftpiFQ5aFUBcb.MGtGzcV mjG6vJfDmO3cboWNaMqTLBs1WycBwOuJL7rr6RnXdsfcPGMEUwg9Ih4lQR8tANKjPvEaB6dxL88D CnGzVYKXu7TgqxoL8WhSPhMTigYKXyc_DQ0HdH94XrkgJfdQnufUDx4EBZyWmWaIgkzJWxHb1O12 4..3xrl1SBZxjaecr1K6hzzfOZfudp7wzhaH_52VMv6J3AEUKou2pVyFNvqCcBO1AmvFphA_X2VR 4hX2AHwE8tHRez8HOWtas1sj0hl3DHD.u.kPv_3i6n.f_rS21.MXvnftYzpV0YcNO.Ge6Yk3WeL0 WuPzW8Hh3BA8gHU4aNKLb3r7wrTQ2PUQ6Fafq8tZE1qaQl7Tsty3eKwZJ7PX47jfFan9vLTDZmjs ZErwLjhl97Z9SuznuSqtbyxc1x9OU0FSVaLl5JGHHe1HTqA0KBNW4PQNXvQDo5jAiw5T0V__SFrS fQHUmC3326dAV513UG3slJj_b2A7PvEDlqwC.ZgZKZPTy.k6qw_UrCx1Hte97crMHt8mA11WsKxi U3K0RN5vyCwcGEDMuuopTrkTln05TVt5x9PhDbobI2pxcLQGlZS2Eju_WNh4WKB0.LmI6xC9A4BG jhP.cxOaeZuHeLX2TAZSjK56sc_oV4w0vhTafvy07Pz0IvP6_xjZnbxW20NWfpw1q02wqoMOmHhY 7M_o7jctGppDzkf8SMZR7hRWK3rClQA7No8MRLnxmUQPFF03G5wU0tFWvoMG9r9HJ2aksA75lwhL oW3AyvQ5sJz9TtZ5YGrvyIYNnQ87lkHeAADH7n5dc5 Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.ir2.yahoo.com with HTTP; Wed, 1 May 2019 00:13:17 +0000 Original-Received: from 2.152.205.184.dyn.user.ono.com (EHLO Ergus) ([2.152.205.184]) by smtp415.mail.ir2.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 09e9b563c2309c0b3fb81348ee7f1186; Wed, 01 May 2019 00:13:12 +0000 (UTC) Content-Disposition: inline In-Reply-To: <874l6f132f.fsf@tcd.ie> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 77.238.176.97 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:236084 Archived-At: Hi all!: I have 3 questions before sending all the changes I propose: 1) I provided both cases, a function isearch-forward-region and isearch-yank-region. One can be bind to M-s something and the other to M-something once in isearch-mode-map. So the user will be not forced to move to exit isearch if he is already there. But on the other hand with the yank one the other does not offer any real advantage as C-s M-w is not shorter than M-s M-w, bust a bit easier to type, but not to remember. I would like M-s M-(y?w) for the first and M-(y?w) for the second... but I still find those a bit inconsistent (and long). What do you suggest? 2) A more theoretical: Why the region-extract-function is not a normal function? Why {when|if|and|...}-let macros are in such a special file and most of the code don't use them? What's the problem with them? 3) What do you think is the right behavior in case isearch-string is not empty? Suppose you marked a region and then type: C-s letter, the cursor will move to letter, but the actual active region will be from mark->letter. Because in that case the point has already moved from it's initial position, so the region is not the same than when it started. 1) Should the command do nothing in that case? 2) Or it must yank what used to be the initial region?? 3) Something else? Best, Ergus. On Wed, May 01, 2019 at 12:33:12AM +0100, Basil L. Contovounesios wrote: >Ergus writes: > >> On Tue, Apr 30, 2019 at 11:39:11PM +0100, Basil L. Contovounesios wrote: >>>Ergus writes: >>> >>>> (region-bounds))) >>>> (contiguous (= (length bounds) 1)) ;; Region is contiguous >>> >>>Better to use the function region-noncontiguous-p. >>> >> I already had the bounds.. I didn't want to do the funcall again... but >> I know it is probably not important.. I am just an obsessed. > >The higher-level and more flexible region-extract-function will handle >this for you in any case. > >>>> (region-string (and (= (count-lines region-beg region-end) 1) >>>> (buffer-substring-no-properties >>>> region-beg region-end))) >>> >>>Why can't the region span multiple lines? Better to use >>>region-extract-function for this, as it is more flexible. >>> >> I don't thing that searching multiple lines will be very useful in >> practice and could potentially produce some corner cases. But I >> will think about that a bit more. > >AFAIK, isearch is designed to work perfectly fine with multiple lines, >and I use this feature a lot, especially in the context of lax >whitespace matches in Info manuals, for example. > >Providing a dedicated region isearch command which is limited to a >single line sounds hardly better than using isearch-yank-word-or-char or >similar. > >>>> (isearch-yank-string region-string) >>>> >>>> (when-let (count (and arg (prefix-numeric-value arg))) >>>> (isearch-repeat-forward count))) >>> >>>This can be simplified as per Noam's suggestion. >> Yes, sorry, I was concerned if somehow the prefix could be non-nil, but >> (prefix-numeric-value arg) could return nil... I don't really know the >> fancy valued that prefix could potentially have. But probably there is >> not any danger there. > >All potential prefix values are listed under (info "(elisp) Prefix >Command Arguments"), and prefix-numeric-value is guaranteed to return an >integer. > >Thanks, > >-- >Basil >