From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Question about display engine Date: Wed, 07 Aug 2019 18:01:12 +0300 Message-ID: <83o911aukn.fsf@gnu.org> References: <20190807005411.qfzzpz5cjrajbwn2@Ergus> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="58460"; mail-complaints-to="usenet@blaine.gmane.org" Cc: emacs-devel@gnu.org To: Ergus Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Aug 07 17:02:17 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hvNSC-000F4a-ES for ged-emacs-devel@m.gmane.org; Wed, 07 Aug 2019 17:02:16 +0200 Original-Received: from localhost ([::1]:42206 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hvNSB-0002Ze-DP for ged-emacs-devel@m.gmane.org; Wed, 07 Aug 2019 11:02:15 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47605) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hvNRe-0002No-J2 for emacs-devel@gnu.org; Wed, 07 Aug 2019 11:01:51 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:45990) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hvNRY-0006Sa-8E; Wed, 07 Aug 2019 11:01:37 -0400 Original-Received: from [176.228.60.248] (port=3529 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hvNRK-0004sm-Q4; Wed, 07 Aug 2019 11:01:27 -0400 In-reply-to: <20190807005411.qfzzpz5cjrajbwn2@Ergus> (message from Ergus on Wed, 7 Aug 2019 02:54:11 +0200) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:239225 Archived-At: > Date: Wed, 7 Aug 2019 02:54:11 +0200 > From: Ergus > Cc: emacs-devel@gnu.org > > Sorry to bother with this. Sorry for not answering sooner: I needed to find time to re-read the relevant code and recollect the consequences. > Fixing the issue 36858 in text mode I found that the > extend_face_to_end_of_line uses the same face for the last char in the > line. Yes. > This is useful to extend selection face the whole line, but this created > a difference with gui emacs when the last face was underlined or > overlined because in tui the underline is extended for the entire line. The issue is more general, and not limited to the underline attribute. See below. > To fix this I need to create a new face to extend until the end of the > line that has the same properties than it->face_id except that the > underline and overline properties will be disabled. Why only underline and overline? And why do you think you can reset these attributes at will in this case? Suppose someone defines the 'region' face to use underline -- we definitely cannot reset this attribute in that case, because then the region will appear non-contiguous, right? > I can produce the desired effect doing: > > ```Lisp > (defface my_new_face > '((t :weight normal :slant normal > :underline nil :overline nil :strike-through nil > :box nil :inverse-video nil :stipple nil))) > ``` > > ```C > DEFSYM (my_new_face, "my-new-face"); > > it->face_id = merge_faces (it->w, my-new-face, 0, it->face_id) > ``` > > But this seems very dirty. > > How can I produce the same effect in the right way? (I mean create a new > face_id based on it->face_id but with :underline nil :overline > nil... etc?) And only with C code. You need to call realize_face after copying the attributes of the default face and resetting some of the attributes to Qunspecified. But this is the mechanical part of the issue; I think the conceptual part is more problematic. First, we indeed behave inconsistently in GUI and TTY frames regarding faces that straddle the newline. On GUI frames, some attributes, such as colors and the box attribute, extend all the way to the window's edge; others, like underline, overline, and strike-through only affect the single glyph that stands for the newline (which the display engine adds so it will have a place to display the cursor). By contrast, on TTY frames, every attribute we support in text mode extends to the window's edge. Emacs behaved like that since v21. The question is: which of the 2 is the correct display, if there is a correct one? When trying to answer this question, please keep in mind two special use cases: the use case with the region, and the use case where the same attribute continues on the next screen line. Maybe there are other relevant use cases as well. I myself don't have a definitive answer. The TTY behavior makes more sense to me, but people frequently complain about it saying it's ugly, so I guess "makes sense" doesn't necessarily cut it.