From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.help Subject: RE: killing the result of isearch Date: Tue, 7 Nov 2017 14:54:40 -0800 (PST) Message-ID: <3d8cb47d-ca09-4302-9d70-de64006fcb5f@default> References: <433bd3d0-a506-4d89-9d10-dcbfb0e23be0@default> <852BAA28-2A50-4AD9-B8D6-9F06905A4395@gmail.com> <87r2tava5x.fsf@hornfels.zedat.fu-berlin.de> <87y3nigy86.fsf@hornfels.zedat.fu-berlin.de> <87wp32f7os.fsf@hornfels.zedat.fu-berlin.de> <29AEE45F-D0CA-442F-8F46-E290C40782B4@gmail.com> <97361DF0-A104-4FC4-B16B-5ADCBDD0E35C@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1510095327 14792 195.159.176.226 (7 Nov 2017 22:55:27 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 7 Nov 2017 22:55:27 +0000 (UTC) To: Jean-Christophe Helary , Help Gnu Emacs mailing list Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Tue Nov 07 23:55:21 2017 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eCCm8-0003cr-KQ for geh-help-gnu-emacs@m.gmane.org; Tue, 07 Nov 2017 23:55:20 +0100 Original-Received: from localhost ([::1]:56220 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eCCmG-0004K1-2r for geh-help-gnu-emacs@m.gmane.org; Tue, 07 Nov 2017 17:55:28 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42508) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eCCle-0004Jk-VP for help-gnu-emacs@gnu.org; Tue, 07 Nov 2017 17:54:51 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eCClb-0003Nm-02 for help-gnu-emacs@gnu.org; Tue, 07 Nov 2017 17:54:51 -0500 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:39626) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eCCla-0003NS-Oo for help-gnu-emacs@gnu.org; Tue, 07 Nov 2017 17:54:46 -0500 Original-Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id vA7Mshs3008354 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 7 Nov 2017 22:54:44 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id vA7Msh0H005080 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 7 Nov 2017 22:54:43 GMT Original-Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id vA7MsfmC032468; Tue, 7 Nov 2017 22:54:42 GMT In-Reply-To: <97361DF0-A104-4FC4-B16B-5ADCBDD0E35C@gmail.com> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4600.0 (x86)] X-Source-IP: userv0022.oracle.com [156.151.31.74] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] [fuzzy] X-Received-From: 141.146.126.69 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.help:114799 Archived-At: > >> I am actually talking about expectations from using emacs where region= s > >> are highlighted, like what isearch seems like doing. What I am seeing = is > >> what looks like a region (and except for the active match, all the > others > >> are highlighted exactly as a region would be), but it doesn't act like= a > >> region. So there is a UI promise that's broken. > > > > That's not what I see in vanilla Emacs: `emacs -Q'. >=20 > Interesting. When I do that on one of my local files (with an emacs I bui= lt > a few days ago) I do get the current match highlighted in purple and the > other matches highlighted in blue (after testing a region is highlighted = in > a slightly different color). The cursor is blinking at the end of the fir= st > match. >=20 > So it looks as I wrote: this looks like a region, with a cursor blinking > where point it, but it does not act as one. >=20 > What matters here is not the color, but the fact that point has moved and > something that looks like a region is formed. Hence the expectation. And > really, if that "object" exists on screen, I'd love to be able to capture > it somehow. OK, so you feel that any highlighting that shows a different background from the default background, and where the cursor is at one end of a stretch of such highlighting, "looks like a region". To you it looks as if that text has been selected, available to act on (e.g. cut, copy, replace). Emacs uses background highlighting for lots of different things, and sometimes the cursor is at the end of such a highlighted stretch of text. If you use your interpretation then you are likely to be disappointed from time to time - such highlighting does not, in general, indicate "the" Emacs region. Fortunately, you can customize Emacs faces, so you could, in order not to be confused, customize all faces that by default highlight the background, so that they no longer do so. You can easily change them to highlight the foreground instead, for example. There are not that many, and changing them all is easily done. Use `M-x list-faces-display' to see which faces you use have that problem. The ones I see, by default (`emacs -Q') are: cursor fringe header-line header-line-highlight isearch isearch-fail lazy-highlight match menu mode-line mode-line-highlight mode-line-inactive next-error query-replace secondary-selection show-paren-match show-paren-match-expression show-paren-mismatch tool-bar tooltip trailing-whitespace tty-menu-disabled-face tty-enabled-face tty-menu-selected-face Some of those (e.g., fringe, the mode-line ones) are used in non-buffer-position places, where you cannot place the cursor anyway, so you need not change them - no possible confusion with region highlighting there.