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: Fri, 15 Nov 2013 19:47:37 -0800 (PST) Message-ID: References: <20137354-f982-4314-9c09-21a5fbc36557@default> <83ob5mi02j.fsf@gnu.org> <1519bff5-bf9d-42bc-8993-d96153f0004f@default> 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 1384573701 32305 80.91.229.3 (16 Nov 2013 03:48:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 16 Nov 2013 03:48:21 +0000 (UTC) Cc: 15899@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Nov 16 04:48:24 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 1VhWrw-0007J2-AW for geb-bug-gnu-emacs@m.gmane.org; Sat, 16 Nov 2013 04:48:24 +0100 Original-Received: from localhost ([::1]:34656 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VhWrv-0003y7-Ab for geb-bug-gnu-emacs@m.gmane.org; Fri, 15 Nov 2013 22:48:23 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50008) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VhWrj-0003xB-MW for bug-gnu-emacs@gnu.org; Fri, 15 Nov 2013 22:48:20 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VhWrb-0006TH-3v for bug-gnu-emacs@gnu.org; Fri, 15 Nov 2013 22:48:11 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:42441) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VhWrb-0006TD-0Y for bug-gnu-emacs@gnu.org; Fri, 15 Nov 2013 22:48:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VhWra-0008KN-LC for bug-gnu-emacs@gnu.org; Fri, 15 Nov 2013 22:48:02 -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 03:48:02 +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.138457367131994 (code B ref 15899); Sat, 16 Nov 2013 03:48:02 +0000 Original-Received: (at 15899) by debbugs.gnu.org; 16 Nov 2013 03:47:51 +0000 Original-Received: from localhost ([127.0.0.1]:56460 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VhWrO-0008Jv-OX for submit@debbugs.gnu.org; Fri, 15 Nov 2013 22:47:51 -0500 Original-Received: from userp1040.oracle.com ([156.151.31.81]:51194) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VhWrM-0008Jf-Dm for 15899@debbugs.gnu.org; Fri, 15 Nov 2013 22:47:49 -0500 Original-Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id rAG3ldrH027478 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 16 Nov 2013 03:47:40 GMT Original-Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rAG3lcDf001773 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 16 Nov 2013 03:47:38 GMT Original-Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rAG3lcrq001768; Sat, 16 Nov 2013 03:47:38 GMT In-Reply-To: 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:80626 Archived-At: > > The fact that face `region' highlights "on top of" other > > highlighting is _on purpose_, i.e., by design. >=20 > No, it was the result of the implementation technique, no > of design. You "accidentally" cut off that first line, where I said _what_ was by design. I've put it back, to restore the message honestly. How do you know that Emacs Dev did not _intend_ for the region display to appear "on top of" other highlighting (with the exception of isearch)? I don't believe for a second that this was by accident or just a result of an "implementation technique". Not until you can show some supporting evidence for that claim. Without contrary evidence, I am persuaded that Emacs, like every other app that uses selection, chose this behavior for its _user-level_ effect: The point is to show users just what is selected. There is no better reason to make such a choice. =20 Result of an "implementation technique", indeed! And there were already lots of other UIs that showed selection highlighting, before Emacs added its own. Just as for menus, tooltips, mouse-face highlighting, links, text attributes, and much of the rest of the Emacs UI, these things were developed first outside Emacs and only later (sometimes much later) emulated by and added to Emacs. Emacs got its selection highlighting design from others, not as a result of some Emacs "implementation technique". Users everywhere expect a selection highlight to show them clearly what they've selected. That, and not some unspoken "implementation technique", is the reason that Emacs Dev showed the region face clearly throughout the region selected. Up until this regression, that is. If what is now the behavior remains, then Emacs will be the only UI I'm aware of that does not have selection highlighting override other highlighting in appearance - the only one where _you cannot know what you've selected_ based on highlighting. Can you name another UI that does that? This is really, really silly. Usability out the window - poof. Users will have no idea what they are selecting. Except in lucky cases. And even then they will have to remain unsure, because there is no way to tell whether what they are seeing highlighted as selected is really everything that is selected or just some of it. > Usually the context makes it pretty clear, "Usually" there is no other highlighting of the same text. So what? This usual case is not what the bug is about. > and if the user is surprised at some point, that surprise > will most likely not last very long Wrong. They will need to remain unsure - there is no way to know whether something unhighlighted with face `region' is in fact selected. And even if you were right that user confusion would "most likely not last very long" (based on what?), there is _no reason_ that users have to be confused about selection coverage at all. This-won't-hurt-long is no consolation, because there is no need to inflict pain in the first place. No reason not to show them the region highlighted normally.