From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: isearch region or thing at point. Date: Sat, 4 May 2019 08:24:21 -0700 (PDT) Message-ID: <19478b8e-f8cb-48cd-9231-dd82b42b734b@default> References: <20190429004135.rn5tp2gnmbjovrxj@Ergus> <87h8agy4yf.fsf@mail.linkov.net> <20190430162501.xmqh5r5h57sjjlq5@Ergus> <87h8af15kg.fsf@tcd.ie> <20190430231614.l423x6eqta5fbhor@Ergus> <874l6f132f.fsf@tcd.ie> <20190501112025.fnsynkbmkvllapyv@Ergus> <83y33mlgdb.fsf@gnu.org> <20190504121526.mslnh3xqgc64dy7t@Ergus> <45220b6f-8236-41fa-a520-fd7c562072da@default> <20190504145636.34kaiqrji7zxsdhh@Ergus> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="257921"; mail-complaints-to="usenet@blaine.gmane.org" Cc: contovob@tcd.ie, Eli Zaretskii , emacs-devel@gnu.org, juri@linkov.net To: Ergus Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat May 04 17:24:48 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 1hMwWt-0014y7-6r for ged-emacs-devel@m.gmane.org; Sat, 04 May 2019 17:24:47 +0200 Original-Received: from localhost ([127.0.0.1]:57853 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hMwWr-0008HA-UH for ged-emacs-devel@m.gmane.org; Sat, 04 May 2019 11:24:45 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:34303) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hMwWg-0008H4-Es for emacs-devel@gnu.org; Sat, 04 May 2019 11:24:35 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hMwWf-00071h-8c for emacs-devel@gnu.org; Sat, 04 May 2019 11:24:34 -0400 Original-Received: from userp2120.oracle.com ([156.151.31.85]:32834) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hMwWd-00070T-Cj; Sat, 04 May 2019 11:24:31 -0400 Original-Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x44F3lsP024494; Sat, 4 May 2019 15:24:24 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=1ZO8PaPlUGZtF2yI+pD1m908wfpmvAwbJec3gOdEcjI=; b=HIFJ8/ZOA7nhpiAyt8w/PJ6TKhvMl6FkjNtxbNyeQnztEKGfrimLVBQHj6FQ/LUo7i+b 5UW1Zr8ulyjhDzQU99RC8ABxb25qrDfuscCGAeCfo1MBtESsDUsAoFzTnGqm+eeSNfAP JlMYj15jZQZ6T8fOkymoLQe9lb6/V1tjo3HReXXRzY721xFA5Wi5gSlJgLub0oD97MQ3 SMW2+M0NB3DuNQz6//wGWLc4p9CUeiieymCzna9KO7PskWuIK5fepa8XOF4AH1izQJpv cpY/Vbyg5f0lvjq7zY4u3wBRafjyCI9fFF1CILQORA7Y4Js18I/jyPvOJraW2CJkI25w ig== Original-Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by userp2120.oracle.com with ESMTP id 2s94b090vs-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 04 May 2019 15:24:24 +0000 Original-Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1]) by aserp3030.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x44FMxFt169115; Sat, 4 May 2019 15:24:23 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserp3030.oracle.com with ESMTP id 2s94b8c2qc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 04 May 2019 15:24:23 +0000 Original-Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id x44FOMgY024027; Sat, 4 May 2019 15:24:22 GMT In-Reply-To: <20190504145636.34kaiqrji7zxsdhh@Ergus> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4834.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9247 signatures=668686 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-1810050000 definitions=main-1905040103 X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9247 signatures=668686 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1905040103 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] X-Received-From: 156.151.31.85 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:236151 Archived-At: > >> This patch has changed a lot because some others made suggestions I > >> considered useful. I will attach the new patch in another mail. > >> > >> On the other hand it makes sense that M-w should be used in case the > >> user wants to add the text in the minibuffer to the kill-ring. > >> (Something like isearchp-kill-ring-save) > >> > >> So maybe M-r (region) or M-i (insert) must be used for what I propose > >> and Drew may add the isearch-kill-ring-save function he wrote and bind > >> it to M-w. That way there will be all the copy functionalities in plac= e. > > > >I would prefer that, yes. `M-w' to copy to the > >kill-ring (as usual). > > > >Do you need an actual patch to include the command > >I sent, or can you please just include it (renaming > >prefix `isearchp-' to `isearch-')? >=20 > >> But then we must recommend bind M-r or M-i (or whatever) for similar > >> functionalities. And if possible correct other modes to be consistent > >> with that (if that does not start a religious war here please). > > There are similar modes with commands to copy text from region into > minibuffer and all them use different bindings. I just propose to unify > that somehow when possible. > > >Sorry, I don't know what you mean, there. `M-r' is > >(and has long been) `isearch-toggle-regexp'. > > Sorry, I forgot that, So the only alternative is M-i. There are other alternatives, too (but I'm not saying they are necessarily better). We have prefix `M-s', for example. But aside from a few, I prefer that we use it for toggle commands. Vanilla Emacs uses it for these: M-s C-e=09isearch-yank-line M-s SPC=09isearch-toggle-lax-whitespace M-s '=09=09isearch-toggle-char-fold M-s _=09=09isearch-toggle-symbol M-s c=09=09isearch-toggle-case-fold M-s e=09=09isearch-edit-string M-s h r=09isearch-highlight-regexp M-s i=09=09isearch-toggle-invisible M-s o=09=09isearch-occur M-s r=09=09isearch-toggle-regexp M-s w=09=09isearch-toggle-word (Note that we already give 2 bindings to `isearch-toggle-case-fold', which we need not do.) And Isearch+ uses `M-s' additionally for these: M-s M-SPC isearchp-toggle-set-region M-s M-k isearchp-toggle-repeat-search-if-fail M-s # isearchp-toggle-showing-match-number M-s % isearchp-toggle-limit-match-numbers-to-region M-s h L isearchp-toggle-lazy-highlighting M-s h R isearchp-toggle-highlighting-regexp-groups M-s h b isearchp-toggle-lazy-highlight-full-buffer M-s h d isearchp-toggle-dimming-filter-failures M-s h f isearchp-highlight-matches-other-face M-s h h hlt-highlight-isearch-matches M-s h l isearchp-toggle-lazy-highlight-cleanup M-s h u hlt-unhighlight-isearch-matches M-s u f isearchp-unhighlight-last-face M-s v isearchp-toggle-option-toggle > >> I will try to do the same for replace-like commands. > > > >(Not sure what you mean by that, either.) >=20 > When region is active; replace-string (and related) limits the replaces > to the active region. But alternatively we could provide a simple hint > that inserts the region text into minibuffer and deactivate it, so > instead of limiting the replace to the region, the region can be used as > the string to replace. >=20 > M-w M-% C-y RET =3D> M-% M-i >=20 > Or similar. Got it. I agree that for Isearch and other things, such as replacement, there are at least those two very different ways to use the active region: 1. Copy its content to the kill ring (or the secondary selection or a register or...). 2. Limit the action to the region (e.g., limit search or replacement to the region). That was in fact one of the points underlying my message, though I didn't state it explicitly. Replacement commands already let you limit the action to the active region, even in vanilla Emacs. Isearch+ (but not yet vanilla Isearch) also lets you limit the search to the active region. And in general when the region is active, the typical change in behavior a command makes is to act on the region instead of the whole buffer or the part of it following point. I agree that it might be good to have key bindings that consistently reflect this difference - these two different ways to use the active region. There are additional ways in which a command can make use of the active region, of course. But these two stand out as fairly general possibilities. It would be good to "standardize" bindings - say reserve `M-w' (e.g. on a prefix key) for the "copy-region" (or similar) action, and find another key (e.g. on a prefix key) for the "limit-to-region" action.