From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#15899: 24.3.50; regression: `region' overlay is lower priority than default Date: Sat, 16 Nov 2013 08:23:35 -0800 (PST) Message-ID: <7031ba1e-2f47-4dd0-908a-938c26016e12@default> References: <<20137354-f982-4314-9c09-21a5fbc36557@default> <83ob5mi02j.fsf@gnu.org>> < <83bo1liv80.fsf@gnu.org>> <<87mwl58yvc.fsf@yandex.ru> <834n7dipnq.fsf@gnu.org> <5286A1AD.1080106@yandex.ru>> <<83wqk8hgtf.fsf@gnu.org> <5287403B.2060302@poczta.onet.pl>> <<83ppq0hbln.fsf@gnu.org>> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1384619062 29994 80.91.229.3 (16 Nov 2013 16:24:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 16 Nov 2013 16:24:22 +0000 (UTC) Cc: 15899@debbugs.gnu.org To: Eli Zaretskii , Jarek Czekalski Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Nov 16 17:24:26 2013 Return-path: Envelope-to: geb-bug-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 1VhifX-00052w-FN for geb-bug-gnu-emacs@m.gmane.org; Sat, 16 Nov 2013 17:24:23 +0100 Original-Received: from localhost ([::1]:36225 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VhifW-0002YE-KT for geb-bug-gnu-emacs@m.gmane.org; Sat, 16 Nov 2013 11:24:22 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34561) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VhifL-0002Y6-45 for bug-gnu-emacs@gnu.org; Sat, 16 Nov 2013 11:24:19 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VhifC-0006BG-I3 for bug-gnu-emacs@gnu.org; Sat, 16 Nov 2013 11:24:11 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:43326) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VhifC-0006BC-E2 for bug-gnu-emacs@gnu.org; Sat, 16 Nov 2013 11:24:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VhifB-0003Rw-KA for bug-gnu-emacs@gnu.org; Sat, 16 Nov 2013 11:24:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 16 Nov 2013 16:24:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15899 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 15899-submit@debbugs.gnu.org id=B15899.138461902813236 (code B ref 15899); Sat, 16 Nov 2013 16:24:01 +0000 Original-Received: (at 15899) by debbugs.gnu.org; 16 Nov 2013 16:23:48 +0000 Original-Received: from localhost ([127.0.0.1]:57345 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Vhiew-0003RP-Ja for submit@debbugs.gnu.org; Sat, 16 Nov 2013 11:23:47 -0500 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:19048) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Vhiet-0003R5-Oz for 15899@debbugs.gnu.org; Sat, 16 Nov 2013 11:23:44 -0500 Original-Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id rAGGNbuU017014 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 16 Nov 2013 16:23:38 GMT Original-Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rAGGNahZ010967 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 16 Nov 2013 16:23:37 GMT Original-Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rAGGNaFg009091; Sat, 16 Nov 2013 16:23:36 GMT In-Reply-To: <<83ppq0hbln.fsf@gnu.org>> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 12.0.6680.5000 (x86)] X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:80646 Archived-At: > Previously, Emacs users did not have the freedom to > overrule the region highlighting with an overlay face. Many > generations of Emacs users lived with that limitation and never > complained about that, at least not seriously enough to make this an > issue. Keeping the priority of the region overlay at infinity just > preserves previous behavior. No, it does not preserve previous behavior. 1. Previously, isearch highlighting took priority over region highlighting. Isearch highlighting has a large, finite value. 2. Previously, region highlighting used the `face' text property. 3rd-party code and user code and interactions that manipulate text properties will no longer work. Yes, using an overlay for the region brings other possibilities. But it takes away certain possibilities, as well (#2). > > I can't imagine an example where infinite priority is better than > > a high value. Could you help with that? >=20 > It avoids the problem of priority race. If you declare a winner ahead of time then there is no race. Big deal. Isearch needs (by default, at least) to win out over region. And why not others as well, depending on need? Why foreclose the possibility? Sure, if someone wants to fiddle with priorites then there is always the potential for escalation spiraling round. That's life with Lisp. > With an infinite priority, we can be sure the region highlighting > will always be visible, come what may. Which might not always be what someone wants. I'm all for region appearing on top, by default, as I've already argued in detail. Users need to know what they've selected. But that does not mean that someone should be prevented from doing things otherwise. > IOW, keeping the region priority above everything makes sure we > won't have another series of bug reports in the near future asking > why this or that feature makes region invisible. That's just an argument for the default behavior. "_Keeping_ the priority above everything else" is wrong. _Setting_ it above everything else (with exceptions such as isearch) by default is right.