From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Joe Wells Newsgroups: gmane.emacs.devel Subject: Re: Fwd: overlay face property not used for after-string property Date: Mon, 05 Nov 2007 22:06:31 +0000 Message-ID: <86tzo0fiu0.fsf@macs.hw.ac.uk> References: <86r6jfz3bb.fsf@macs.hw.ac.uk> <86bqaixmxk.fsf@macs.hw.ac.uk> <86bqabjozh.fsf@macs.hw.ac.uk> <86y7ddipg5.fsf_-_@macs.hw.ac.uk> <86zlxtdopx.fsf@lola.quinscape.zz> <86d4uolonb.fsf@lola.quinscape.zz> <867ikwhcqi.fsf@macs.hw.ac.uk> <86wsswhbwb.fsf@lola.quinscape.zz> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1194300542 9920 80.91.229.12 (5 Nov 2007 22:09:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 5 Nov 2007 22:09:02 +0000 (UTC) Cc: emacs-devel@gnu.org, Stefan Monnier , rms@gnu.org To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 05 23:09:05 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1IpA7x-0000HB-RN for ged-emacs-devel@m.gmane.org; Mon, 05 Nov 2007 23:09:02 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IpA7n-0005GQ-1y for ged-emacs-devel@m.gmane.org; Mon, 05 Nov 2007 17:08:51 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IpA7i-0005El-ER for emacs-devel@gnu.org; Mon, 05 Nov 2007 17:08:46 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IpA7g-0005ER-Sr for emacs-devel@gnu.org; Mon, 05 Nov 2007 17:08:46 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IpA7g-0005EO-Ns for emacs-devel@gnu.org; Mon, 05 Nov 2007 17:08:44 -0500 Original-Received: from izanami.macs.hw.ac.uk ([137.195.13.6]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1IpA7Y-0006jS-RR; Mon, 05 Nov 2007 17:08:37 -0500 Original-Received: from lxultra1.macs.hw.ac.uk ([137.195.27.173]:43016 helo=127.0.0.1) by izanami.macs.hw.ac.uk with smtp (Exim 4.51) id 1IpA7V-0005QK-7p; Mon, 05 Nov 2007 22:08:33 +0000 Original-Received: (nullmailer pid 16063 invoked by uid 1001); Mon, 05 Nov 2007 22:06:31 -0000 In-Reply-To: <86wsswhbwb.fsf@lola.quinscape.zz> (David Kastrup's message of "Mon\, 05 Nov 2007 17\:53\:24 +0100") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) X-detected-kernel: by monty-python.gnu.org: Error: This connection is not (no longer?) in the cache. X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:82601 Archived-At: David Kastrup writes: > Joe Wells writes: > >> David Kastrup writes: >> >>> Stefan Monnier writes: >>> >>>>> I think that the before-string should, in effect, use >>>>> (get-char-property (overlay-start ov) 'face) >>>>> to determine the face to use if no fully specified face is in the >>>>> before-string. >>>> >>>> No. Go read the beginning of this thread again where I explained >>>> why this is bad: it's (much) harder to remove a face than to add >>>> one. >>> >>> Then our problem is that it is much harder to remove a face than to >>> add one. And that is the problem we should fix. >> >> It's not actually an issue of =E2=80=9Cremoving=E2=80=9D a face. The is= sue is >> actually =E2=80=9Cpreventing inheritance=E2=80=9D of a face. >> >>>> Also text-properties should not affect before/after-strings. >>> >>> I don't see why not if they are appropriately sticky. >> >> An example application is linum.el. This code needs to display >> strings at the beginning of each line and the strings need to be >> displayed with a face independent of the face of the adjacent text >> (regardless of whether there are sticky text properties there). > > That's what I say: instead of making the behavior illogical in order > to default to some behavior good for some application, we should add > the facility for the application to explicitly request the behavior it > needs. The current behavior is illogical, so I don't understand your complaint. Also, I believe adding a feature to try to block inheritance in some cases will lead to a specification that is too complicated to understand. It is simpler to have fewer inheritances occur in the first place. >>> Resolving partially specified faces goes through priorities. If >>> there are usage cases for before/after-string that should not >>> inherit, then we need to add a way to say "completely resolve to >>> 'default (or whatever other face) here". Then things like lineno >>> can use that way. >> >> The idea of =E2=80=9Ccompletely resolve to default=E2=80=9D sounds inter= esting >> (independently of what we are discussing). >> >>> But it does not make sense to substitute a missing facility with >>> some fixed but illogical rules that cater for some but not all use >>> cases because it is easier to override this in that manner. >> >> The problem is that the existing rules are already illogical > > Because of a bug. I agree that there is a bug. I don't know what you think the bug is. For me, the bug is that a face given by a text property in the buffer can affect the display of before-string and after-string properties of overlays. I would be willing to allow this for overlays with negative priority. That could be a useful meaning for negative priorities (which currently have no meaning). >> and we are trying to figure out how to make them less illogical. > > What I see happening is that the current bug is used as an excuse to > establish a different inconsistent behavior as "correct", based on > convenience for some applications. Actually, we are trying to propose a more consistent behavior (which is also more useful). > Basically "if we are being > inconsistent, we might as well be inconsistent in a more convenient > manner." I think it is perfectly consistent to think =E2=80=9Conly higher priority f= ace properties affect a piece of text=E2=80=9D, with text properties in the buf= fer being considered to have the lowest priority (or priority zero if we now decide to allow negative overlay priorities). > And I do not consider this a good idea. If the consistent and logical > behavior is inconvenient for some applications, we need to add the > facilities for overriding it. But the override should not become a > fixed default. As I mention above, I think adding a facility for preventing certain cases of face inheritance will make things too complicated, and it is better to remove the problematic cases of inheritance. --=20 Joe