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: Sat, 10 Aug 2019 14:42:52 +0300 Message-ID: <83ef1t8cw3.fsf@gnu.org> References: <20190807155738.yviofsumjjhqueci@Ergus> <83imr9ar9f.fsf@gnu.org> <0975890b-37b4-428d-f6e5-5dcf894fb6be@gmx.at> <83ftmdapxm.fsf@gnu.org> <20190808083804.ta3evocyb4hirywj@Ergus> <835zn7bvvp.fsf@gnu.org> <20190808164319.bvsm265x76agq67v@Ergus> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="194047"; mail-complaints-to="usenet@blaine.gmane.org" Cc: rudalics@gmx.at, emacs-devel@gnu.org To: Ergus Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Aug 10 13:43:07 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 1hwPm7-000oHQ-F0 for ged-emacs-devel@m.gmane.org; Sat, 10 Aug 2019 13:43:07 +0200 Original-Received: from localhost ([::1]:35870 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hwPm6-0000SI-7b for ged-emacs-devel@m.gmane.org; Sat, 10 Aug 2019 07:43:06 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49484) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hwPm2-0000SC-9W for emacs-devel@gnu.org; Sat, 10 Aug 2019 07:43:03 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:52244) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hwPm1-0003SK-RU; Sat, 10 Aug 2019 07:43:01 -0400 Original-Received: from [176.228.60.248] (port=4897 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hwPm1-0005sF-5X; Sat, 10 Aug 2019 07:43:01 -0400 In-reply-to: <20190808164319.bvsm265x76agq67v@Ergus> (message from Ergus on Thu, 8 Aug 2019 18:43:19 +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:239306 Archived-At: > Date: Thu, 8 Aug 2019 18:43:19 +0200 > From: Ergus > Cc: martin rudalics , emacs-devel@gnu.org > > >Indeed, nothing is ever as simple in the display code, due to the > >sheer amount of different use cases. I think at least one other face > >attribute that's special in this regard is :box, in particular (but > >not only) because extend_face_to_end_of_line is called from the > >function which redisplays the mode line and the header line. > > > Yes I have seen :p. That's why I will vote for simplicity+efficiency > over more complex customization that 99% of the users won't > need/know/use. We cannot take the simplicity+efficiency escape if it will cause inconsistent behavior in valid use cases. > I only want a uniform behavior between gui and tui. Because bigger > changes I have understand that are close to impossible. Making the behavior of TTY and GUI frames consistent should be easy once we decide which one we want to keep, provided we also decide not to extend the background color on GUI (and TTY) frames. But if we decide to keep the TTY behavior, it will make GUI display slightly less efficient, especially in wide windows. > I vote for: > > Reproduce in TUI the gui behavior as is now by default but: > > 1) With a not-extend-by-default policy Including non-extension of background color? Because if you still want to extend the color, I don't see how to make TTY and GUI consistent, at least not easily. > 2.0) With some condition checks to extend the mentioned exceptions > (secondary, region, hl_line_mode etc) maybe this last can be set in a > customizable variable as there will be relatively few elements. > > xor > > 2.1) Add the "extensible" flag to the face. I think both of these possibilities aren't workable due to face merging. > 3) Add an extra face to extend (like in my previous code) that needs to > be merged with the last face in the line conditionally and can be used > in case the user wants extend but removing the underline and keeping > the background color (for example). This can only work if we assume users will want the same attribute be extended or not irrespective of the face. Such an assumption is not necessarily valid: users could want the hl-line face, for example, be always extended, regardless of its attributes, but would like at the same time not see other faces' :underline attribute extended. IOW, such a solution (and similar ones proposed here) look like kludgey workarounds, something that IMO is not really appropriate for a major feature such as faces. > I am specially concerned about this because org-mode behavior in > terminal affects many users. We could claim this to be a bug in Org. No? Why does Org insist on covering the newline with the face?