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: Sat, 31 Oct 2020 09:00:55 +0100 Message-ID: <5c72b8d3-512c-7138-197a-cf2a70e8df32@gmx.at> 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="36285"; 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 Sat Oct 31 09:02:39 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 1kYlqR-0009KW-Fs for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 31 Oct 2020 09:02:39 +0100 Original-Received: from localhost ([::1]:54554 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kYlqQ-0007Ku-AV for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 31 Oct 2020 04:02:38 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59796) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kYlpq-0007KY-BX for bug-gnu-emacs@gnu.org; Sat, 31 Oct 2020 04:02:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:48936) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kYlpq-0004mD-1L for bug-gnu-emacs@gnu.org; Sat, 31 Oct 2020 04:02:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kYlpp-00034U-VK for bug-gnu-emacs@gnu.org; Sat, 31 Oct 2020 04:02:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 31 Oct 2020 08:02:01 +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.160413127111721 (code B ref 41852); Sat, 31 Oct 2020 08:02:01 +0000 Original-Received: (at 41852) by debbugs.gnu.org; 31 Oct 2020 08:01:11 +0000 Original-Received: from localhost ([127.0.0.1]:60479 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kYlp1-00032y-8T for submit@debbugs.gnu.org; Sat, 31 Oct 2020 04:01:11 -0400 Original-Received: from mout.gmx.net ([212.227.15.18]:36309) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kYlov-00032G-Mf for 41852@debbugs.gnu.org; Sat, 31 Oct 2020 04:01:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1604131258; bh=H3mb+UxTzqzlr5lzo2nI/MsUlk3FSa+FxaAOi5QoXvs=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=g//v1ohp8zBUewaEkJ2BVjoaJwGQD+M6eAeaLzsk89dL0Wx1Grz90rtstG63mrDwQ KtQpWN27lu4MM4oTkrE8WXTdvmZjBGxecG+y4Qj5n6ioddVVM8kdQthY+oIs/SktvW 9LUwEGas7//1ThSgU17EMlPl48qByKOP3n3gJ26A= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [192.168.1.102] ([212.95.7.235]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MxUs7-1kATZ500vB-00xqY9; Sat, 31 Oct 2020 09:00:58 +0100 In-Reply-To: Content-Language: en-US X-Provags-ID: V03:K1:CK39SMN83usGWQTnVBlbYkJ84GwtSBHthYllY+1DN4kCepL08fV 82P5z5kDvJanD5L/epFGSiHVhqEvn0dXGpiQSSRY2561XhzFDxxp2yOOv0kJsgV8P0dfgOh WchnqBeS0A916iNzeK7v0ypVm8o6DdV/qQ75GuBXPW+/oN0s1JxtMNxacaWM0v7MLe1R4o9 64H9u34WDl4ouxAFvAPiQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:afovqOuDUZE=:4REtfNZKtOgkL/DmBLeVEh oTBNU0JciiGT8kvCgVwKI0Rr1ec6+h3EeNRPKnUIQvWTLdqqLG4YnFGaJjszYwi1J/hb+UDqe 91j4IKoyBHy/HyZ7lqjdiAuuePC17qICd6+QaovtxgE2CT8YbAxxDMEz6639K6UU9jfHL7r4o D+15WeSSRa6R6NVxZ5WhW9Vzi5r6AUKJlVuuWk0VkrbCMb62M7YFIL/HrirQJ15K/gceW+HF9 GdurKTB+5Omgx3aXdzfxyQGuTJr7thXynQ8y169A7QZWRftOuC/0gOlxpDXQ7/3P7WlL0ju3N oBjqdsCrac+mR3oOBiy/Oex5bfSAsXFFx9taQ/D8VNTK03hJb0Ct1U/8mIHckWJ4//LW+oP9+ M9vWXPB/mRlygy1/L9yQH9rlcyxuk5BhpDL/PKW0VC/NzCXiX/XrDJrnPS5t80cJn8t38NbLF akaOfTXEjSV0YhA4tYhjrh73xrjM+YhBEssnCW4tacfCCjLS6JH+hr1cyuYirwP9nkyEUYGKh +ab2wZmPqOTFscGQalGXJx2Bq1CwiGqUXY9XsCNp8uFUwluAqRvpG9cpN6/Z92X83l74X/C1F IzzqQnRiyRGYF68yPB0kHdNzdqFr9+7qLEim537Ru+5LwgQN6CMsC7Q/STl7e5qfUR/3Gzymu t62w+m+zaeMYAblD8O5MR+I8sx092o9sI6gPj7PRufEprSEMz28JRjgDFbuXjBSjTUwehUBHp Ur7y8KENB5DehRa5GwEfZ8C+7ONCzi4K8h9tdpvTT7IrOmxfTEBo5wUI23PKdID6LKoGAL30 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:192247 Archived-At: >> I'd say "will also scale the text in the mode line when displaying that >> buffer". > > It doesn't scale the text in the mode line, though. Silly me. I obviously meant "header line" here. >> 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? > > Yes. But that seems (in my testing) to be the case for any face I > tested that doesn't have an absolute value for :height. So I'm not sure > that it needs to be specifically mentioned in NEWS. By no means. I just mentioned it to illustrate how elusive the text scaling mechanism is. >> 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. > > I'm not sure it is clear to everyone (it cleared some stuff up for me), > but I worry that this might be too detailed for NEWS. The interesting > bits is probably not exactly how it works, but rather what its visible > effects are. Fully agreed. That's why in NEWS I'd try to talk only about those visual effects and skip any details of the underlying implementation like faces, fonts and their scaling. >> We might have a problem when these two are set in separate steps. > > Yes, if the variable is set after scaling, it does not take effect until > another scaling operation is done. > > Adding this seems to fix that: > > (add-variable-watcher 'text-scale-remap-header-line-face > #'text-scale--refresh) > > (defun text-scale--refresh (symbol newval operation where) > (when (and (eq symbol 'text-scale-remap-header-line-face) > (eq operation 'set) > text-scale-mode) > (with-current-buffer where > (let ((text-scale-remap-header-line-face newval)) > (text-scale-mode 1))))) Something like that. Here I have a comment in my private version of face-remap.el that says ;; ... face-remapping first pushes an ;; entry to `face-remapping-alist' and then sets its cdr to the ;; modified value so our variable watcher won't catch the modified ;; value. Such destructive operations are a general problem with ;; watching non-scalar variables. but I can't tell whether it's directly related. martin