From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#41852: 27.0.50; text-scale commands don't scale header of tabulated-list-mode Date: Fri, 30 Oct 2020 18:37:35 +0100 Message-ID: References: <955fe4fe-a64d-b7c6-fe31-7efd810f97a5@ims.co.at> <83mu553e0x.fsf@gnu.org> <953c6df9-59b4-8b57-0be3-600d147fe9c7@ims.co.at> <83y2k2pabb.fsf@gnu.org> <83wnzmnioj.fsf@gnu.org> <83lfg1nfv1.fsf@gnu.org> <83d01dnegn.fsf@gnu.org> <2ae49edc-098f-9ace-595d-9e29bf3d2c8b@gmx.at> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8238"; mail-complaints-to="usenet@ciao.gmane.io" Cc: thomas.hisch@ims.co.at, 41852@debbugs.gnu.org To: Stefan Kangas , Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Oct 30 18:39:06 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1kYYMi-0001zZ-7n for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 30 Oct 2020 18:39:04 +0100 Original-Received: from localhost ([::1]:43940 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kYYMg-0002k5-TS for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 30 Oct 2020 13:39:03 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39508) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kYYLi-0002jf-OC for bug-gnu-emacs@gnu.org; Fri, 30 Oct 2020 13:38:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:48045) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kYYLi-0001N7-E4 for bug-gnu-emacs@gnu.org; Fri, 30 Oct 2020 13:38:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kYYLi-0002PX-9d for bug-gnu-emacs@gnu.org; Fri, 30 Oct 2020 13:38:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 30 Oct 2020 17:38:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 41852 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 41852-submit@debbugs.gnu.org id=B41852.16040794689247 (code B ref 41852); Fri, 30 Oct 2020 17:38:02 +0000 Original-Received: (at 41852) by debbugs.gnu.org; 30 Oct 2020 17:37:48 +0000 Original-Received: from localhost ([127.0.0.1]:59591 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kYYLU-0002P4-DH for submit@debbugs.gnu.org; Fri, 30 Oct 2020 13:37:48 -0400 Original-Received: from mout.gmx.net ([212.227.17.20]:60253) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kYYLS-0002Oo-4e for 41852@debbugs.gnu.org; Fri, 30 Oct 2020 13:37:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1604079457; bh=rqmZymlE/Qu2RaWpZrq7XrBGIOHRbofdVrqxPueDbzQ=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=LdBjjnsY+5f8lvjm0SyOOuyU0BcnhvDhflRfPyw4rtlgarQOH45S6MfeSJH7YAb5z /O3koeki7AM3sfhb4fh2lYRpDXDsguspykZsvV0LxakotQtMui6cpn4pNNMInwHFnL zCbHc4MrRsMfto9E2fyXA95tkQnw3BNUC8K6uiBM= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [192.168.1.102] ([212.95.5.74]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MNsw4-1kjUYj3Cwq-00OIF7; Fri, 30 Oct 2020 18:37:37 +0100 In-Reply-To: Content-Language: en-US X-Provags-ID: V03:K1:oIq9LljWYXUqFYV6kgWl/ELj+aDFubdrKHGrKI3X65MXpz4M+uB CxK6DImXQhnGWpHlq8VRqSMME9Zv/Y72l7wqngIbNb/BlfOXPYtdRznw1TPcdlIG0FL6DLR 5DPMNjXFrybrksyqftnP0NJuYaXw3oPv6EJPbYhYdN6BJ9sUa2nya015O6vvzLCkfY8EuzX 1u441b5isgmBch9y1Q4tQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:vuKo5rhkeXc=:Xg2m4JzpWmcgDosrnq+ayw hW0yPaXzCwPt0VlTWCh5Ep2uacaRBjnwgHeIukindWuphTPOtu3wC8+nRB5uvoHj7ZXI3w/7c k5P3nvvv7q60RMgSx7P4+sn1y9SffZO6R3mBkfNFuy9g7BW0L6TpTmJeoakFUdqIQIu9cv97w g8PcDq8HrLHfx10W6Mu+KiwS7K2x4lh2J9Aq8qy/CR5EphSUxjIIK+gJm8wKp91aFgLv/UXZB 67s1sL/eceo5TmHL9hSJA0vaz+5dNUj0fesiFVO1Wpj0JjAHMut6DXTaFbF5oG2c70vDyBt4L fsZ0WQQiOV51cOO6Yo8Gy4FzpfpkzS3oB5wyS16flHeSiQloiJQNqgW2yKocMu1tEtWw1ZW+9 u0ryMtXnz7IAZSqX5XhJTuLXuXJbM5aqU6YYkKP6ESb+uS/ADMv9u8GKHtwe/1uTANgxTaNkG Ndwfgy6/QqOHsmlKqwkkPZ6rcVRjasysNdqk0CfIibblLlSSm31CacjXXbOMIrsiWRjQPULuS WRZ6quvmLusLMg1GdckbwTJIazHQAb/7rRNrhD8DsDU+fcAJ/x9SYovNekluxHSfbh5Ukpw2K /b4ZPPE3X+kf3t5nGy/WLdvxe+A09WvAH/eB9mSgkDbJH5YsMQp/cEHUf0KV1GTiD6/8or1NO dhic6JplEClAqK8C5g44YNaclyMzEO9UGbcM9L+zN7VSxZiMVR9XHenpLV0oCmfTspaaipY0R SDrHHserXWXSXVBjUDiMWIZFXeesrxmKsl1u5Rbo7/tqvjyJSAPqu5U17Gm/lLzUOykpPwdG X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:192164 Archived-At: > Could you be more specific? It already says it's buffer local, but it > seems like you think it should say something more? IIUC one cannot "set" a face buffer-locally. One has to emulate that via face remapping. > Do you mean to be very explicit about it, like this? > > When the new buffer local variable 'text-scale-remap-header-line-face' > is non-nil, 'text-scale-adjust' will also change the font size of the > 'header-line' face in the current buffer. I'd say "will also scale the text in the mode line when displaying that buffer". > This will also affect any > face that inherits from it. But if I assign the header line face or some face inheriting from it to some buffer text (not that I recommend doing that), that text will be scaled regardless of the value of 'text-scale-remap-header-line-face'. Right? >> (2) that text in the header line or elsewhere in such a buffer not >> inheriting from (the remapped) header line face is unaffected, and > > I'm not sure I understand what you mean. If text-scale-mode is enabled, > typically through running e.g. `text-scale-increase', the `default' face > is scaled. Here too I would say something like "the buffer text is scaled". The default face itself is not scaled by face remapping. The remapping is applied by the display engine whenever the buffer is displayed after all faces have been merged. But maybe that is clear to everyone and you should simply ignore what I wrote. > The result, AFAICT, is that all faces in the buffer change > size (well, not the mode line). The faces do not change size. They just "appear" larger or smaller. And mode, header and tab line are not part of the buffer, so face remapping does not affect them. So far - I wouldn't mind if your change affected mode and tab line as well. > And that makes sense since all other > implicitly inherits from it, right? > > This works even for anonymous faces, e.g.: > > (progn > (fundamental-mode) > (insert (propertize "foo" 'face '(:height 1.5))) > (text-scale-increase)) > > What am I missing? Inserting "foo" makes it part of the buffer text and thus subject to text scaling ('text-scale-increase' needs an argument btw). >> (3) whether and how existing customizations of the header line face are >> taken into account. >> >> Wrt (3) I assume that 'tabulated-list-mode' can already get derailed >> when a user customizes header line face to use some large or small font >> size (a scenario where face remapping is not involved at all). > > I tried customizing the `Height' for the `header-line' face, and it > seems to work as expected: > > With no text-scale-mode it is as big as it is customized to be. When I > run `text-scale-increase', it scales up accordingly (relative to its > customized size). So I don't know what, if anything, should be added > here. Since it works as expected, perhaps there is nothing to add? OK. >> Note that maybe 'text-scale-mode-header-line' should be also watched by >> 'set-buffer-redisplay'. > > I tried adding `text-scale-remap-header-line-face' to the list of > variables that are fed to `add-variable-watcher' at the end of frame.el. > That doesn't work, unfortunately. > > I believe that since the remapping is done on a Lisp level, > `text-scale-mode' isn't called even with a variable watcher. Is there a > way to work around that? Or am I doing it wrong? I'm not sure whether it's needed at all, Eli knows better. I suppose it should work out of the box because setting the header line format already triggers 'set-buffer-redisplay' and the additional setting of 'text-scale-mode-header-line' will be covered by it. We might have a problem when these two are set in separate steps. martin