From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Ergus Newsgroups: gmane.emacs.devel Subject: Re: Question about display engine Date: Wed, 7 Aug 2019 17:32:20 +0200 Message-ID: <20190807153220.ssijgjxnf6dszz45@Ergus> References: <20190807005411.qfzzpz5cjrajbwn2@Ergus> <83o911aukn.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="202931"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: NeoMutt/20180716 Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Aug 07 17:35:06 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 1hvNxy-000qfW-C2 for ged-emacs-devel@m.gmane.org; Wed, 07 Aug 2019 17:35:06 +0200 Original-Received: from localhost ([::1]:42698 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hvNxx-0000l5-Az for ged-emacs-devel@m.gmane.org; Wed, 07 Aug 2019 11:35:05 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55139) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hvNvY-0006wk-C9 for emacs-devel@gnu.org; Wed, 07 Aug 2019 11:32:39 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hvNvU-0005nh-Co for emacs-devel@gnu.org; Wed, 07 Aug 2019 11:32:34 -0400 Original-Received: from sonic305-20.consmr.mail.ir2.yahoo.com ([77.238.177.82]:40647) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hvNvS-0005lB-O8 for emacs-devel@gnu.org; Wed, 07 Aug 2019 11:32:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1565191946; bh=gS1vRCPr5TwJv8Jg/+VFyGoUfgJeD34xLssmoAA/MMo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From:Subject; b=XOYRGHuN87KcirsmcAvyB0Xy27+sE2w68csU7xEjzqp20BnpHyTVpDbyYqvPiKZ0MNRo0CisSm0CFWslxH1QR4astKT0EdzY1Vhqhv6MTVabPKzuc4oTo9OVscowMTwnfnf9pshfpYBHvGgZR56hc3V+NkkG0lyKRwJODL5CxG2V9KT+Ohfxy9NmUPVpu5wh7VfzdFCoD2DK8m1EQlEGMB64K68r1M6AgjyGTgIh6gg+245Hr6/FSWlwVKfkdFrUbzz68aNDJYe8J80wo7QJA63KCOh9f4sTO+VOdM32OKWlhGVbblWI6j9kM0j9t09zerYOfb5RuUZvxuDgs2pXMA== X-YMail-OSG: 1ds3wLYVM1kSqU3bZU67.nj0IUXJNs_2VncF1qYhNNUQxiZKxyC1UdC.W4eYTkG HQ.SgRudBke_g5T8dgROLWS8Ylswknu5FsZhj1rY6.d4ivbRzyZM8Jq5AYcBv051b3U7yixqcihW s_YquUyw8G0DzRxW7FJKUj6DFfTOehSTbPmDCzsEGUvqunkc9aW13w9Cvpw5.1nlcasjWmKmHKds 9RUH1nTk2Ib.DCxUtHTSbx6sVN.hZO7t6AL5zpz.LvgV.3yc0hw6McSrw_AY_Wd4OOk1dCQ85SaD 5.RJ7QBIn0nB88NcBiQg9lbpHBKnoIvkmEyz2LpwEdnzIYd8FHyDL.B8PfGhLUWRF6Y95HW1Ag12 LJNZGChTtf_ltUnnNXa1lj4wfqG16HqsY6f8Cqh5m5rxt6ABPIhNHFs1hQFEGrNUnAQAWgXTVSXq QZga1ThSpLaOfqYje83mtE43oWQR.6VHX45w.yJ2fNZ6l8WCSCes1EJvWBqA.xJHytAnLXNxnHjw zHRWthI7X1kamvkus6VkSJbe8VhmmHJtOzdc057mwzqNqtxNj7I0Yy_MpLDpItmgX9aY_XkhddmP T229UHT2pghS9Q_5aDIDLoY0Kt7JTBOQYFXkOTDRFXlr2VHrbO4SLz22KH73OFhKNTHw5Y44AK7f Fwkrsp.Y54AohcheFXtxiPnf9vp9TZNDmKHSJmKlHep_b8e_yTxSu.O43h6MJV3VsRx9DdKc6vNq 7TtToMPbN8uMAwQX4ixGBLHhU6_XXdjWA7U3zYqgMWJrjcDNl5YJS1sM7Tzb5BhGHIMNwPBrAjs4 geXoR.lmgIaECvIAnqDYiCAi1WWbmn3.ZEaO0RexdA Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.ir2.yahoo.com with HTTP; Wed, 7 Aug 2019 15:32:26 +0000 Original-Received: by smtp403.mail.ir2.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 8575d3d388e696507c4fa66f54f68402; Wed, 07 Aug 2019 15:32:22 +0000 (UTC) Content-Disposition: inline In-Reply-To: <83o911aukn.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 77.238.177.82 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:239227 Archived-At: On Wed, Aug 07, 2019 at 06:01:12PM +0300, Eli Zaretskii wrote: >> 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. > Hi: I am not sure about what will be the community opinion; so I'll wait for some comments (and the usual complains) before implementing anything. Maybe it makes some sense to consider the region as a corner case here. So a possible solution is just to add a condition to reset the underline (and other attributes) when the last glyph was not in the active region. The actual TUI behavior is annoying in some modes; so maybe the best is to reproduce the gui behavior as it is now in TUI too. But: After thinking on that a little bit more since yesterday; maybe it is possible to add another basic face for the rest of the line. That face will be merged with the previous face as in the example code, so if it specifies :underline then merging should work as specified; else, it will just use the :underline from the latest glyph. So the user could potentially customize the desired behavior. The arguments will come about what the defaults should be, but at least we don't limit that. Does it makes sense? Best, Ergus