From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Yuri Khan Newsgroups: gmane.emacs.help Subject: Re: automatic selection during search Date: Thu, 26 Sep 2013 23:01:52 +0700 Message-ID: References: <67ac7987-7f15-4603-a34f-7e5dbc366265@default> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1380211369 16795 80.91.229.3 (26 Sep 2013 16:02:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 26 Sep 2013 16:02:49 +0000 (UTC) Cc: "help-gnu-emacs@gnu.org" , Barry Margolin To: Drew Adams Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Thu Sep 26 18:02:53 2013 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VPE1h-0007sW-4U for geh-help-gnu-emacs@m.gmane.org; Thu, 26 Sep 2013 18:02:49 +0200 Original-Received: from localhost ([::1]:58748 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VPE1g-0003IQ-Hq for geh-help-gnu-emacs@m.gmane.org; Thu, 26 Sep 2013 12:02:48 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46753) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VPE0s-0002Qp-9U for help-gnu-emacs@gnu.org; Thu, 26 Sep 2013 12:02:02 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VPE0n-0007pN-MY for help-gnu-emacs@gnu.org; Thu, 26 Sep 2013 12:01:58 -0400 Original-Received: from mail-lb0-x232.google.com ([2a00:1450:4010:c04::232]:35902) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VPE0n-0007p8-FK for help-gnu-emacs@gnu.org; Thu, 26 Sep 2013 12:01:53 -0400 Original-Received: by mail-lb0-f178.google.com with SMTP id z5so1278039lbh.9 for ; Thu, 26 Sep 2013 09:01:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=vni3fFInUllIqSw/OWF3NzxSBcTxow+vghZ+pzJxA4U=; b=W3PMAeB+CT0sHIzKYGRkyz0i/WpDrq8J1Ws1soA++KTvpUvB2/zGn1x5d/7qnPcGZL zNa+f84Wy0uWO14hARE+ARfaGxeV2mhB4mJo8F2g0whylYuZBn2cNXWaNDN5wiWMavSG 7/7nIWjBmFvxTsWzqkXGHsVRYTjS1V27XF6c1ZhR6wTni4YyvXuduxEjZB828nNgfNrV IqNDeziRXwSLjkcv6E73BlNZRxfRFOw6z3dqxC56UptLKYeB74T3sGhQQBPY6xPNL/xY gzIwcoylvAbE/EdyuD/K2FuZYH73gTPyZJIyAPwsk6GKWLXqvRxLgWf9APt0pdvOsDmH 0mrw== X-Received: by 10.152.120.5 with SMTP id ky5mr1307706lab.18.1380211312247; Thu, 26 Sep 2013 09:01:52 -0700 (PDT) Original-Received: by 10.114.185.101 with HTTP; Thu, 26 Sep 2013 09:01:52 -0700 (PDT) In-Reply-To: <67ac7987-7f15-4603-a34f-7e5dbc366265@default> X-Google-Sender-Auth: tmNpn3T_5u-LvdTbBoBvvayl1ww X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c04::232 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 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.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:93614 Archived-At: On Thu, Sep 26, 2013 at 10:43 PM, Drew Adams wrote: > It's fine for a given user to add such behavior via a hook, if s?he wants= . > > But the behavior of extending the active region during Isearch should not= be > considered a bug. A priori, Isearch should make no decisions about chang= ing > the region activation. Leave it up to the user. Extending after set-mark or cua-set-mark is understandable and intuitive. Extending after kill-ring-save, copy-region-as-kill or cua-copy-region is not. Before this thread showed up, I wasn=E2=80=99t even able to connect the region extending with the act of copying. All I knew was that isearch *sometimes* unpredictably causes the region to extend when I expect it to deactivate. > FWIW, Isearch+ gives you choices in behavior wrt the active region, decid= ed by > options `isearchp-deactivate-region-flag' and `isearchp-restrict-to-regio= n-flag'. > > * Non-nil `isearchp-deactivate-region-flag' means deactivate the region b= efore > searching, so you can better see the text etc. If nil, you get the ordi= nary > Isearch behavior: no deactivation. > > * Non-nil `isearchp-restrict-to-region-flag' limits searching to the acti= ve > region. If nil, you get the ordinary Isearch behavior: no restriction = of > searching to the region. Both options are only useful for persistent region. For us CUA types, isearch should deactivate the region the same as every other point movement command, *except* if the current region has explicitly been made persistent by the user invoking set-mark.