From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#15899: 24.3.50; regression: `region' overlay is lower priority than default Date: Sat, 16 Nov 2013 15:49:11 +0200 Message-ID: <528777D7.1060306@yandex.ru> 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> <52874820.2020601@yandex.ru> <83ob5kh9nb.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1384609812 844 80.91.229.3 (16 Nov 2013 13:50:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 16 Nov 2013 13:50:12 +0000 (UTC) Cc: 15899@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Nov 16 14:50:17 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 1VhgGP-0005PU-Gf for geb-bug-gnu-emacs@m.gmane.org; Sat, 16 Nov 2013 14:50:17 +0100 Original-Received: from localhost ([::1]:35901 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VhgGP-000437-0h for geb-bug-gnu-emacs@m.gmane.org; Sat, 16 Nov 2013 08:50:17 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40652) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VhgGG-00041a-4z for bug-gnu-emacs@gnu.org; Sat, 16 Nov 2013 08:50:13 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VhgGA-0005R8-99 for bug-gnu-emacs@gnu.org; Sat, 16 Nov 2013 08:50:08 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:42817) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VhgGA-0005Qs-5y for bug-gnu-emacs@gnu.org; Sat, 16 Nov 2013 08:50:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VhgG9-00080g-L5 for bug-gnu-emacs@gnu.org; Sat, 16 Nov 2013 08:50:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 16 Nov 2013 13:50: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.138460976530737 (code B ref 15899); Sat, 16 Nov 2013 13:50:01 +0000 Original-Received: (at 15899) by debbugs.gnu.org; 16 Nov 2013 13:49:25 +0000 Original-Received: from localhost ([127.0.0.1]:56836 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VhgFY-0007zh-FE for submit@debbugs.gnu.org; Sat, 16 Nov 2013 08:49:25 -0500 Original-Received: from mail-ea0-f179.google.com ([209.85.215.179]:61130) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VhgFU-0007zR-H0 for 15899@debbugs.gnu.org; Sat, 16 Nov 2013 08:49:21 -0500 Original-Received: by mail-ea0-f179.google.com with SMTP id r15so1512234ead.24 for <15899@debbugs.gnu.org>; Sat, 16 Nov 2013 05:49:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=NyC3AKOqSPcw6YFzmw/PqjaG9sQxHQyMkyT6+5tLxiE=; b=kVBx82XhpHh9ttUUqkG5eqtqRAZJDlX0mi5bDZWhRWZBIMa9Tlzc4puWGdwb+ypUiy BAjfPGC74QynH8fhgftJh5c1kpatVu8xZ1M1fqiX084YeSEOFx7JuBn1RpuWp95J9eqf d5fcVrNPI8kQhNZ4DnK/xSCByJxfaZUaOuRHwOm7pqS1OqGTfF1SNlfgAy7+CMlQ7w9z gacXJhDeSbITnNMvzgaXkuLJ/Gj8F8Akb/vTD60kKGcMyxLtb5bW+o7Tt5/G2uRNInI8 GGPvQQSIgpeu/3/k98OvftalOyjP87j6w+rh+XAQOVrfrFmLgEys5UPhYbT3jDqY0Pkk IClw== X-Received: by 10.14.175.3 with SMTP id y3mr311765eel.59.1384609754554; Sat, 16 Nov 2013 05:49:14 -0800 (PST) Original-Received: from [192.168.10.2] (62-113-224.netrun.cytanet.com.cy. [62.228.113.224]) by mx.google.com with ESMTPSA id s3sm16982744eeo.3.2013.11.16.05.49.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 16 Nov 2013 05:49:13 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 In-Reply-To: <83ob5kh9nb.fsf@gnu.org> 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:80642 Archived-At: On 16.11.2013 13:24, Eli Zaretskii wrote: > What way is that? Before region highlighting was reimplemented as an > overlay, it had a fixed "priority" that couldn't be controlled or > worked around. So what exactly did easy-kill expect from that > behavior? That behavior was broken on Leo Liu's system (don't know how) and on mine too (with some themes only). See https://github.com/leoliu/easy-kill/issues/3 for more details. > But the region always has point on one of its ends, so both the places > where point was and where it is are clearly visible when the region is > active. In many times point wasn't at any of region ends. That's how `easy-mark' works, it selects some unit of text *around* the point. > So why is there a need for the easy-mark to be visible in > that situation (which is transient and therefore short-lived)? Just for user information. Looks kinda nice. > The part of the region that overlaps the easy-mark overlay will not be > visible, if the region's priority is lower. That just means that easy-mark will need to set its priority higher than the *documented* region priority. > That's not the race I had in mind. What I had in mind was users > complaining about their favorite overlay-based features being obscured > by the region, lobbying the maintainers to increase the priorities of > those overlays above the region (and possibly also above the easy-mark > overlay), or increase the priority of the region overlay; then other > users complaining about the effects of that, and so on and so forth ad > nauseam. This will have to be solved on a package-by-package basis, like every contentious feature. One user complaint: change the priority of a package-specific overlay. More complaints to change it in different directions: add a user option that will set the priority that overlay. > How can you even assume that the "region overlay priority > won't change", given the possibility and enough pressure from users? > Once out of the bottle, this genie cannot be easily put back. Region priority will have to be set once (to 100, or something), documented, and then never changed again. Any changes will have to be made to other overlays' priorities.