From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gregory Heytings via "Emacs development discussions." Newsgroups: gmane.emacs.devel Subject: Re: buffer-face-set changes the fringe, is it a bug? Date: Mon, 6 Jul 2020 19:08:39 +0200 (CEST) Message-ID: References: <2E75863E-82E2-4D61-AD34-0282362C6E99@gnu.org> <835zb2t1t8.fsf@gnu.org> <83lfjwsiin.fsf@gnu.org> Reply-To: Gregory Heytings Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29337"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Alpine 2.21 (NEB 202 2017-01-01) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Jul 06 19:20:50 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jsUnS-0007YQ-3a for ged-emacs-devel@m.gmane-mx.org; Mon, 06 Jul 2020 19:20:50 +0200 Original-Received: from localhost ([::1]:57698 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jsUnR-0000R6-1Y for ged-emacs-devel@m.gmane-mx.org; Mon, 06 Jul 2020 13:20:49 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34634) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jsUc6-0000jk-6R for emacs-devel@gnu.org; Mon, 06 Jul 2020 13:09:06 -0400 Original-Received: from mx.sdf.org ([205.166.94.18]:53532) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jsUc3-0007XV-UC for emacs-devel@gnu.org; Mon, 06 Jul 2020 13:09:05 -0400 Original-Received: from sdf.org (IDENT:ghe@faeroes.freeshell.org [205.166.94.9]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 066H8jBu029729 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Mon, 6 Jul 2020 17:08:46 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sdf.org; s=default; t=1594055327; bh=Iv8rH6Mn0dod24Mx8+Vgy5QROmzvUVc8UGlHaLWmDQs=; h=Date:From:To:Subject:In-Reply-To:References; b=PT/ZKtD1fBFze5rkMZPa1QPhO7KZHhMR4qDq/E9MqHdrE64jjAWiTHW4XQu8kxW7j 4U/mmv7Edp71+J+rtkQPLwqzv43w+Nv1O+N15HmAKkSAzgvoyOGrX/j470UKalnPcP 2yex8v8vKt2cYL+4arAW0aYkGLl9UIicYEd1m4h4= Original-Received: (from ghe@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 066H8gRk005041; Mon, 6 Jul 2020 17:08:42 GMT In-Reply-To: <83lfjwsiin.fsf@gnu.org> Received-SPF: none client-ip=205.166.94.18; envelope-from=ghe@sdf.org; helo=mx.sdf.org X-detected-operating-system: by eggs.gnu.org: First seen = 2020/07/06 13:09:00 X-ACL-Warn: Detected OS = ??? X-Spam_score_int: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, SPF_HELO_PASS=-0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:252729 Archived-At: > >> So it seems that it's only when a face remapping takes place that an >> omitted face in [1] means using the default face. Before the face >> remapping takes place, the fringe face is used instead. > > No, it uses the default face, but the result is produced slightly > differently (not by actually merging the two faces). > Sorry, but that doesn't make any sense. The default face does not contain any blue or red, it's black on white. So how could blue or red enter into the face when no face is specified (i.e. when the face is omitted)? At the very least, this is not what one understands with the (previous or current) documentation. I'm not entirely sure, but apparently the logic in draw_fringe_bitmap_1() is to take DEFAULT_FACE_ID as an initial value for face_id, and if face_id is not set explicitly to a different value, to reset its value to FRINGE_FACE_ID. In handle_single_display_spec(), face_id is initially set to DEFAULT_FACE_ID, which means (given the above) that when face is omitted it is FRINGE_FACE_ID that will in fact be used. When face is 'fringe' the derived face that is created is equivalent to FRINGE_FACE_ID. When face is explicitly set to 'default', a derived face is created, and is subjected to face remappings in the buffer. I think again that this is a bug, and that one should have (if my understanding is correct), in handle_single_display_spec(): int face_id = lookup_fasic_Face (it->f, FRINGE_FACE_ID); instead of: int face_id = lookup_basic_face (it->f, DEFAULT_FACE_ID); Gregory