From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Aaron Jensen Newsgroups: gmane.emacs.bugs Subject: bug#30553: 26.0.91; underline appears beneath line-spacing rather than beneath text Date: Mon, 26 Feb 2018 08:01:03 -0800 Message-ID: References: <83r2pf78x5.fsf@gnu.org> <83fu5v6kdi.fsf@gnu.org> <83371u6xc2.fsf@gnu.org> <83y3jf21wh.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Trace: blaine.gmane.org 1519660816 15792 195.159.176.226 (26 Feb 2018 16:00:16 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 26 Feb 2018 16:00:16 +0000 (UTC) Cc: Alp Aker , 30553@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Feb 26 17:00:12 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eqLCF-0003aV-Pz for geb-bug-gnu-emacs@m.gmane.org; Mon, 26 Feb 2018 17:00:12 +0100 Original-Received: from localhost ([::1]:59895 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eqLEI-0001VU-AM for geb-bug-gnu-emacs@m.gmane.org; Mon, 26 Feb 2018 11:02:18 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51916) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eqLE5-0001Sp-Ij for bug-gnu-emacs@gnu.org; Mon, 26 Feb 2018 11:02:11 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eqLE2-0000Jg-Gk for bug-gnu-emacs@gnu.org; Mon, 26 Feb 2018 11:02:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:54019) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eqLE2-0000Jc-BO for bug-gnu-emacs@gnu.org; Mon, 26 Feb 2018 11:02:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1eqLE2-0004Dw-1N for bug-gnu-emacs@gnu.org; Mon, 26 Feb 2018 11:02:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Aaron Jensen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 26 Feb 2018 16:02:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 30553 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 30553-submit@debbugs.gnu.org id=B30553.151966087216174 (code B ref 30553); Mon, 26 Feb 2018 16:02:01 +0000 Original-Received: (at 30553) by debbugs.gnu.org; 26 Feb 2018 16:01:12 +0000 Original-Received: from localhost ([127.0.0.1]:33683 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eqLDD-0004Cn-Tb for submit@debbugs.gnu.org; Mon, 26 Feb 2018 11:01:12 -0500 Original-Received: from mail-qk0-f174.google.com ([209.85.220.174]:43933) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eqLDC-0004Ca-Fh for 30553@debbugs.gnu.org; Mon, 26 Feb 2018 11:01:10 -0500 Original-Received: by mail-qk0-f174.google.com with SMTP id j4so13794585qke.10 for <30553@debbugs.gnu.org>; Mon, 26 Feb 2018 08:01:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=u0jrUz30YlQLP1GMvTeBLWub1xFXvxYDMhoJAQb9Pzk=; b=Hpg/Yf/mFymtfmAWFwx/GWEQS9sRE5BiCB1+9Y2GXDdg+I+1onxySBACl5Mkkv+FgC UJ8tZGii568HjZ5EEQs/+i0RUf3EaDOmcpMIs01UTKFIAreBu2mQvNo60l4PEhCliqT2 GsbY6GkFsg4ofq3SXiX7EexTj1dN3vXPN5kDtoCQN2bhOJsTu+wHovyM6kHsYZJZfEwq B0PM6UJW669yFNQtwxZvm9RQTKM34BDDPampNpyJWsqX9yLn2Do0A7kVPtDsrV+L/Y/N XVzarwbJeo/FRalI3zh8C0FesC8ybCvX7rDPav+seHmTJoLojDXVwEs/VmwMEwCZ2XKZ KeOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=u0jrUz30YlQLP1GMvTeBLWub1xFXvxYDMhoJAQb9Pzk=; b=iPJmf1HK2CPVwuLvcFS8NsERYYuPVeaHfavMvPnD0lmgi2ehHaCfwHu0mCTooDO5tT HZraeiHYUJ4NJ4RkkkPvaHWACidFpXin5QQvwuwTe8bC5AS6S/7RkqinSOKJbtPnwgL0 T8CTtZXMHLHbLnD6AWMw3RoJSKoeVo6Xipv/E0Oyub0StB5Wz8C6fQIjhPi9HqMEr4tr 8qhclmeQMIF9E0H677VNnQC4Cy0MFEtnUggF50lYsp7HIDFHl6e7jCT46USbFQMprU77 OAs6javH7XSfYDqqa1PJhdNkEDAEJFEBWs8KmcuEFQHIMv99EG9601rnmhlafD/O3/8l lpYA== X-Gm-Message-State: APf1xPChvAVk0JXMjjtojH0jOoOFg465RZ1dROP1y8P6LxXmOY0kLD9S QbrtFxZ+1cp830YL1j/rKk2Tl1jFnoPoreUCkzQ= X-Google-Smtp-Source: AG47ELu1kRU0NjrcPTWGXc4ClnLZWPihqdfQnzkb3AOgKGxKoouBWhamubnrq2KtWvkjrMQyZgWk9z+jBDhgYBDJzoA= X-Received: by 10.55.214.10 with SMTP id t10mr16598535qki.341.1519660864825; Mon, 26 Feb 2018 08:01:04 -0800 (PST) Original-Received: by 10.237.54.65 with HTTP; Mon, 26 Feb 2018 08:01:03 -0800 (PST) In-Reply-To: <83y3jf21wh.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:143672 Archived-At: On Mon, Feb 26, 2018 at 7:42 AM, Eli Zaretskii wrote: > I'm not sure I see the point of adding yet another variable. Don't > you see the same problem with local values of that variable, like you > saw with the 2 existing ones? Yes, but the point is actually that this is a setting I would be ok with for my entire frame. Whereas before I was using different underline settings depending on whether or not it was code or prose. > In general, you cannot assume in display code that buffer-local > variables have their expected values, because redisplay needs to > redraw windows other than the selected one, and when it does so, the > window's buffer is not made the current one in the full sense of the > word. What you saw is the display engine using the value from the > last buffer that was current before a redisplay cycle. So you need to > explicitly access buffer-local values by calling buffer_local_value; > see the examples of that in xdisp.c. Ok, that makes sense. Would you like me to make that change for all of them given my description below? Is there some performance penalty to this? > If we want to allow users to make these variables buffer-local, the > best way is to modify the display code to use their buffer-local > values. That would be a cleaner solution, I think. > > But anyway, what is the use case where you need different values for > these variables in different buffers? These variables were introduced > to solve problems with semi-buggy fonts, and these problems are not > limited to a single buffer. Also, if you set these variables to > ignore the line-spacing, it will produce a reasonable display in a > buffer without any line-spacing at all, so I wonder why you needed to > make these local. Can you explain? I briefly described this above, but here are some more details. Today, globally, I'm using: (setq x-underline-at-descent-line t) This was the default in spacemacs and it's likely because of #30609 (underlines drawn over descenders make text hard to read) and different colored underlines are used heavily with flycheck. And, in org-mode: (setq-local line-spacing 1) (setq-local x-underline-at-descent-line nil) (setq-local x-use-underline-position-properties t) For reasons that led me to create this initial bug report: x-underline-at-descent-line looks terrible when line-spacing > 0. With this variable, you are right, I no longer need to use `setq-local`, I can just set this variable globally and it will look reasonable for code and prose. That said, I'm not sure exactly what you meant by: "if you set these variables to ignore the line-spacing", are you referring to the new variable I introduced or are you OK with me making a change to x-underline-at-descent-line to ignore line spacing?