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 13:21:19 -0800 (PST) Message-ID: <5cfb2403-7f6c-4f6a-8c67-46b91eed47fb@default> References: <<78b8713a-e96f-4b4d-990a-3af59ebdf942@default>> <<83zjp5h33w.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 1384550539 30790 80.91.229.3 (15 Nov 2013 21:22:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 15 Nov 2013 21:22:19 +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 Fri Nov 15 22:22:23 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 1VhQqM-0003eU-3i for geb-bug-gnu-emacs@m.gmane.org; Fri, 15 Nov 2013 22:22:22 +0100 Original-Received: from localhost ([::1]:33951 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VhQqL-0004Nc-F5 for geb-bug-gnu-emacs@m.gmane.org; Fri, 15 Nov 2013 16:22:21 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58959) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VhQqA-0004L0-S3 for bug-gnu-emacs@gnu.org; Fri, 15 Nov 2013 16:22:19 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VhQq2-0001Ct-7x for bug-gnu-emacs@gnu.org; Fri, 15 Nov 2013 16:22:10 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:42238) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VhQq2-0001Cn-4T for bug-gnu-emacs@gnu.org; Fri, 15 Nov 2013 16:22:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VhQq1-0007CO-Tk for bug-gnu-emacs@gnu.org; Fri, 15 Nov 2013 16:22: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: Fri, 15 Nov 2013 21:22: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.138455049327636 (code B ref 15899); Fri, 15 Nov 2013 21:22:01 +0000 Original-Received: (at 15899) by debbugs.gnu.org; 15 Nov 2013 21:21:33 +0000 Original-Received: from localhost ([127.0.0.1]:56257 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VhQpX-0007Bd-SM for submit@debbugs.gnu.org; Fri, 15 Nov 2013 16:21:32 -0500 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:42951) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VhQpV-0007BL-4r for 15899@debbugs.gnu.org; Fri, 15 Nov 2013 16:21:30 -0500 Original-Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id rAFLLLPC014743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 15 Nov 2013 21:21:22 GMT Original-Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rAFLLKmA016143 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Nov 2013 21:21:21 GMT Original-Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rAFLLKMt016120; Fri, 15 Nov 2013 21:21:20 GMT In-Reply-To: <<83zjp5h33w.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: ucsinet21.oracle.com [156.151.31.93] 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:80615 Archived-At: > > 1. I meant that the change to the behavior of the region not > > appearing "on top of" other highlighting (except isearch) > > needs to be reverted (undone). >=20 > You cannot revert behavior, only the code. I added "(undone)", to be clear. And no, code is not the only thing that can be reverted. When you revert a buffer using `g', you are reverting behavior/effects, not reverting code. Revert just means to go back to a previous state. > If the new implementation has unwanted side effects, those side > effects need to be fixed by further changes. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ No, that is not the need. The need is to remove the unwanted side effects - sure. But that does not imply keeping the culprit code and then trying to make "further changes" to make things right. That is only one possible approach. It is not _necessary_ to follow that approach -there is no such "need". Another approach is to (1) revert the code changes that brought about the regression and then (2) fix the bug those changes were intended to fix in some other way. That is, assuming there really was a bug to be fixed. Can you say what it was? If so, can you also say why keeping the changes made so far and applying (unknown) "further changes" is the best way to go? > > 4. If it was in fact a bug, it's not clear why the fix for it > > needed to involve changing region highlighting to use an > > overlay. Not clear to me anyway. >=20 > It doesn't have to be clear. I assume you mean that it does not have to be clear to me. Hopefully you agree that it has to be clear to someone. Is it clear to you? If so, do tell, pray. > The fact that region highlighting now uses an overlay is an > implementation detail. No, it is not. Why? Because Emacs _users_ do things with buffer text, and with text properties, and with overlays. These are not simply implementation artifacts. They are first class Emacs thingies that can be and are manipulated by Emacs users. Some users might not care whether some particular highlighting is via a text property or an overlay. Other users might care. Depends on what they are doing. Users interact with Emacs in lots of ways besides interactive use of `emacs -Q' commands and menus. They add text properties, examine them, change them, search their text, change their text,... This is a passably big change for Emacs Users. Emacs has used text property `face' to "implement" region highlighting ever since such highlighting has existed. Why no proposal for such a change? No discussion? > Bug reports should generally remain on the level of behavior, > i.e. requirements, they should not normally go to the > implementation level. What is the _behavioral requirement_ that obliges the use of an overlay for the region? Can you answer that? I've seen nothing so far. Talk about text properties vs overlays is on the user level, as well as the developer level. It is mistaken to think that it is something hidden to users inside some "implementation level". > The implementors should have freedom to implement the > required behavior as they see fit, as long as the results are > reasonable. Sure they should. But just what is the required behavior here? And how relative is that "freedom"? And what is the community of "implementors" that should enjoy this freedom? "The implementors" are not a separate breed from Emacs users. We are in this together. ("The educator himself must be educated." - Theses on Feuerbach) > > My suggestion is to first revert the code change and then > > discuss what the bug is that it was intended to fix. If > > there is really a bug that needs fixing, then let's please > > try to find some other, non-shotgun fix for it. >=20 > Again, please stay on the level of required behavior, and > leave the implementation out of this discussion. Something wrong with discussing implementation among "implementors"? Among users too? Not at all. > As long as there's no evidence that the new implementation ^^^^^^^^^^^ > cannot possibly accommodate the required behavior, the ^^^^^^^^^^^^^^^^^^^^^^^^^^^ > implementation can stay. Setting the bar a bit high, aren't you? Balderdash. As long as there is no evidence that the _old_ implementation "cannot possibly accommodate" other changes that fix the bug, the old implementation can stay. You are being simplistic here. The new implementation is not the One Tried & True that cannot be questioned. It is not arguments against the new implementation that need to be proved beyond a reasonable doubt. That's backwards. What should be demonstrated is why we should choose a new region implementation. This change has not even been released yet - why on Earth put up a wall of "as long as there is no evidence that it cannot possibly accommodate"? As if it were enshrined in unquestionable tradition. It's bad enough to defend a longstanding and proven status quo dogmatically. It's downright ridiculous to do so for a change that is only a few days old and has not yet seen the Light of User Day. Is there even any "evidence" that there was a bug to be fixed? Again, can you say what the bug is, clearly and not referring to implementation? IOW: This is the _requirement_, in terms of behavior: _____ And this is why it is better to fix the remaining problems caused by the recent "fix" than it is to start over with a different fix: _______