From unknown Tue Aug 19 05:12:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#53636: 29.0.50; face-remapping broken on master Resent-From: Tassilo Horn Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 30 Jan 2022 13:55:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 53636 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 53636@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.164355089817635 (code B ref -1); Sun, 30 Jan 2022 13:55:02 +0000 Received: (at submit) by debbugs.gnu.org; 30 Jan 2022 13:54:58 +0000 Received: from localhost ([127.0.0.1]:35749 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nEAfR-0004aN-CY for submit@debbugs.gnu.org; Sun, 30 Jan 2022 08:54:58 -0500 Received: from lists.gnu.org ([209.51.188.17]:59534) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nEAfN-0004aB-2j for submit@debbugs.gnu.org; Sun, 30 Jan 2022 08:54:55 -0500 Received: from eggs.gnu.org ([209.51.188.92]:54720) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nEAfM-0001CB-R1 for bug-gnu-emacs@gnu.org; Sun, 30 Jan 2022 08:54:52 -0500 Received: from [2001:470:142:3::e] (port=47636 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nEAfM-0007Tc-HP for bug-gnu-emacs@gnu.org; Sun, 30 Jan 2022 08:54:52 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:Subject:To:From:in-reply-to: references; bh=YiggAijF8xc1aqWy3LOGHN28UbdTstGQisRgzYJN47g=; b=PrdXBv0Cst+B+9 vyUGPlfwAI2I05+4Q2UacNR3DfNWThHBAdicqQRhYbeQ2Evu9Lxu5sIT9IOEpgrqtWt37L9zrKcC3 kjWRMPyr1cXsXm8JxVzx9bEqYzckuVpJiA5TTmu4Uo5Gh39jsD6WSLoyVNEb26swyzw8QFgoELRJj gv72NsL8QiUloEmVrEhbUOh7SIcewxl4XA+kA1KChFwIUf+zjUjN1ygukPEm9L49HA2X8vjlDGWca c2lEZKYgNUfdui9a7M7cOj0GmEupBuPQfLWL7eNHCKnn+MpocJURDb7uoRSJSy61wubZu8/HAo+Jt KnWUWDQ08vGvcFkW7nug==; Received: from auth1-smtp.messagingengine.com ([66.111.4.227]:40939) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nEAfL-0001vV-I1 for bug-gnu-emacs@gnu.org; Sun, 30 Jan 2022 08:54:52 -0500 Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailauth.nyi.internal (Postfix) with ESMTP id 524E027C0054 for ; Sun, 30 Jan 2022 08:54:51 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Sun, 30 Jan 2022 08:54:51 -0500 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrfeelgdehkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepfgfhvffufffkgggtsehttdertddtre dtnecuhfhrohhmpefvrghsshhilhhoucfjohhrnhcuoehtshguhhesghhnuhdrohhrgheq necuggftrfgrthhtvghrnhepuddvueevjeefkeeuffeifffhtefhvdeiuddttdfgiedvvd fhvefflefgudejteevnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghi lhhfrhhomhepthhhohhrnhdomhgvshhmthhprghuthhhphgvrhhsohhnrghlihhthidqke eijeefkeejkeegqdeifeehvdelkedqthhsughhpeepghhnuhdrohhrghesfhgrshhtmhgr ihhlrdhfmh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Sun, 30 Jan 2022 08:54:50 -0500 (EST) User-agent: mu4e 1.7.6; emacs 29.0.50 From: Tassilo Horn Date: Sun, 30 Jan 2022 14:52:53 +0100 Message-ID: <87o83tib13.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) I'm expeciencing/debugging a problem with the doom-themes package but was able to come up with a simple recipe without dependencies. --8<---------------cut here---------------start------------->8--- (defun doom-themes-visual-bell-fn () "Blink the mode-line red briefly. Set `ring-bell-function' to this to use it." (let ((doom-themes--bell-cookie (face-remap-add-relative 'mode-line 'error))) (force-mode-line-update) (run-with-timer 0.15 nil (lambda (cookie buf) (with-current-buffer buf (face-remap-remove-relative cookie) (force-mode-line-update))) doom-themes--bell-cookie (current-buffer)))) (setq ring-bell-function #'doom-themes-visual-bell-fn visible-bell t) --8<---------------cut here---------------end--------------->8--- When I eval that with emacs -Q, version 27.2, C-g will blink the mode-line shortly (that is, all mode-line text is red and boldish for a fraction of a second) as I would expect. Same for the current emacs-28 branch. However, with the current master configured --with-modules and --with-pgtk, I don't see any flashes. Even more, although I don't get flashes, sometimes during normal emacs operation the mode-line will turn into the error face after an error has happened and not pop back to normal (unless I switch buffers back and forth) as if the timer function would not have run. I've also tried with master and --without-pgtk. There it seems to be broken, too, i.e., after evaling the code above, C-g or errors won't flash the mode-line (but I can't say anything about the "suddenly the error face sticks" issue). In GNU Emacs 29.0.50 (build 41, x86_64-pc-linux-gnu, GTK+ Version 3.24.31, cairo version 1.17.4) of 2022-01-30 built on thinkpad-t440p Repository revision: 988d3d79bac0343dd2b1b89d1b15470edbb5e6ac Repository branch: master System Description: Arch Linux Configured using: 'configure --with-modules --with-pgtk' Configured features: ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG JSON LCMS2 LIBOTF LIBSYSTEMD LIBXML2 MODULES NOTIFY INOTIFY PDUMPER PGTK PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS WEBP XIM GTK3 ZLIB Important settings: value of $LC_MONETARY: de_DE.utf8 value of $LC_NUMERIC: de_DE.utf8 value of $LC_TIME: de_DE.utf8 value of $LANG: en_US.UTF-8 locale-coding-system: utf-8-unix Major mode: ELisp/d Minor modes in effect: symbol-overlay-mode: t display-fill-column-indicator-mode: t editorconfig-mode: t debbugs-browse-mode: t hl-todo-mode: t global-aggressive-indent-mode: t aggressive-indent-mode: t pdf-occur-global-minor-mode: t diredfl-global-mode: t which-key-mode: t highlight-parentheses-mode: t corfu-global-mode: t corfu-mode: t yas-global-mode: t yas-minor-mode: t outline-minor-mode: t global-git-commit-mode: t magit-auto-revert-mode: t bug-reference-prog-mode: t vertico-mode: t marginalia-mode: t minibuffer-depth-indicate-mode: t electric-pair-mode: t recentf-mode: t pixel-scroll-precision-mode: t pixel-scroll-mode: t override-global-mode: t save-place-mode: t savehist-mode: t shell-dirtrack-mode: t puni-global-mode: t puni-mode: t tooltip-mode: t global-eldoc-mode: t eldoc-mode: t show-paren-mode: t electric-indent-mode: t mouse-wheel-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t column-number-mode: t line-number-mode: t transient-mark-mode: t Load-path shadows: ~/Repos/el/mu/build/mu4e/mu4e hides ~/Repos/el/mu/mu4e/mu4e ~/Repos/el/mu/build/mu4e/mu4e-main hides ~/Repos/el/mu/mu4e/mu4e-main ~/Repos/el/mu/build/mu4e/mu4e-view hides ~/Repos/el/mu/mu4e/mu4e-view ~/Repos/el/mu/build/mu4e/mu4e-org hides ~/Repos/el/mu/mu4e/mu4e-org ~/Repos/el/mu/build/mu4e/mu4e-lists hides ~/Repos/el/mu/mu4e/mu4e-lists ~/Repos/el/mu/build/mu4e/mu4e-actions hides ~/Repos/el/mu/mu4e/mu4e-actions ~/Repos/el/mu/build/mu4e/mu4e-helpers hides ~/Repos/el/mu/mu4e/mu4e-helpers ~/Repos/el/mu/build/mu4e/mu4e-search hides ~/Repos/el/mu/mu4e/mu4e-search ~/Repos/el/mu/build/mu4e/mu4e-server hides ~/Repos/el/mu/mu4e/mu4e-server ~/Repos/el/mu/build/mu4e/mu4e-update hides ~/Repos/el/mu/mu4e/mu4e-update ~/Repos/el/mu/build/mu4e/mu4e-context hides ~/Repos/el/mu/mu4e/mu4e-context ~/Repos/el/mu/build/mu4e/mu4e-draft hides ~/Repos/el/mu/mu4e/mu4e-draft ~/Repos/el/mu/build/mu4e/mu4e-bookmarks hides ~/Repos/el/mu/mu4e/mu4e-bookmarks ~/Repos/el/mu/build/mu4e/mu4e-message hides ~/Repos/el/mu/mu4e/mu4e-message ~/Repos/el/mu/build/mu4e/mu4e-compose hides ~/Repos/el/mu/mu4e/mu4e-compose ~/Repos/el/mu/build/mu4e/mu4e-headers hides ~/Repos/el/mu/mu4e/mu4e-headers ~/Repos/el/mu/build/mu4e/mu4e-mark hides ~/Repos/el/mu/mu4e/mu4e-mark ~/Repos/el/mu/build/mu4e/mu4e-contacts hides ~/Repos/el/mu/mu4e/mu4e-contacts ~/Repos/el/mu/build/mu4e/mu4e-icalendar hides ~/Repos/el/mu/mu4e/mu4e-icalendar ~/Repos/el/mu/build/mu4e/mu4e-folders hides ~/Repos/el/mu/mu4e/mu4e-folders ~/Repos/el/mu/build/mu4e/mu4e-speedbar hides ~/Repos/el/mu/mu4e/mu4e-speedbar ~/Repos/el/mu/build/mu4e/mu4e-contrib hides ~/Repos/el/mu/mu4e/mu4e-contrib ~/Repos/el/mu/build/mu4e/mu4e-vars hides ~/Repos/el/mu/mu4e/mu4e-vars /home/horn/.emacs.d/elpa/transient-20220129.1515/transient hides /home/horn/Repos/el/emacs/lisp/transient Features: (shadow emacsbug repeat network-stream url-cache go-translate gts-engine-deepl gts-engine-google-rpc gts-engine-google gts-engine-bing gts-implements gts-faces gts-core debug edebug backtrace cl-print symbol-overlay shortdoc xref conf-mode help-fns radix-tree cursor-sensor executable dabbrev cape sort gnus-cite mm-archive mail-extr textsec uni-scripts idna-mapping ucs-normalize uni-confusable textsec-check expand-region yaml-mode-expansions text-mode-expansions the-org-mode-expansions web-mode-expansions er-basic-expansions expand-region-core expand-region-custom misearch multi-isearch adaptive-wrap org-element ol-eww eww xdg mm-url ol-rmail ol-mhe ol-irc ol-info ol-gnus nnselect gnus-search eieio-opt speedbar ezimage dframe ol-docview doc-view ol-bibtex ol-bbdb ol-w3m ol-doi org-link-doi editorconfig-core editorconfig-core-handle editorconfig-fnmatch project consult-vertico consult-icomplete consult puni pulse dired-aux display-fill-column-indicator auto-package-update finder-inf generic yaml-mode fish-mode cargo cargo-process rust-utils rust-mode rust-rustfmt rust-playpen rust-compile rust-cargo web-mode disp-table preview-latex auto-loads tex-site editorconfig elfeed-show elfeed-search vc-mtn vc-hg vc-bzr vc-src vc-sccs vc-svn vc-cvs vc-rcs debbugs-browse elfeed-csv elfeed elfeed-curl elfeed-log elfeed-db elfeed-lib avl-tree generator url-queue xml-query socks elpher hl-todo aggressive-indent rainbow-mode pdf-occur tablist tablist-filter semantic/wisent/comp semantic/wisent semantic/wisent/wisent semantic/util-modes semantic/util semantic semantic/tag semantic/lex semantic/fw mode-local cedet pdf-isearch pdf-misc pdf-tools pdf-view magit-bookmark bookmark jka-compr pdf-cache pdf-info tq pdf-util pdf-macs image-mode exif vc-git vc-dir ewoc epa-file rdictcc diredfl dired-x mu4e-icalendar gnus-icalendar org-capture org-refile icalendar diary-lib diary-loaddefs mu4e mu4e-org mu4e-view org ob ob-tangle ob-ref ob-lob ob-table ob-exp org-macro org-footnote org-src ob-comint org-pcomplete org-list org-faces org-entities org-version ob-emacs-lisp ob-core ob-eval org-table oc-basic bibtex ol org-keys oc org-compat org-macs org-loaddefs find-func cal-menu calendar cal-loaddefs mu4e-main mu4e-headers mu4e-lists mu4e-compose mu4e-draft mu4e-actions smtpmail sendmail mu4e-search mu4e-bookmarks mu4e-mark mu4e-message flow-fill mule-util hl-line mu4e-contacts mu4e-update mu4e-folders mu4e-server mu4e-context mu4e-vars mu4e-helpers ido mu4e-meta ecomplete auto-dictionary flyspell ispell tramp-smb which-key highlight-parentheses restclient kind-icon svg-lib corfu yasnippet forge-list forge-commands forge-semi forge-bitbucket buck forge-gogs gogs forge-gitea gtea forge-gitlab glab forge-github ghub-graphql treepy gsexp ghub let-alist gnutls forge-notify forge-revnote forge-pullreq forge-issue forge-topic yaml forge-post markdown-mode color thingatpt noutline outline forge-repo forge forge-core forge-db closql emacsql-sqlite emacsql emacsql-compiler magit-submodule magit-obsolete magit-blame magit-stash magit-reflog magit-bisect magit-push magit-pull magit-fetch magit-clone magit-remote magit-commit magit-sequence magit-notes magit-worktree magit-tag magit-merge magit-branch magit-reset magit-files magit-refs magit-status magit magit-repos magit-apply magit-wip magit-log which-func imenu magit-diff smerge-mode diff diff-mode git-commit log-edit pcvs-util add-log magit-core magit-autorevert autorevert filenotify magit-margin magit-transient magit-process with-editor server magit-mode magit-git magit-section magit-utils crm dash visual-filename-abbrev rg vc vc-dispatcher rg-info-hack advice rg-menu transient rg-ibuffer rg-result wgrep-rg wgrep rg-history rg-header ibuf-ext ibuffer ibuffer-loaddefs grep compile cus-edit pp cus-load debbugs soap-client url-http url-auth url-gw nsm warnings rng-xsd rng-dt rng-util xsd-regexp bug-reference vertico edmacro kmacro marginalia icomplete mb-depth use-package-diminish ace-window avy alert log4e notifications gntp elec-pair rx recentf tree-widget pixel-scroll use-package-bind-key bind-key saveplace savehist smiley gnus-art mm-uu mml2015 mm-view mml-smime smime dig gnus-sum shr pixel-fill kinsoku svg dom gnus-group gnus-undo gnus-start gnus-dbus dbus xml gnus-cloud nnimap nnmail mail-source utf7 netrc nnoo gnus-spec gnus-int gnus-range message yank-media rmc puny dired dired-loaddefs rfc822 mml mml-sec epa derived epg rfc6068 epg-config mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045 ietf-drums mailabbrev gmm-utils mailheader gnus-win gnus wid-edit nnheader gnus-util text-property-search mm-util mail-prsvr mail-utils range doom-themes-ext-org doom-themes-ext-visual-bell face-remap doom-Iosvkem-theme doom-themes doom-themes-base diminish cl-extra help-mode use-package-ensure use-package-core tramp tramp-loaddefs trampver tramp-integration files-x tramp-compat shell pcomplete comint ansi-color ring parse-time iso8601 time-date ls-lisp format-spec easy-mmode info package browse-url url url-proxy url-privacy url-expand url-methods url-history url-cookie url-domsuf url-util mailcap url-handlers url-parse auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs password-cache json map url-vars seq gv subr-x byte-opt bytecomp byte-compile cconv cl-loaddefs cl-lib iso-transl tooltip eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel term/pgtk-win pgtk-win term/common-win tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese composite emoji-zwj charscript charprop case-table epa-hook jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice button loaddefs faces cus-face macroexp files window text-properties overlay sha1 md5 base64 format env code-pages mule custom widget keymap hashtable-print-readable backquote threads dbusbind inotify dynamic-setting system-font-setting font-render-setting cairo move-toolbar gtk x-toolkit pgtk lcms2 multi-tty make-network-process emacs) Memory information: ((conses 16 852054 127409) (symbols 48 53826 5) (strings 32 254312 8041) (string-bytes 1 7102601) (vectors 16 130308) (vector-slots 8 2357843 222007) (floats 8 908 1032) (intervals 56 8258 801) (buffers 992 41)) From unknown Tue Aug 19 05:12:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#53636: 29.0.50; face-remapping broken on master Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 30 Jan 2022 17:42:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 53636 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Tassilo Horn Cc: 53636@debbugs.gnu.org Received: via spool by 53636-submit@debbugs.gnu.org id=B53636.16435645113433 (code B ref 53636); Sun, 30 Jan 2022 17:42:01 +0000 Received: (at 53636) by debbugs.gnu.org; 30 Jan 2022 17:41:51 +0000 Received: from localhost ([127.0.0.1]:37559 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nEED1-0000tJ-Gy for submit@debbugs.gnu.org; Sun, 30 Jan 2022 12:41:51 -0500 Received: from quimby.gnus.org ([95.216.78.240]:36996) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nEECw-0000sy-Eh for 53636@debbugs.gnu.org; Sun, 30 Jan 2022 12:41:50 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=ClUuhJTSFaoCtFMt/aNfHdkqcN4Q1lDOeH+zWYdj/rQ=; b=hqeel5A6Qxto3WtPiNpoBzE9Z+ 0wSruMRY+FC1sDk4lOdf9M+l7uWeMCD82l5xWnAYkXx9jjlLSj1N5mwUQ8zHGK+SSJ6JhyYJTuHyZ T39qzgBpicChZ71cyeCplHUQFwLB87JG4pt7Fcd0pzqUnouoC21PGsy7szyWCPRI90YE=; Received: from [84.212.220.105] (helo=giant) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nEECn-0000fy-90; Sun, 30 Jan 2022 18:41:39 +0100 From: Lars Ingebrigtsen References: <87o83tib13.fsf@gnu.org> X-Now-Playing: Ida's _Shhh..._: "Shhh..." Date: Sun, 30 Jan 2022 18:41:36 +0100 In-Reply-To: <87o83tib13.fsf@gnu.org> (Tassilo Horn's message of "Sun, 30 Jan 2022 14:52:53 +0100") Message-ID: <871r0p9l4f.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Tassilo Horn writes: > I've also tried with master and --without-pgtk. There it seems to be > broken, too, i.e., after evaling the code above, C-g or errors won't > flash the mode-line (but I can't say anything about the [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Tassilo Horn writes: > I've also tried with master and --without-pgtk. There it seems to be > broken, too, i.e., after evaling the code above, C-g or errors won't > flash the mode-line (but I can't say anything about the "suddenly the > error face sticks" issue). I can confirm that I'm also seeing the bug on master, but not on emacs-28 (with just ./configure on Debian/bookworm). -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Sun Jan 30 12:41:56 2022 Received: (at control) by debbugs.gnu.org; 30 Jan 2022 17:41:56 +0000 Received: from localhost ([127.0.0.1]:37561 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nEED5-0000tZ-OU for submit@debbugs.gnu.org; Sun, 30 Jan 2022 12:41:55 -0500 Received: from quimby.gnus.org ([95.216.78.240]:37010) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nEED0-0000t3-MZ for control@debbugs.gnu.org; Sun, 30 Jan 2022 12:41:51 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Subject:From:To:Message-Id:Date:Sender:Reply-To:Cc: MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=eUVvLIse4x2T5iBv14VgUPUo1ONatff5CTw5hGwvVuQ=; b=Wo5q3dudz+waZhejUXQ9BOE80F aXfASLV26wrFSI8WNo8Xey8ApyzW3ms75f/bkguG+3aFRaWDlAwevKqcqKrGLy2wB0HrVzhrYml1t rdqiioRGmGDPeLEmvzJHXFAGCOllTPOZHGeLWRX0rOAzd58kgPnSAsakyQPm6i+42DvY=; Received: from [84.212.220.105] (helo=giant) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nEECs-0000g8-O1 for control@debbugs.gnu.org; Sun, 30 Jan 2022 18:41:44 +0100 Date: Sun, 30 Jan 2022 18:41:42 +0100 Message-Id: <87zgnd86jt.fsf@gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #53636 X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: tags 53636 + confirmed quit Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) tags 53636 + confirmed quit From unknown Tue Aug 19 05:12:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#53636: 29.0.50; face-remapping broken on master Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 30 Jan 2022 18:29:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 53636 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: Lars Ingebrigtsen Cc: 53636@debbugs.gnu.org, tsdh@gnu.org Received: via spool by 53636-submit@debbugs.gnu.org id=B53636.164356728816812 (code B ref 53636); Sun, 30 Jan 2022 18:29:02 +0000 Received: (at 53636) by debbugs.gnu.org; 30 Jan 2022 18:28:08 +0000 Received: from localhost ([127.0.0.1]:37625 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nEEvo-0004N6-9o for submit@debbugs.gnu.org; Sun, 30 Jan 2022 13:28:08 -0500 Received: from eggs.gnu.org ([209.51.188.92]:55300) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nEEvn-0004Me-62 for 53636@debbugs.gnu.org; Sun, 30 Jan 2022 13:28:07 -0500 Received: from [2001:470:142:3::e] (port=52116 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nEEvh-0001sG-VB; Sun, 30 Jan 2022 13:28:01 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=zpcuaB0YggCzZJnsjstJjBVwKWRdJopMRkMbcKJ7dRw=; b=Q9zEmtk9OUwo hzvCKsCQkIpzbNMAEIRqMjGGxXTrHsUXuUN6TisVok70JliMXafZX9wVDzjC/XElBCRNOxChJ3Ngh O2NmSsMsTmzztEXI+7pjneOEq6arOP/Zks7Z1iG3LcX34BoALOGwR+YoISr6dD0TfpNT9vGEwvNto f9SDUY8UdQtvRIJ/dYvtbOs/gCj1u0Xh70bm2v8c/NzQDbW4Y5mul0MDTe//7DYIMsMiuiR4nFlx6 UkoObRj8xgO/Ku/Q7m8HaKB3vTRlepcRScMzSunbf5udLTEHzXXlijEPs/+saNvDPlwx+J9NYRZsD XC2nN1/oBJBae42IZOoxog==; Received: from [87.69.77.57] (port=3486 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nEEvX-0003dq-TX; Sun, 30 Jan 2022 13:28:01 -0500 Date: Sun, 30 Jan 2022 20:27:47 +0200 Message-Id: <83ee4p9izg.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <871r0p9l4f.fsf@gnus.org> (message from Lars Ingebrigtsen on Sun, 30 Jan 2022 18:41:36 +0100) References: <87o83tib13.fsf@gnu.org> <871r0p9l4f.fsf@gnus.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen > Date: Sun, 30 Jan 2022 18:41:36 +0100 > Cc: 53636@debbugs.gnu.org > > Tassilo Horn writes: > > > I've also tried with master and --without-pgtk. There it seems to be > > broken, too, i.e., after evaling the code above, C-g or errors won't > > flash the mode-line (but I can't say anything about the "suddenly the > > error face sticks" issue). > > I can confirm that I'm also seeing the bug on master, but not on > emacs-28 (with just ./configure on Debian/bookworm). If the problem is with face remapping, can we please have a reproducer that is simpler to debug? Like one that doesn't need any timers and flashing text? TIA From unknown Tue Aug 19 05:12:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#53636: 29.0.50; face-remapping broken on master Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 30 Jan 2022 18:33:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 53636 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: Eli Zaretskii Cc: 53636@debbugs.gnu.org, tsdh@gnu.org Received: via spool by 53636-submit@debbugs.gnu.org id=B53636.164356752717299 (code B ref 53636); Sun, 30 Jan 2022 18:33:02 +0000 Received: (at 53636) by debbugs.gnu.org; 30 Jan 2022 18:32:07 +0000 Received: from localhost ([127.0.0.1]:37638 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nEEzf-0004Ur-83 for submit@debbugs.gnu.org; Sun, 30 Jan 2022 13:32:07 -0500 Received: from quimby.gnus.org ([95.216.78.240]:37358) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nEEzc-0004U2-De for 53636@debbugs.gnu.org; Sun, 30 Jan 2022 13:32:05 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=eF+biTz7Q6IiJcw3T0zfs9f2HbTpjE5Cesk+Q2ketKM=; b=iUfLvLUtnIpDD4WieeawFpemZR IVg4ml8Ym8mWOc325ZXbXriz+h7XDtVQrKwDWcQNnzqP9hXkKmlj4h0Xq5WVshsTeNq4UIUY3nSi2 q/kGhEHq314uANv2XQQ8LkEglVJGMH0p2PZtS6Fu0tnpAN9AhJzk65Uyfm8l5Us0ue6k=; Received: from [84.212.220.105] (helo=giant) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nEEzT-00013i-Da; Sun, 30 Jan 2022 19:31:57 +0100 From: Lars Ingebrigtsen References: <87o83tib13.fsf@gnu.org> <871r0p9l4f.fsf@gnus.org> <83ee4p9izg.fsf@gnu.org> X-Now-Playing: Ida's _Shhh..._: "Shrug (Dub)" Date: Sun, 30 Jan 2022 19:31:54 +0100 In-Reply-To: <83ee4p9izg.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 30 Jan 2022 20:27:47 +0200") Message-ID: <87mtjd8485.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii writes: > If the problem is with face remapping, can we please have a reproducer > that is simpler to debug? Like one that doesn't need any timers and > flashing text? I assumed that all that async stuff was part of the reproducer, but indeed it's not. Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: > If the problem is with face remapping, can we please have a reproducer > that is simpler to debug? Like one that doesn't need any timers and > flashing text? I assumed that all that async stuff was part of the reproducer, but indeed it's not. Just evaling this is sufficient: (face-remap-add-relative 'mode-line 'error) And this is because mode-line is (in Emacs 29) the parent of two faces (but not used directly on the mode line), so you apparently have to do this instead: (face-remap-add-relative 'mode-line-active 'error) I'm not sure whether that's a bug or not? (That remapping a parent face has no effect.) -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From unknown Tue Aug 19 05:12:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#53636: 29.0.50; face-remapping broken on master Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 30 Jan 2022 19:20:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 53636 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: Lars Ingebrigtsen Cc: 53636@debbugs.gnu.org, tsdh@gnu.org Received: via spool by 53636-submit@debbugs.gnu.org id=B53636.164357037122201 (code B ref 53636); Sun, 30 Jan 2022 19:20:02 +0000 Received: (at 53636) by debbugs.gnu.org; 30 Jan 2022 19:19:31 +0000 Received: from localhost ([127.0.0.1]:37681 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nEFjX-0005m1-Aq for submit@debbugs.gnu.org; Sun, 30 Jan 2022 14:19:31 -0500 Received: from eggs.gnu.org ([209.51.188.92]:33670) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nEFjW-0005lp-1O for 53636@debbugs.gnu.org; Sun, 30 Jan 2022 14:19:30 -0500 Received: from [2001:470:142:3::e] (port=53014 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nEFjQ-0008Lx-Ng; Sun, 30 Jan 2022 14:19:24 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=7VpADtca+QduhBsXbh5jN3xbPlLQET+b3RIogMtyn0k=; b=htU9QO9sCuNr WPix+MZXm9tmmiKqO+X8cz+GLHu0u3l0ACVyIMJWADUbWXc6smEYVpwqrwneBwJBWQE/hLww5S8aQ jMy4PikTL3iGBHq4WnsyLmAzTsV7gCmXgptk22J/oBmXN0gWSKKo4ps/FXqRran1Z9BtUyG6mT5Y3 V6KplqQ4vtJcthVtq8gjbtKJ2Pb6tUH+1wALwpAPbd856DrJFodpdo3Ab1Wys3qGOaeXzWwygK/Bf df4JXInsASiNlOoOZQGTBHsqfGWzSfzRnLW8fU0vus3ASilmtI2t20faGt5Ut2ExV1vyF2L3ljyXT wdsY4C3c2Jx17hxHKViWPQ==; Received: from [87.69.77.57] (port=2686 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nEFjP-0005r7-RS; Sun, 30 Jan 2022 14:19:24 -0500 Date: Sun, 30 Jan 2022 21:19:17 +0200 Message-Id: <83a6fd9glm.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87mtjd8485.fsf@gnus.org> (message from Lars Ingebrigtsen on Sun, 30 Jan 2022 19:31:54 +0100) References: <87o83tib13.fsf@gnu.org> <871r0p9l4f.fsf@gnus.org> <83ee4p9izg.fsf@gnu.org> <87mtjd8485.fsf@gnus.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen > Cc: 53636@debbugs.gnu.org, tsdh@gnu.org > Date: Sun, 30 Jan 2022 19:31:54 +0100 > > Eli Zaretskii writes: > > > If the problem is with face remapping, can we please have a reproducer > > that is simpler to debug? Like one that doesn't need any timers and > > flashing text? > > I assumed that all that async stuff was part of the reproducer, but > indeed it's not. > > Just evaling this is sufficient: > > (face-remap-add-relative 'mode-line 'error) > > And this is because mode-line is (in Emacs 29) the parent of two faces > (but not used directly on the mode line), so you apparently have to do > this instead: > > (face-remap-add-relative 'mode-line-active 'error) > > I'm not sure whether that's a bug or not? (That remapping a parent face > has no effect.) But it does have effect. Try "C-x 5 b *scratch* RET" after evaluating the first face-remap-add-relative, and you will see that it does have effect. So it's something more subtle... And yes, I think the extra indirection we now have on master exposed a problem we never saw before. From unknown Tue Aug 19 05:12:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#53636: 29.0.50; face-remapping broken on master Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 30 Jan 2022 20:26:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 53636 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: larsi@gnus.org Cc: 53636@debbugs.gnu.org, tsdh@gnu.org Received: via spool by 53636-submit@debbugs.gnu.org id=B53636.16435743575219 (code B ref 53636); Sun, 30 Jan 2022 20:26:02 +0000 Received: (at 53636) by debbugs.gnu.org; 30 Jan 2022 20:25:57 +0000 Received: from localhost ([127.0.0.1]:37753 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nEGlp-0001M7-6v for submit@debbugs.gnu.org; Sun, 30 Jan 2022 15:25:57 -0500 Received: from eggs.gnu.org ([209.51.188.92]:43116) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nEGll-0001Lo-Vo for 53636@debbugs.gnu.org; Sun, 30 Jan 2022 15:25:56 -0500 Received: from [2001:470:142:3::e] (port=53952 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nEGlg-0008K3-LY; Sun, 30 Jan 2022 15:25:48 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=Xv5bUkHi/0mhFSfP3grx/GynkofryhQ2p19sIORiCoE=; b=q+WxuQyk+iyF WKdLblYWA7F/oTrWmnGLw9MCYYPS8JXFSMDAjVI4eJH5SzrXyv3bb7Cr5vbd5gCnmZThXoyENumIb dQJ78PuTcuXDbdSHo0cpUKV6ub4MwgsrCgf4nbuzs8uOWYPrxRw047N+lSoy7iJSej2oUXz+w3Fc0 UobzXdku22vQVXgr8C8Z8wIvBv0RCmucL7w6ct/mf1qfv//5QWigFus/LVnCVWMaHCvqhcJnRyF+T jCn7kSl54r/NAsWKjpFpvWy4KXcFufYOCVISsN36VJsUoG2WtY0AyfxbPQZNxgpbPD8zM0SimAQX4 nw/S+nZhN8ANrW5tnsYHPQ==; Received: from [87.69.77.57] (port=2709 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nEGl2-0002ns-0d; Sun, 30 Jan 2022 15:25:23 -0500 Date: Sun, 30 Jan 2022 22:25:02 +0200 Message-Id: <835yq19dk1.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <83a6fd9glm.fsf@gnu.org> (message from Eli Zaretskii on Sun, 30 Jan 2022 21:19:17 +0200) References: <87o83tib13.fsf@gnu.org> <871r0p9l4f.fsf@gnus.org> <83ee4p9izg.fsf@gnu.org> <87mtjd8485.fsf@gnus.org> <83a6fd9glm.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Sun, 30 Jan 2022 21:19:17 +0200 > From: Eli Zaretskii > Cc: 53636@debbugs.gnu.org, tsdh@gnu.org > > > I'm not sure whether that's a bug or not? (That remapping a parent face > > has no effect.) > > But it does have effect. Try "C-x 5 b *scratch* RET" after evaluating > the first face-remap-add-relative, and you will see that it does have > effect. So it's something more subtle... > > And yes, I think the extra indirection we now have on master exposed a > problem we never saw before. Actually, I think this is a new problem on master, introduced by making the mode-line face be a parent of mode-line-active and mode-line-inactive faces. When that was done, lookup_basic_face was changed to use mode-line-active instead of mode-line, so now the mode-line face is not recomputed when face-remapping-alist is changed. Instead, we recompute mode-line-active and mode-line-inactive, but those are not in face-remapping-alist in this scenario, so they don't change on the existing frame. Do we still need the mode-line as a parent of these two faces, or can we go back to what we had before the variable-pitch mode-line changes? From unknown Tue Aug 19 05:12:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#53636: 29.0.50; face-remapping broken on master Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 30 Jan 2022 20:30:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 53636 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: Eli Zaretskii Cc: 53636@debbugs.gnu.org, tsdh@gnu.org Received: via spool by 53636-submit@debbugs.gnu.org id=B53636.16435745475523 (code B ref 53636); Sun, 30 Jan 2022 20:30:02 +0000 Received: (at 53636) by debbugs.gnu.org; 30 Jan 2022 20:29:07 +0000 Received: from localhost ([127.0.0.1]:37757 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nEGos-0001Qy-Np for submit@debbugs.gnu.org; Sun, 30 Jan 2022 15:29:07 -0500 Received: from quimby.gnus.org ([95.216.78.240]:38438) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nEGoq-0001QT-4f for 53636@debbugs.gnu.org; Sun, 30 Jan 2022 15:29:05 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=th3G4M3Km9tzbzhwItkMcZVIqQ0sw/n98X6/tROA3AE=; b=RtgRXjUZ30z1FFnhqFk4Qgf+jf rQNCHwhjtFVsCj15e9SMxBMydHIHKg3nj3o7HbSiUFvRoJYVNlF7sWigq7VmVpDMhFWtqBt21J7vT i703wcOJQXq4XHi/FObJme/zkX0Y1+4MOQKvtROVih9TmhylLwW4QUuSkd11w+mysh/M=; Received: from [84.212.220.105] (helo=giant) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nEGoh-0001th-3k; Sun, 30 Jan 2022 21:28:57 +0100 From: Lars Ingebrigtsen References: <87o83tib13.fsf@gnu.org> <871r0p9l4f.fsf@gnus.org> <83ee4p9izg.fsf@gnu.org> <87mtjd8485.fsf@gnus.org> <83a6fd9glm.fsf@gnu.org> <835yq19dk1.fsf@gnu.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAD1BMVEVOdZg8aJXZyLRn YWr///+0ydZhAAAAAWJLR0QEj2jZUQAAAAd0SU1FB+YBHhQbAURxq4MAAAFxSURBVDjLdZMBjsQg CEXFXgDTCzRwgVbuf7f9gLrtTIdsNvU/Qfwypcyg9cXlK2jhdt8rcoTWkFID4IOoVBGB2uJDVlFi X16pTuCo7fIIiFvmLEknsBN6FfnKQHg39QVkm9FVfwF+j7Zbv4Hjdvk22M2Nxripu0C72T8ozOlR S4QyLRzhp8cUzt2tXJ7HXWktie5g+P2MeaHjF/C3+AGAqG2nHDUKPK07qPFLRqIfAAW3H0DUXoEh PoG6aBc/S4VK/NmV77yPaoAoENc+U68xPL4Xc8kY2TZdDwDVY78fnA9DkF3MBni+FvLJt4/hHMRf n5g2DIwmA1pzVMj1npOG/4OwHNahmmmPU0SvMJhrMV9ZiPhA9pkNbBZLkT7GtkcxJrMeuh/SfaH4 xdTCSIhzHaI1b8LNLLx07cN3VT257Am6zUBKl2sB7UPNfNzfZqncr2Ga6VVy2cerZCD/KrHFG5HH KVbQfldR/HkeNOxU1PoDgHFqbywcqW4AAAAldEVYdGRhdGU6Y3JlYXRlADIwMjItMDEtMzBUMjA6 Mjc6MDErMDA6MDBbHRkPAAAAJXRFWHRkYXRlOm1vZGlmeQAyMDIyLTAxLTMwVDIwOjI3OjAxKzAw OjAwKkChswAAAABJRU5ErkJggg== X-Now-Playing: Ida's _Heart Like A River_: "The Morning" Date: Sun, 30 Jan 2022 21:28:53 +0100 In-Reply-To: <835yq19dk1.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 30 Jan 2022 22:25:02 +0200") Message-ID: <87czk97yt6.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii writes: > Actually, I think this is a new problem on master, introduced by > making the mode-line face be a parent of mode-line-active and > mode-line-inactive faces. When that was done, lookup_basic_face was [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: > Actually, I think this is a new problem on master, introduced by > making the mode-line face be a parent of mode-line-active and > mode-line-inactive faces. When that was done, lookup_basic_face was > changed to use mode-line-active instead of mode-line, so now the > mode-line face is not recomputed when face-remapping-alist is changed. > Instead, we recompute mode-line-active and mode-line-inactive, but > those are not in face-remapping-alist in this scenario, so they don't > change on the existing frame. Ah, right. So we should go back to also recomputing mode-line, I guess... > Do we still need the mode-line as a parent of these two faces, or can > we go back to what we had before the variable-pitch mode-line changes? The plan is to reintroduce the variable-pitch stuff after we've ironed out the width issues, so I'd rather keep the faces as is. (And I think it makes more sense conceptually, since `mode-line' is also used as the parent of other faces, like `header-line'.) -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From unknown Tue Aug 19 05:12:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#53636: 29.0.50; face-remapping broken on master Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 31 Jan 2022 12:22:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 53636 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: Lars Ingebrigtsen Cc: 53636@debbugs.gnu.org, tsdh@gnu.org Received: via spool by 53636-submit@debbugs.gnu.org id=B53636.164363167228473 (code B ref 53636); Mon, 31 Jan 2022 12:22:01 +0000 Received: (at 53636) by debbugs.gnu.org; 31 Jan 2022 12:21:12 +0000 Received: from localhost ([127.0.0.1]:38501 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nEVgG-0007PA-Id for submit@debbugs.gnu.org; Mon, 31 Jan 2022 07:21:12 -0500 Received: from eggs.gnu.org ([209.51.188.92]:42618) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nEVgE-0007Oy-T3 for 53636@debbugs.gnu.org; Mon, 31 Jan 2022 07:21:11 -0500 Received: from [2001:470:142:3::e] (port=43070 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nEVg4-0008Sa-7i; Mon, 31 Jan 2022 07:21:05 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=OJBIPzbnJ4nwV1lYrf8NOxrmPE8WAlfGt/MZcoAq73k=; b=KnX7vvrJIEvq 4ueBR2/Y8JlhIb8OBojiELNixOdtKEY9q8EuJ2i7hbznBNjfi4jW957q8ozADrWLVspt/lH8Ijv5J 5tH2EwVRy9Hcg647DOEh/ubVfxOZ3AsMsaKbLMMBja1j9RqTY6P2OwyRrxp7WNVZqQhEoyvD12cUu H11yMYHjhOYyeG4CYZr2tvMtlXn6gI0Tb7aURjd2mPMzvZynDgrrnobkLBHuqjy5XMv6jLvQEm6Zq ++cr1oWIUPocYJt+IWqM3N5w4EwCgwVxBVfI25OHE62o1kwDYKBhnmtVmTvypwzBbzNhzz4ySRfS6 rrub4MD5cCyszTtMXcoS2g==; Received: from [87.69.77.57] (port=1222 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nEVfA-0005UD-4e; Mon, 31 Jan 2022 07:20:04 -0500 Date: Mon, 31 Jan 2022 14:20:01 +0200 Message-Id: <8335l49jwu.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87czk97yt6.fsf@gnus.org> (message from Lars Ingebrigtsen on Sun, 30 Jan 2022 21:28:53 +0100) References: <87o83tib13.fsf@gnu.org> <871r0p9l4f.fsf@gnus.org> <83ee4p9izg.fsf@gnu.org> <87mtjd8485.fsf@gnus.org> <83a6fd9glm.fsf@gnu.org> <835yq19dk1.fsf@gnu.org> <87czk97yt6.fsf@gnus.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen > Cc: 53636@debbugs.gnu.org, tsdh@gnu.org > Date: Sun, 30 Jan 2022 21:28:53 +0100 > > Eli Zaretskii writes: > > > Do we still need the mode-line as a parent of these two faces, or can > > we go back to what we had before the variable-pitch mode-line changes? > > The plan is to reintroduce the variable-pitch stuff after we've ironed > out the width issues, so I'd rather keep the faces as is. (And I think > it makes more sense conceptually, since `mode-line' is also used as the > parent of other faces, like `header-line'.) OK, I will see what I can do. From unknown Tue Aug 19 05:12:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#53636: 29.0.50; face-remapping broken on master Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 31 Jan 2022 19:45:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 53636 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: larsi@gnus.org Cc: 53636@debbugs.gnu.org, tsdh@gnu.org Received: via spool by 53636-submit@debbugs.gnu.org id=B53636.16436583005478 (code B ref 53636); Mon, 31 Jan 2022 19:45:02 +0000 Received: (at 53636) by debbugs.gnu.org; 31 Jan 2022 19:45:00 +0000 Received: from localhost ([127.0.0.1]:41018 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nEcbk-0001QH-ID for submit@debbugs.gnu.org; Mon, 31 Jan 2022 14:45:00 -0500 Received: from eggs.gnu.org ([209.51.188.92]:58968) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nEcbi-0001Q2-F2 for 53636@debbugs.gnu.org; Mon, 31 Jan 2022 14:44:58 -0500 Received: from [2001:470:142:3::e] (port=53670 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nEcbb-0008PT-L2; Mon, 31 Jan 2022 14:44:53 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=A+Lp815Y1108hIJcSfj5UCUgJAKCvWe124K7qbKGtRg=; b=UDiXmRs+oNqP XVAriaV5lKnNSUPvpBeYuG9Tsa43wWQ5x/ede3RSZIGzJmMDa7ZBnq2JZ6d5C1+eBHfaeIsQHkM5W McBAju2dIuNlpFrkaCWFEvoVo9k7jvVZAO/tfjto/E4N/j5z5VsJi9ioOzSN3/+HIo08ZEls95jkl QhNigPMcogQvjiN/I0edDRkQPuqSfAtIZ2ejdofUB/WEXOj+O/ENrhc0zK+BerqSW+LyjVP2C2mxp CPkmi97r58UWY7qRoYCBqDtSexsnuXj9WG9eJuy1mb9NvfE/ZBCDt9P942RPD1qXkeEq7/lKLiID0 8LM6nrf5H1QtrQ5fo+Rq4g==; Received: from [87.69.77.57] (port=4568 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nEcbZ-0007uI-Dn; Mon, 31 Jan 2022 14:44:50 -0500 Date: Mon, 31 Jan 2022 21:44:45 +0200 Message-Id: <835ypz8zbm.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <8335l49jwu.fsf@gnu.org> (message from Eli Zaretskii on Mon, 31 Jan 2022 14:20:01 +0200) References: <87o83tib13.fsf@gnu.org> <871r0p9l4f.fsf@gnus.org> <83ee4p9izg.fsf@gnu.org> <87mtjd8485.fsf@gnus.org> <83a6fd9glm.fsf@gnu.org> <835yq19dk1.fsf@gnu.org> <87czk97yt6.fsf@gnus.org> <8335l49jwu.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Mon, 31 Jan 2022 14:20:01 +0200 > From: Eli Zaretskii > Cc: 53636@debbugs.gnu.org, tsdh@gnu.org > > > From: Lars Ingebrigtsen > > Cc: 53636@debbugs.gnu.org, tsdh@gnu.org > > Date: Sun, 30 Jan 2022 21:28:53 +0100 > > > > Eli Zaretskii writes: > > > > > Do we still need the mode-line as a parent of these two faces, or can > > > we go back to what we had before the variable-pitch mode-line changes? > > > > The plan is to reintroduce the variable-pitch stuff after we've ironed > > out the width issues, so I'd rather keep the faces as is. (And I think > > it makes more sense conceptually, since `mode-line' is also used as the > > parent of other faces, like `header-line'.) > > OK, I will see what I can do. Basically, the problem is that mode-line is a well-known face name, and so it can be expected that user customizations and Lisp packages rely on the fact that remapping or otherwise tweaking that face directly affects the display of the mode line of the selected window. So when we effectively renamed mode-line to mode-line-active, we broke compatibility, since in some situations, such as the one described here, what was previously done with the mode-line face must now be done with mode-line-active face. Is that analysis correct, or am I missing something? If so, my suggestion is: . rename mode-line-active back to mode-line . introduce a new face, mode-line-base, say, from which mode-line will inherit, like mode-line-active now inherits from mode-line Then all the tricks people play with the mode-line face will work again, and we can warn not to rely on remapping mode-line-base to automatically affect the mode lines of the currently selected frame. Since this is a new face, we don't need to worry about code out there which already remaps that face. But making this new mode-line-base face use variable-pitch, for example, will still produce the same effect that we had with mode-line a few weeks before. Would that be an acceptable solution? (I considered alternatives, but they are all uglier. Basically, the "basic faces" aren't supposed to inherit from other faces, for face remapping to work as expected.) From unknown Tue Aug 19 05:12:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#53636: 29.0.50; face-remapping broken on master Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 01 Feb 2022 19:40:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 53636 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: Eli Zaretskii Cc: 53636@debbugs.gnu.org, tsdh@gnu.org Received: via spool by 53636-submit@debbugs.gnu.org id=B53636.16437443512827 (code B ref 53636); Tue, 01 Feb 2022 19:40:02 +0000 Received: (at 53636) by debbugs.gnu.org; 1 Feb 2022 19:39:11 +0000 Received: from localhost ([127.0.0.1]:44173 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nEyze-0000jW-VY for submit@debbugs.gnu.org; Tue, 01 Feb 2022 14:39:11 -0500 Received: from quimby.gnus.org ([95.216.78.240]:60580) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nEyzc-0000jH-Jr for 53636@debbugs.gnu.org; Tue, 01 Feb 2022 14:39:09 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=VrTe0T4AqnFvGedvD6ZZ0NU+SizflzbncZB1WTYC0nE=; b=R5PRXLwJilX+Ur6Z1zIR27XMb5 TZv1gLEsvhwWjtG4HAzHSY7cRVj65sa8hBNQFFL04/c0DaNYJjwPUs3AqhkOVE1rSVaAfCdbvu/cE h3+7shJ2+mrfvg48a3+7r0SxevHsbiSQi1YdEeK00Js7xOFCGxRCE2sr1PbCzXgs7ZI4=; Received: from [84.212.220.105] (helo=giant) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nEyzT-0002xA-05; Tue, 01 Feb 2022 20:39:01 +0100 From: Lars Ingebrigtsen References: <87o83tib13.fsf@gnu.org> <871r0p9l4f.fsf@gnus.org> <83ee4p9izg.fsf@gnu.org> <87mtjd8485.fsf@gnus.org> <83a6fd9glm.fsf@gnu.org> <835yq19dk1.fsf@gnu.org> <87czk97yt6.fsf@gnus.org> <8335l49jwu.fsf@gnu.org> <835ypz8zbm.fsf@gnu.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAIVBMVEVbXWaKeHWllp3J srCmjHmEe4y4sctpaYrKusrYzdv///+k58upAAAAAWJLR0QKaND0VgAAAAd0SU1FB+YCARMgHSZX M2gAAAF6SURBVDjLlZLPasMwDMaVwch1CX2AxknWew2lu60jL9BA2b2DLMe2UHzfIDjXDob9tpPs JHXzZ2Mfton1k/Q5IPAYYzEnJbPMfiyTbBOC18aRMBPGzGwDcM/wGq/eOGfLNs4SC1zFhhDwnKA5 iYxUEMGN4I6NCYH/K1iwEy4TCnHPog6cxJyd5gtk3jwMgyhAkP7LI5oCzwTS3OmW2JNAutuJvFeQ REcAAiJ1UZYl64oq8qHHUwXqsegkrWpZ6Qq01pWsdV8foKUu2ltVFGVV1BYoxoqylF0q9dKKKsaF gGOGVn2XC+iY00NuokrWF1B8JQdE1miOU2Veb1LJXNGNXoXDtJatFC1tQGx73TSTcg/fOC9F2aW3 2mOr1sTR57rx6CO+SuGrHXa3gC8BAeND/QHYJIhHwcsE2PvC6ixed1Z5EDwALFrQ6bwNAhzq9x44 CHE0AMRA2ymws8BvOhwck+gKhPD9KzAVhwaB6IFrjWsyDo4NGLyM/vwHukllMgpRZT0AAAAldEVY dGRhdGU6Y3JlYXRlADIwMjItMDItMDFUMTk6MzI6MjkrMDA6MDCoICceAAAAJXRFWHRkYXRlOm1v ZGlmeQAyMDIyLTAyLTAxVDE5OjMyOjI5KzAwOjAw2X2fogAAAABJRU5ErkJggg== X-Now-Playing: Nosdam's _Rayon_: "From Nowhere To North" Date: Tue, 01 Feb 2022 20:38:53 +0100 In-Reply-To: <835ypz8zbm.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 31 Jan 2022 21:44:45 +0200") Message-ID: <87fsp2v0ky.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii writes: > So when we effectively renamed mode-line to mode-line-active, we broke > compatibility, since in some situations, such as the one described > here, what was previously done with the mode-line face m [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: > So when we effectively renamed mode-line to mode-line-active, we broke > compatibility, since in some situations, such as the one described > here, what was previously done with the mode-line face must now be > done with mode-line-active face. But this is a bug, I think? You can see the same effect in Emacs 28 if you do: (face-remap-add-relative 'mode-line 'link-visited) This won't have the expected effect on faces that inherit from mode-line (line mode-line-inactive/header-line) in the current frame, but if you open a new frame, it'll have an effect there. > Is that analysis correct, or am I missing something? > > If so, my suggestion is: > > . rename mode-line-active back to mode-line > . introduce a new face, mode-line-base, say, from which mode-line > will inherit, like mode-line-active now inherits from mode-line The new mode-line-active face was supposed to fix the decoupling of mode-line and header-line. In Emacs 28, there's no way to change the look of the (active) mode line without also changing the header-line face. Introducing a new face that mode-line inherits from doesn't solve this issue. > Would that be an acceptable solution? (I considered alternatives, but > they are all uglier. Basically, the "basic faces" aren't supposed to > inherit from other faces, for face remapping to work as expected.) Making face remapping work reliably for these faces would be better, but I haven't looked at the code. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From unknown Tue Aug 19 05:12:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#53636: 29.0.50; face-remapping broken on master Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 01 Feb 2022 20:11:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 53636 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: Lars Ingebrigtsen Cc: 53636@debbugs.gnu.org, tsdh@gnu.org Received: via spool by 53636-submit@debbugs.gnu.org id=B53636.16437462086087 (code B ref 53636); Tue, 01 Feb 2022 20:11:02 +0000 Received: (at 53636) by debbugs.gnu.org; 1 Feb 2022 20:10:08 +0000 Received: from localhost ([127.0.0.1]:44222 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nEzTb-0001a7-K5 for submit@debbugs.gnu.org; Tue, 01 Feb 2022 15:10:07 -0500 Received: from eggs.gnu.org ([209.51.188.92]:33908) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nEzTZ-0001ZV-Vm for 53636@debbugs.gnu.org; Tue, 01 Feb 2022 15:10:06 -0500 Received: from [2001:470:142:3::e] (port=46920 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nEzTA-0007mt-EM; Tue, 01 Feb 2022 15:10:00 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=7L28qOOkcOMwdlUXoFe6dvy7EY9DuT4ZkaTzuQiQACI=; b=d68JGj0FgHQd wz2DB8HiAyZ11iWOxXmzchUlT+1Aqwdv2CZxKWbnfQ51iUGbxntFeQUGdkyozu4JVeeIBHn0m9zKJ PyGjqNiQWEWt0M7C28XzoPDEEKtQY5PT4im9pwFlANCB8Yfz9Xf3WL8xMsGg38LR1KodhjiBp/e2O sQg3nT6GxIDTbJDhqaycQdhYLEunm/WMkXi6OCwyh1UHU3vny1BtWUtUgJpReH/DwHm2GN7fw04I0 vutGqWzT9kD91s2d4T6C23nH6zlARPtDBno9WqlK5k50sRWnc0K1tePmQvwNIzr/bwSS5ogtCEdvy 2Mw3WS35UkzYAqOReJ7/iQ==; Received: from [87.69.77.57] (port=2912 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nEzT5-0000Q8-T2; Tue, 01 Feb 2022 15:09:37 -0500 Date: Tue, 01 Feb 2022 22:09:35 +0200 Message-Id: <83leyu73i8.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87fsp2v0ky.fsf@gnus.org> (message from Lars Ingebrigtsen on Tue, 01 Feb 2022 20:38:53 +0100) References: <87o83tib13.fsf@gnu.org> <871r0p9l4f.fsf@gnus.org> <83ee4p9izg.fsf@gnu.org> <87mtjd8485.fsf@gnus.org> <83a6fd9glm.fsf@gnu.org> <835yq19dk1.fsf@gnu.org> <87czk97yt6.fsf@gnus.org> <8335l49jwu.fsf@gnu.org> <835ypz8zbm.fsf@gnu.org> <87fsp2v0ky.fsf@gnus.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen > Cc: 53636@debbugs.gnu.org, tsdh@gnu.org > Date: Tue, 01 Feb 2022 20:38:53 +0100 > > Eli Zaretskii writes: > > > So when we effectively renamed mode-line to mode-line-active, we broke > > compatibility, since in some situations, such as the one described > > here, what was previously done with the mode-line face must now be > > done with mode-line-active face. > > But this is a bug, I think? You can see the same effect in Emacs 28 if > you do: > > (face-remap-add-relative 'mode-line 'link-visited) What do you suggest instead? to treat some basic faces specially because we happen to know that they inherit from other basic faces? That's ugly and fragile. If we want to solve this cleanly and radically, I'd prefer to break the vicious circle by removing the inheritance from basic faces altogether. The basic faces are just that: they aren't supposed to inherit from other basic faces. That would also decouple header-line and everything else as a side effect. > Making face remapping work reliably for these faces would be better, but > I haven't looked at the code. Maybe you will see something I don't, but in general face remapping isn't magical, we must explicitly account for it where it might matter, or it will not work. After all, all face remapping does is add some members to a list, it doesn't actually change any faces. So we need to do stuff like this: if (! NILP (Vface_remapping_alist)) remapped_base_face_id = lookup_basic_face (w, XFRAME (w->frame), base_face_id); That's how face-remapping-alist takes its effect. If you want this to work for inherited faces, you must do this for the parent face, recursively, before you do it for the face in which you are interested. You want to add the inheritance-chasing loop to basic face look up? I don't. From unknown Tue Aug 19 05:12:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#53636: 29.0.50; face-remapping broken on master Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 02 Feb 2022 18:01:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 53636 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: Eli Zaretskii Cc: 53636@debbugs.gnu.org, tsdh@gnu.org Received: via spool by 53636-submit@debbugs.gnu.org id=B53636.164382480624135 (code B ref 53636); Wed, 02 Feb 2022 18:01:02 +0000 Received: (at 53636) by debbugs.gnu.org; 2 Feb 2022 18:00:06 +0000 Received: from localhost ([127.0.0.1]:53434 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nFJvJ-0006Go-5P for submit@debbugs.gnu.org; Wed, 02 Feb 2022 13:00:05 -0500 Received: from quimby.gnus.org ([95.216.78.240]:42166) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nFJvE-0006E0-TN for 53636@debbugs.gnu.org; Wed, 02 Feb 2022 13:00:03 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=QWVeu+WLkN5PSrwrF3PC8Em/AFvXKUK4sar0X1gHsds=; b=KNWuNB+o3hwUHhY1hOfO03K66z ebGu18dTPxqUzh6dYXhQRoJ5GiHFZix+4xXnhUPj5PtRhUvcVlpoMWMngEpDJOcpriAphMqOHFn+o WzvZGxOKJzGgrq8nM/JuXGy0xXdsMtZ6BKV2ahkWO+0NURkTkq/7RuIn0hA4oTDWQumc=; Received: from [84.212.220.105] (helo=giant) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nFJv5-0006S2-IP; Wed, 02 Feb 2022 18:59:54 +0100 From: Lars Ingebrigtsen References: <87o83tib13.fsf@gnu.org> <871r0p9l4f.fsf@gnus.org> <83ee4p9izg.fsf@gnu.org> <87mtjd8485.fsf@gnus.org> <83a6fd9glm.fsf@gnu.org> <835yq19dk1.fsf@gnu.org> <87czk97yt6.fsf@gnus.org> <8335l49jwu.fsf@gnu.org> <835ypz8zbm.fsf@gnu.org> <87fsp2v0ky.fsf@gnus.org> <83leyu73i8.fsf@gnu.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAG1BMVEWYi3bcy67p1bPf zK5fVk1KQjyEeWpDPDb///9hueWkAAAAAWJLR0QIht6VegAAAAd0SU1FB+YCAhEzBDLioboAAAGq SURBVDjLrZRbTsMwEEUDiviOmQ1QewXj2QCPOPyCGpMNVKygabfPnbEdgVq+wFKiyMd33k5346+v 7hew+yMIzhZJAU6YhEUoDv1Y1pMBwZ4TIO8APvCkDcCKmhoM3DVFUOAbmPvpGxAnjpz6mOd+bgD2 hYP66BS442F6qYoY4SJEgDnlm9yPFcStPgoel+kKGFNejmv/Xk1tYEwp59OY3n8qQprGDMUF8IdP BWu+BCgTbOWlgtBAQuIAH4f9z7IHhJTzOT8NlyArehta5kIiUXbhFSDP+VQUkbBpqwCgVAFJBYvt r8u63ynQ6mprOZTzeF4eFLBoRyAz5+benEMRqqmk9tGnZEAHwQgDzMgxTa/PBlg252M+r+NyXPZF oVPFpK3FutPXbQPwDZ0X8uy4jShZHo7JiszItgFXBrRMl4RtqMkSxGTpPG5driCqgL2NuqoN4JuC lpE9ObjiGLkBNaU+2Vkg2utd1wHo+WghCXM5U0ApL+sVUrYBuzV6S8o+UwOtVr59xG+mgloupbQb VkwRgie53xSQGEDkejL4WAQBZxTQ9R/A/4EvkUS/H2sl77AAAAAldEVYdGRhdGU6Y3JlYXRlADIw MjItMDItMDJUMTc6NTE6MDQrMDA6MDBbfoihAAAAJXRFWHRkYXRlOm1vZGlmeQAyMDIyLTAyLTAy VDE3OjUxOjA0KzAwOjAwKiMwHQAAAABJRU5ErkJggg== X-Now-Playing: Frank Cloutier and the Victoria Cafe Orchestra's _Anthology of American Folk Music: Social Music (1)_: "Moonshiner's Dance Part One" Date: Wed, 02 Feb 2022 18:59:49 +0100 In-Reply-To: <83leyu73i8.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 01 Feb 2022 22:09:35 +0200") Message-ID: <87k0edrvxm.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii writes: > If we want to solve this cleanly and radically, I'd prefer to break > the vicious circle by removing the inheritance from basic faces > altogether. The basic faces are just that: they aren't suppose [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: > If we want to solve this cleanly and radically, I'd prefer to break > the vicious circle by removing the inheritance from basic faces > altogether. The basic faces are just that: they aren't supposed to > inherit from other basic faces. That would also decouple header-line > and everything else as a side effect. OK, you want to change the header-line and mode-line-inactive faces so that they no longer inherit from the mode-line face? But they aren't the only basic faces that have this problem -- `tab-line' inherits from `variable-pitch', for instance. > That's how face-remapping-alist takes its effect. If you want this to > work for inherited faces, you must do this for the parent face, > recursively, before you do it for the face in which you are > interested. You want to add the inheritance-chasing loop to basic > face look up? I don't. No, I don't. I was thinking of altering `face-remap-add-relative' so that it resolves the faces that inherit instead of leaving it to redisplay. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From unknown Tue Aug 19 05:12:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#53636: 29.0.50; face-remapping broken on master Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 02 Feb 2022 18:09:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 53636 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: Lars Ingebrigtsen Cc: 53636@debbugs.gnu.org, tsdh@gnu.org Received: via spool by 53636-submit@debbugs.gnu.org id=B53636.16438252881183 (code B ref 53636); Wed, 02 Feb 2022 18:09:01 +0000 Received: (at 53636) by debbugs.gnu.org; 2 Feb 2022 18:08:08 +0000 Received: from localhost ([127.0.0.1]:53449 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nFK35-0000J0-Lz for submit@debbugs.gnu.org; Wed, 02 Feb 2022 13:08:07 -0500 Received: from eggs.gnu.org ([209.51.188.92]:56912) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nFK32-0000Hy-5G for 53636@debbugs.gnu.org; Wed, 02 Feb 2022 13:08:06 -0500 Received: from [2001:470:142:3::e] (port=40854 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nFK2w-00069w-Ua; Wed, 02 Feb 2022 13:07:58 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=kTtENHZum2tJPrSnh2NEXehIrLj1RmelZYi7d7tKjBA=; b=ii7hX/FoTfX8 h1139+WJ9SGZrwHqvVNeE9v9V7d+2Ew0sH/bkaG8lVnBHbd70popmQgR4Smk4+0jS/fVko5rdoJFb DW/JrSonPX6MnTWXrRrxZTaEGc7E+UDRT8vOtonmYwsTGxyDTIywYpO7neLeSytkskNpju4UIOo/a d8nCFaUy4tC0VTYJTXcUOM3NWZ+klb2vyuSTIPmbo/8tqkE03WI++Flr9L3lao2iAAVDG/UY254UP 5yXHU5f2CDSWoJBj9/3lTqJArpovn+5pk7QHMBnLWgiVkYSA005baZdBiadYrj6S1QPjqmNemk1Al 18gITmUlZcpk3cj468fF7A==; Received: from [87.69.77.57] (port=4472 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nFK2w-0002OW-7w; Wed, 02 Feb 2022 13:07:58 -0500 Date: Wed, 02 Feb 2022 20:07:58 +0200 Message-Id: <83sft15egx.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87k0edrvxm.fsf@gnus.org> (message from Lars Ingebrigtsen on Wed, 02 Feb 2022 18:59:49 +0100) References: <87o83tib13.fsf@gnu.org> <871r0p9l4f.fsf@gnus.org> <83ee4p9izg.fsf@gnu.org> <87mtjd8485.fsf@gnus.org> <83a6fd9glm.fsf@gnu.org> <835yq19dk1.fsf@gnu.org> <87czk97yt6.fsf@gnus.org> <8335l49jwu.fsf@gnu.org> <835ypz8zbm.fsf@gnu.org> <87fsp2v0ky.fsf@gnus.org> <83leyu73i8.fsf@gnu.org> <87k0edrvxm.fsf@gnus.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen > Cc: 53636@debbugs.gnu.org, tsdh@gnu.org > Date: Wed, 02 Feb 2022 18:59:49 +0100 > > Eli Zaretskii writes: > > > If we want to solve this cleanly and radically, I'd prefer to break > > the vicious circle by removing the inheritance from basic faces > > altogether. The basic faces are just that: they aren't supposed to > > inherit from other basic faces. That would also decouple header-line > > and everything else as a side effect. > > OK, you want to change the header-line and mode-line-inactive faces so > that they no longer inherit from the mode-line face? Yes, I think this is the best way forward. Though it will be somewhat backward-incompatible, if someone customizes mode-line and expects header-line to follow suit. > But they aren't the only basic faces that have this problem -- > `tab-line' inherits from `variable-pitch', for instance. We should "un-inherit" all of the basic faces. > > That's how face-remapping-alist takes its effect. If you want this to > > work for inherited faces, you must do this for the parent face, > > recursively, before you do it for the face in which you are > > interested. You want to add the inheritance-chasing loop to basic > > face look up? I don't. > > No, I don't. I was thinking of altering `face-remap-add-relative' so > that it resolves the faces that inherit instead of leaving it to > redisplay. I don't think this can work, because that would mean the original face will be affected by remapping, won't it? Face remapping is buffer-local, whereas faces are defined for the entire frame. So we cannot affect the original face and keep the effect buffer-local. And if we produce a different face symbol and modify it instead, then references to the original face symbol will not be redirected to the remapped face. From unknown Tue Aug 19 05:12:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#53636: 29.0.50; face-remapping broken on master Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 02 Feb 2022 19:49:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 53636 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: Eli Zaretskii Cc: 53636@debbugs.gnu.org, tsdh@gnu.org Received: via spool by 53636-submit@debbugs.gnu.org id=B53636.164383133532169 (code B ref 53636); Wed, 02 Feb 2022 19:49:02 +0000 Received: (at 53636) by debbugs.gnu.org; 2 Feb 2022 19:48:55 +0000 Received: from localhost ([127.0.0.1]:53708 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nFLcd-0008Mn-Dr for submit@debbugs.gnu.org; Wed, 02 Feb 2022 14:48:55 -0500 Received: from quimby.gnus.org ([95.216.78.240]:43336) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nFLca-0008MY-LN for 53636@debbugs.gnu.org; Wed, 02 Feb 2022 14:48:53 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=vAKFUnvN+qwi8aVT1jfk6bnY0JSnr8VdPojpsWsISHg=; b=DO0ppsZqW1MIlFLGBcgvocNPvw yi1BI/BrwVpVbP9xIdBvGSuoBn+5IzIxrFODIGUwd2JJhX8c0bCMciOuz4gd6digFmkV07WoaCylN pNwcX1OUAmAdroIQyhdHIN0c2eaDlvlNib4Wv5lmElXQ/UJ8i45KcBsdrJBnqzj+2tBE=; Received: from [84.212.220.105] (helo=giant) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nFLcQ-0007bH-SA; Wed, 02 Feb 2022 20:48:46 +0100 From: Lars Ingebrigtsen References: <87o83tib13.fsf@gnu.org> <871r0p9l4f.fsf@gnus.org> <83ee4p9izg.fsf@gnu.org> <87mtjd8485.fsf@gnus.org> <83a6fd9glm.fsf@gnu.org> <835yq19dk1.fsf@gnu.org> <87czk97yt6.fsf@gnus.org> <8335l49jwu.fsf@gnu.org> <835ypz8zbm.fsf@gnu.org> <87fsp2v0ky.fsf@gnus.org> <83leyu73i8.fsf@gnu.org> <87k0edrvxm.fsf@gnus.org> <83sft15egx.fsf@gnu.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAD1BMVEX7bDxOZ1OdqVDV c0b/////GX2jAAAAAWJLR0QEj2jZUQAAAAd0SU1FB+YCAhMlJviegecAAAGVSURBVDjLdZOJsYUg DEUjNGBIA4INgPTf279Z0Lf9zDg6OWS7QSLixjRK3Tc2K3POTrAsdFGlxMnBiUddlKS1dozO2YG+ JDHRaGaFCY7KZRNN/AB8Vt4Ty7bDpeAyt4MDhwEq+ggAQ2u8Uy4ZJ4aCdIOKbpKgw1EVtFq8CABG QmnS5gDCcJBtBHu9gfofGFx/g9yHgjoWKKUWDALdDFjM8Q2yAiGdQ0EzsKl+mJw7PQMOXQFm3KCL gah+KkAyjQjgId3BJlDLU3lIFQfptDkdaAyzAzK5F5g0xwLTTTuxyKSzko+iV0WBXhel2uxJcSVW XvQ/repxa+jVPRsuR6EUwOrotm0sPDkAzl7NiqmimXfflwFLDZ+1GIvSz2YLxcWxLoS2AEUB0jsY UR0N7ewgyQcQA4f+Dib7Armw3xorriCKX7zE0Tq0RifiMDhk4nfqn0BcPgnPA9gV7yFvN3AMP3uV vhZiB6KRw5XmB/RXcC2QNMcD4me3iAXEr+I3KFja4BtcD7i90e4N6hsoLxHtNtPtt/0BL0RR8q+q zVgAAAAldEVYdGRhdGU6Y3JlYXRlADIwMjItMDItMDJUMTk6Mzc6MzgrMDA6MDANHFOCAAAAJXRF WHRkYXRlOm1vZGlmeQAyMDIyLTAyLTAyVDE5OjM3OjM4KzAwOjAwfEHrPgAAAABJRU5ErkJggg== X-Now-Playing: Sacred Paws's _Run Around The Sun_: "The Conversation" Date: Wed, 02 Feb 2022 20:48:42 +0100 In-Reply-To: <83sft15egx.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 02 Feb 2022 20:07:58 +0200") Message-ID: <871r0loxr9.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii writes: >> OK, you want to change the header-line and mode-line-inactive faces so >> that they no longer inherit from the mode-line face? > > Yes, I think this is the best way forward. Though it will be somew [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) --=-=-= Content-Type: text/plain Eli Zaretskii writes: >> OK, you want to change the header-line and mode-line-inactive faces so >> that they no longer inherit from the mode-line face? > > Yes, I think this is the best way forward. Though it will be somewhat > backward-incompatible, if someone customizes mode-line and expects > header-line to follow suit. I think this would break a lot more than the current situation does. Lots of people expect these faces to inherit the way they do, and have set up stuff based on that. Programmatic remapping of the `mode-line' face, on the other hand, is a much smaller issue, and we can just say "use `mode-line-active' instead". >> No, I don't. I was thinking of altering `face-remap-add-relative' so >> that it resolves the faces that inherit instead of leaving it to >> redisplay. > > I don't think this can work, because that would mean the original face > will be affected by remapping, won't it? Face remapping is > buffer-local, whereas faces are defined for the entire frame. So we > cannot affect the original face and keep the effect buffer-local. And > if we produce a different face symbol and modify it instead, then > references to the original face symbol will not be redirected to the > remapped face. Hm... That's not quite what I'm seeing with the mode line faces. In Emacs 28, with emacs -Q (face-remap-add-relative 'mode-line 'link-visited) C-x 5 2 --=-=-= Content-Type: image/png Content-Disposition: inline Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAA1QAAADQCAIAAACPyrdZAAAABGdBTUEAALGPC/xhBQAAACBjSFJN AAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAABmJLR0QA/wD/AP+gvaeTAAAA EGNhTnYAAA8AAAAJYAAABwEAAAfxAEp0cQAAPepJREFUeNrt3Wd8HMXBBvDZ3etdp94tq1jFkmzL 4G5siksCmFBCCDi0BHASEiAJEAK8CS0QCCRAgBBaYjqGAMEFbGzciyTLsmVZ1Vbv5XrfnffDSbLK nYpVrXv+Pz7g082VudndZ2dmZxnii8lk8vm4Wq0mAAAAAHDeYlEFAAAAAIED4Q8AAAAggCD8AQAA AAQQhD8AAACAAILwBwAAABBAEP4AAAAAAgjCHwAAAEAAQfgDAAAACCAIfwAAAAABBOEPAAAAIIAg /AEAAAAEEIQ/AAAAgACC8AcAAAAQQBD+AAAAAAIIwh8AAABAAEH4AwAAAAggCH8AAAAAAQThDwAA ACCAIPwBAAAABBCEPwAAAIAAwvh8lFLa2NiI2gEAAACYZkQ+H21sbCwtLUXtAAAAAEwzGPYFAAAA CCAIfwAAAAABBOEPAAAAIIAg/AEAAAAEEBGqAGB6cHxw6uTrVurnr9ya5DkPaBlUEwxA86qO39/m Hth0gsNmfRinFo1vcYD+7OaaO8pa6igzIzL19WilGDUy9gJuu3R+XFL0qlW2Pi39NgUz4cUBAMYd 9bQ9dLzqkOD9F5MZO/vv4dLpu8OieyoL/tgpUEJEyug30yLjzulVXG5HudVy0mo5abEWW+3tAqGE EEZzX1bKFUgfE/p72jfVtdVTwoiCbg7zn/yo8amC8u3C8F6TkeOo3RdOygAApheLyXj87EGRlhlN 7eGhIX6fzkTpwm8S8z1dd62m1m+sHjrcdxtl8clHXR1Pl9XscnjcaDpTQHtH3SdWgRImMSxyGWL3 eEH4A5gmGCkn0oh6jrnUzfP28+gIDGOGLzSY7d42QQglxGUx5rlD1/g/jkbpIm7T9fyLnhQ6to8k vY2y+KSj1FXrRPKbGgTrJ40mCyEMp702VM4NrxDDMKKhnsGd/3UzpqZ5+HP+93Rtiy7mJ3qZ3P+T XE7jh7WtJHLmT5TsmBYHmEjSq1Oyrz77T/eW8uPPGpH+Ao9gOWj2UEIYVrNSY9tl8FDBfMjMr9Zz GPQaFKOQyFOVytlqdZKn9fEGM+LgxDN0Nm52UEpIcFDoRcPt9mOSo9NfjZDjADwS0zr82Y2N73cY 2jpM37VH3B0XsVg6oG1Q19Hmur83dNQIRE0MVybpdWNXHABg4rktxjw3IYSIlbobg7hDhk4b4QuM ZodeJ0ft+MJwmpsSUsJUypkSzruXd3R0IChPBse2FqOVEEKkK0M0aK7jaVqHP7k27vkkyb/qm/YZ Gx4+2b40Kv6XYdLuP9IOc8urNQ3f2nnCSi+IiL4zon90G2VxAIAJR8tMxjZCCGESNJo4DUllO48K xGwynBB0F6JvxBdGpFisRzVMPo+1bYuNUkI4adDFSsTvcTXNh33ZWF3UY9rQ4631rze076sry29X z+Apoe4jdSWfm2wWwiUGx9wZFTZfyo5D8fOetb386jNGV/c/5frEL2YGian7RHvLF+2GE3ZnB08k IpFOJIlXqFdFRq+QDXwNocnUsbXDkG+x1brcVoGIOFGoVD5LrV0eHLxEIeo/D4OaXjhe9qW330I7 45ME+b6Ghk87zY2CKFatvzEm6iIZ63Ea3qqt/8bkMBAuTK65LDL6Rp1UMuCNHS5rntFUaLFWOhz1 LreJF5wCkbAirUQSq1Bka/SX6tWRPn4356elRS+be0ZLpdenzr5LRZtMrR80tx+yOjp4IhfLZmmC rogIXyZjx3P/NMKqAyCEUPtho0sghDDSeRqpSKzJkTNHrZS6TYes9EI1DqgwddvuqY6OekoIIeG6 oOTxbKo1jadur7d6CLNgRvYDsvbX61sOWF1OVpqpj9wQHTyTIyZry6u1zfttLgcjnqkJuSU2cqHE xwfiPc4TJmO+yXzKbq9xukw85RlWJZJEK5TztMFrg30eYnzyVBk6thuMx6z2OqfbSomUE4fJFbPV upXBQXOlg0zYoK2Wjq1tnXlWW63LY+Ypx7JqiTRGpkhXaxbotFl+y55n4c9z2mxrEyghhDBMsEKT OJzPz4izwma8FBy+u7HujRZjsUAI8ZSahDB1+M9jI1cpROy4Fp9eeLfhXxVVm3rN5va4XTa3q8Fu k+giV8j6VIbHZfx3VfVHJlfvqTM8766zuetspp3NDQnB0Q/EhaX4SzGC/b3y2k1W71WErnJD058s jvtTQo5XVm5zUkoIIZ5Ga8fGSmtHUtp9WlGvJu765nTp3zuctgEv6RTcLQ53i8Oa39H6n3r1jxNm 3qwRD9UA+OMNFQ83WMzdD5hdtrw2W35H+yXxSQ8Ey8ZjGxpt1UGgEpzGww5KCGFE6hwFQ4h0nlrK WR08ceUabR61Etf4wRRFrXs7XQIhhIjnaeUT01At5tr7atqrvJfGC468ljO/dZMXI5xPljWU8N6n uEo7Gx5x8M+lxWb3OVTQooaS/2uydvRba4byBpfd4LKfNLR92Ki5YUbCkIcYi6315ar67TZP71ey eVxVZleV2bC5sS4lLOGZWK3Wx9Zu31J9+uV2u73XY7zAtzts7Q5boaHtw1rxFSlZ92p8xr/zK7lQ 64flZQ+Ulz9QXv5AWcX7lhFMZmc4WaZOO1va1VXDsJJ0rXaubLjRbZTFp8m2Kdg+qDi9aXjX8Xkc bU+UVLzXN770eTXCn26vubes/pjHzytYWv5r5Xu/F/UYXiur+ror+XU/SJ07mjs7+m5+jXaXbchP 6DZvrKh43zb4t6GdHdWP90p+vWrD8W1V5WsmfswvqRh91UHAajIaTlNCCFGpNWkMIYRJ1KiDCCGE NBqNZ3D9D0xVvMOY7yaEEIZVZism5tBKT7a317LSTI0mrbuHrLOz9jeVTaU8F6nUXKCWefvKPfa2 TYb+B74Ou72zO68xrChSrkhTq7NVyngx5z0rd7tMGyvKXjS6B9nsOow1vy6p/ro7+TGsKEahzNao MxTSIJYwhFDqqbTYLT6KuvdUl/+1O/kxrDheqblAq71QrUqWiryXylAiuPy+d2CcBjocxo/r6z7q tNsZkYoVzAKrYl2768oOtmqvjY65QS9XjmfxacNlav5IEIZ1+BCsb1fW7HHRfk9mCaGE9H7QZm18 okb+z5n64IHbJaUewmgkYuJ2mbrLGD0eQhiFWCznXR1C10s5reZiIXSZ390FIxeLgzhOzhCLy9nC n/0KVLB+UN++Njkk2O83ce9q6fQXsSi1f1HbtCo9OmUMRyjGouogULlyDXaeEELYdI3aO19erNRm i1q/9RDeYTziiErGLHqYkjrM1hpKCCGcTJU8UcmE4bT3pCddLmGIYP+w7NTrFoEST4uLmx+b9lS4 TExoQ2v5HdUmK+ELjRaXXiftW1wkVi4N1l8cpJujkKrOHgWowdaxsbr2v1YPFez/q65fNHvGAl+H J4+95YnTLacFQghhRMorYmJv1KvCep5J3aWdLRsbWg77+uQea8tbHd6OUlFWZML9kdroXm/hctuO dLZ/2dzp/6tP9/AneGzbG2vfajW3CEywOvy+uODW6lP/tErXJc2cZax7udn43mnTlubgm2Ojv68S i8a6+HSrTEFwEkIIo1fqVmhVSTKxhPIGl73IYDho7R2Q6JmWmk32sxmL4ZRXxsT8UK+K5Bin23a0 vfHVhs667nOm9o6690N1d6sHbhxMTHjKP2PVjKV2Q2lzdffLaYNmvJkYrHW2/O5kzTGBEEKo4Djj JMv6HtUYVpqpC1oRFDRfLY8R9UzOExqMjX8501jY/Xnt5vZ9rpB1En9fmropYVjJoojoH2ikIrd1 W0P99l5fzWNv/cwY8aBurMZfx6rqIBBRj+mgVaCEMIxivrp7IgSnzFGyO40CpbZDJteP5RLM+4Op Rzhts3kHWuVyecREvatcE3Kxd4Ng5RfrlW9azB5CGFazNkQmJoQQJlKnz6gxHaHEbnc0ERJ/tiiT HJHyH7kqwsfel9Epgn+ZzBhOnt7pJoKrc6shdoF+4DHCta227hhPCCGMSHv3rMQf9FushhHP0kc/ odN/0+oceICqNRq98yMl6qjfR2v71ZhErFgaplgaGmkQ/G3u0zqwOCwN91U0lHgIK1aui4u/PUSh Js6PvbXKypZGJ+foO/5dU/upue3vJR1fhCf+LVarGbvi0xLDytbEJ94dLO8dtK6JjG0zNR9kevKV +bNma89lIgwjvyYp5efqrk51mVixOCJxJld+R7WxeyzVtaPVeJs6aEAHqihbq1IQQpS6HHFzddcr MqlarZ4QRqq5UM4c897Klro7PJSQ7g/AiLIiZv5Lq0sUDWz3bJQ2+p5w48/qbd74RwXbCauwTjJI fhIvipv1eIj3oh7VHLVMUlyx+WzPnOewweLUaaVjswMcq6qDQGQxGU4IhBDCyjTzzh4uxHM1Ss5o 9hBaZjC0h4eFoKZgynFXO7xTaJgwqWSEwYSW1Z28pG6wZ0j0iV/NDBqwbiATKpX27Lr1UqmCmE2E sBJpTPcBgRFJI0WEuAnvcXVQEt/rkBKpVA3yjowo6PIg8a4WNyV8mdXu0av6fSmPtXWT2XueL1oS O+Mqf8sUsvJV4QO762mry+3Nylq5PMT/h/DfLzGtuwykcuVMTpQUEvdieto9IQr1gCfI5fq7Zs1+ LSE8Q8zFKPo/YZTFpyM2MzrpN32Tn7eJhWgirui+kNBl6TjYa7aaVBN+g7r/BUcRwWFLe20KZpPx pOC/4TJi/dkYx+nF3lcT6c6+Am/sMx9DPDc4yFfy6xIq6T0DV6h3uga5P6RIHnp78NnLuRmRdn2E uvd5mNliqRqjqVRjVnUQiPhj3Tf2CNNo4nq1m1CN2nvQcluNuZgnClMQdTV1T0/TS8QTFkzU4l4T 90WcN80xInGvy+I5lfdQ4nGbR7afZ6JkUu8RrMPlGrDZ0UpDZx0lhBBWEnydXjzS/ngx29XdYnY6 Lefy1c+vnj9G+9C8+Q8N/+mc9hdpmRIRN+iYHJcYHPtiUJSd7X+UHWXx6YcR6a4JlQ05wFlnsRp6 FUpQq3UDn8TKE2QM6b5kh/L2She5cMBKMd3bJdNrA2W6Qx0rZpieWXCuAXMRqeA61tm+32gptTsa XW6zILgp8bXxUqPbI/g9D2Jig3TxfX/aUJ02tdZU2P1agsteR8mssfj5x7DqIOAIloNdlx+J5mgU vXftnEwzT9JQ6SRUMB8yedboRRj5hamF8oaufMSouBEvoTXk7d3ExPdLSnu9FcOwEoYQShiWk/V6 VMoQQggl1N/FE1Rwn7FaKx3Odg9vp5R2H2ictq4SAs/bCem7k3YXW5zerrsgrTZtxBskE6eQiYjL RYjT1PB8s+zeMFXQyF5kus9Tkw9vNTSG5RTjUHya4WTK5KHPyIQGh7NXVxQ9VXdi8A55QgihrmYX JbL+jZcZ8D+9/r/PJb88pb3GfYUz7TV/qWsvddPhnKq5hEG6ztgZ8v55lxHLZ4hIYXcXHaXuNjch YzDuO5ZVB4HGbTXkewghhOFUOap+k4cUOWrRJqeHEuGYwWzXBwXC/grOJ5R3djdW6ciz3znf3q1P n03P/X+Z3n0BTNdzKB141a7TZfy0vuGLTmurQAY51lBC+/f8UVed01uCiVOcy7o2el3oMrHpWzeh 1LW3tuRgkzxbrZmrVqYqVSlyyTAW9Jyo8Oex1N9T1dHpq3pkuvh/xmqmcQqdNt+dFYm1Qz+LN3ro yEdBqX10Y5d8r5eqaa24r9pkGHbZQd+Z0/noJRHrRAw5uycQbDwlZPTxa3KqDqYFWmYwtXlbp1I7 p/9JK5uhUcvbOm2EmM3GE0LQAlwjBFMUM5HrETG99tsM6Zm33mcgqOfBfnvnTmPtg6eby/jhbJ0D o6HH2FWQ0YrOZdiQEQXdPTOyobKxxEMoIR63Pb/Dnt9BCCEMK4pX6S4JDf9B0CBLkUxY7qB8k8PZ 7usvcjc/gT+2eHls8gyejZIyE1d8qnz3UW8nQ3WtdzXqc/lKAh2jrivqan+lrn/yYxguVCaPlnAq lmUI4V2Wg1b38CIT42O7ZJi+gZDyY/PZJ7nq4DxG7YeMXVNXBWvTb0629G8UgqfrCie36ZCFLtCg 0cBUwnDdYyeCSxiTc+nxJThbnjrTlfw4sfKS0LDLdKpEmVjDsj1nXoa2sh9Wmfws10p7ZipxzDl+ Wa06+sUMzeampq/azZWe3kuYeapMbW+a2rcExf05ITTe95lewC33zkYoNRGTVvw8rztmOFsk02+U VCWVhw/ZzcBwYWPUFdHS2X60TxZj44PjHooJTuk1odbYVn6d1Ti88CfYBiY7ytv6FGYlzJjsqsa2 6nB0DyCCw3i4axSJeHhntX2Q57pyjVaPRoVbfcAUwnA6ESEuQgg1ewRK2Km9/xKONTcd9RBCiEga 8sis+OW+FlByCYOM5LAytmvUyc4LhJzjYmEisXpdrHpdrNDhsJVYrafM5jyTqbRrCjxt7Kz5k0zx WrTS11JmE7UDEKnjNs2PC8xWHWDfndOLOOZsHxaTFpnyTIh4orZkodJm6z27gpWG/iY+JKVvPDJ7 ht/F5ml0eSjp+/mps7HP1F9OK5qCVcf0/dLUjbs7TF+NphHcvaPJZDxDVck4O4Cpg5FESBjiooSQ DrdbIFP73uXUfsjg7WjnFkbFLPO9dCbtcA+y0xWHir07e9ricglEPrreD1YvUy2WqRYHh99OPKc7 mv5e03TCQyihVS3NhyNmLvNRmzj7g7HeiOMUMo5YuhMYrbbZPUQsnqiN0uTpc92vTKme1X+rEs7Y nMMeqKXlJrMtVN975oTbYinu1fPHcNII/9tRk7ntqLP3hA/J3GBNFDMBVccoOIY5O02FdrgHpFiY Jly5Rqu3SYeFpbwX53sascdSd0tJUz0hvMN42Bmd7P8Kca67j58XzmU+6SiLQ0ASx8s4xuKhhLY4 nB4in9LhT3DUe3fTjGy2yt+1854Kq/9FxBhZopxl7DwltNZs7YyUj92NmkQz9TFPS+hdpc01lFDB Wuygy5Q+lrw9v9qHu8xo2Gfo+q/UjQ1mKgpR91ljrLWzdfegv5TNYfjGNGbdUmKm3xBs/4536jHt No9gcp3V2Pq1s08j3N/W0dp7U5MrEvxGKlrWUvNcVdXZ/2paioWJqTomWNw76tFyo9mE1jkdUY/p kMXbzkWZar/juSKFek7XLT/th4xO/5sAoxZ1Hc+sbvfIlxAbZXEITOxMhcIb+BwOe+MU3+IoHXK2 PnUZdlsGuRsqm6lRec+/XJa271xj/AnlSm2Wtzapr5lLhJxv4Y/aNlVWPFLh/e/0x1aMY01FnFx/ meLsjA3q7vxbRc1Ox8DNQGg2t79z5tT6k5WfWD1j9Fuy4dI+nVsOi/FYn6bvOdZYv3skpw1UML91 ui6vK2Lxpc1VL3f0/rRMgkYTMhWrjolTynuvP2M11v212dyKvphpp+fGHgyrnDfIvf5YVY7K27po efelwT6FyuXe1W49VuPRkS8KPcriEJj0aqX31Jd3WMqmdrNhOJHOu51RZ6nVZ7by5DU2Hh10Z6sL ClksIoQQKlg+qOsYZHt08/xIwyH1uJq87870vhtCbxj2hbEnuzxK/0V5W1P3v63WlieK2v6lVGfI ZXoR4Xm+02Uvt9rqu1Y2YfRjt1UmadS6ZmdH978FV9uzleJfx4TNkzJWl3Vfc/3bbfaR7lis1qb7 T7THySVit/1031UBGVa5KljGTsmqU6m1mazhSPfHpdS1t7Z0Xx2rYHtWJGcuiM98OAjLfpzXhAKD xXuBBydXZw+2S+eyNCpxp8lFiNtqyPOErvXzZIlad4G4bbubUI/hzdqOWfH66JG0kVEWh8DEybQ5 4sbTLkIFa6FVWKWdwo2GUWap2G+MAiWe/U2NJ7QxmX1GqfmSptNPtboGP9FmON36CNWBOoudkPaO qgc45rHYoAFbilDbWf9cm+T+5PDoPo/ze6orDkvDfxiijfcx7Ow5XN/ovfE9K1Zn+14FFuEPxoFK G3N/uPX3zfae8VJKhCarsclqHO+3lmnCrlR0/Nt2tres3dT4aHGfYQSWIZSS4fU1ihIVbJXNxQvu auvADkMmOjR6rWSKVh0jDv5hcGN+q6v3mSmlgpXv2SmxdgHd5+c5wXzI5O39ZaI06sHXIgjSaGYy phJKqGA+aOLX6P0sMMZqrw9T7qm3OgltaD99q7ExRS5WdN9ZJysy8abB15AdZfFR4K0Nt+c3DPHq jPKn6ak/7DPl0bOt4vjzxj7rxnedIlLTi8fzX+pVeGFC9mP6KT0h7XzFKJcFST5tdgnEU2CyerTq YccTWl5fvKZ+iFdPjE77R4R8jBKleHmo/h1jWyshLlvTA6ccV4eHzFdIlIRvtVsPtrV8bXG5iXiu RnTCNEhfAxMfnvBz86kXjB6BCKdbK283qS/R63OU0hARK/DuRrs1r7N9j9VNlDEDC7vc1i2tFVsb xElq3UKNKkUuDRFxHHW32K3721q2W9weQghhM8JDs7HUC0wg0dzYlCfY0082mg0TvQdR3JAQc7K0 Js/jO95xYt1PQ4S3Gk3DG/vlcqLjc+oqPvGVkpSqyN9HqRVTt+rYeTGJP3VWvGFy8wSmJ5fVmNd1 eBFlqxWDpxJWop4nZUoclHTd6kPnp/UyiREzf2sv+0uH002I22M/ae5ZPIZVhA65DNsoi587Sugw ZpAMXJiTCpT6ux9Q35XXmfNpadbzDJOm10e3NNVS0mwwlsaoM4bdTCilQ+7PPWP6w6l00b8Ltz7S bHcSYncY3qs2vNd3U0uJmHmPrPGnJvug31h6eeIs/kzFK51OFyFOp3lLo3nLgGcNEtOo4C43tpYb W31u7jHBMx4K83fpDHrjYbyI50envJ0243qdXOdnG2ZYUYI6+Mb4pIdDx3DklEjkYU+kJf1YK+t3 YGMYLl4X9WRa4hWyEazLx3Dqu2Yl/0QjkfR5KfGskPgXkqPSuSlddQyn/FFKxiszo7+nVcaIOQmD 1f+mGVpmMLR3/daqeaqhfl5GMU/dNUrUM1PQzzOll85Mf21m1CqNPIxjR9xLMMriEJBEypDvKRiG EMHZucs6xacniy+InfW3uOBZ4v5HE4lYtW5G6vMxas1wXoaVr0vMeG1m5EUK0cCFHRhWkq6PeiQh NGpAscyw6B/q1fFi3wsiKmTa6xJSX03QR/jdJfj+Q0NDQ2lpKZoijA1BcFVYrGecrk6ed1FWynFq kThSKk+QS3Xjefphd1mPW2w1To+LYbUSWbJanSIecu1Q56elRS+be04Spdenzr5LxRBC263GfJuj lSdKsTxNrU6RTMQypJNVdQAAE8/QXrH+jMFCiD4k+d0ZWvmU/8BUcFdazCUOl5EnHCeKVqiylbJz uoEOtThtJ632epfbSomUFYfJFelKRdgQ/QuCwWGvsDvqXW6LIAiE00ik8QpVulw01HQkhD+APvyF PwAAGGeC5bXi0o8dlHDa381OXitGjYwTdB4AAADAVMCqrovUqAihvOnTVhsmK49fRaMKAAAAYEoI 1sf8UMkyhJ5uadqLWzmMF9/DWc+SZ1E1AAAAANMPev4AAAAAAggu+ADoAxd8AADA9IbwBwAAABBA fIc/Sulvf/tb1A4AAADANOM7/JlMJp+Pq9VqVBkAAADA+QsXfAAAAAAEEIQ/AAAAgACC8AcAAAAQ QBD+AAAAAAIIwh8AAABAAEH4AwAAAAggCH8AAAAAAQThDwAAACCAIPwBAAAABBCEPwAAAIAAgvAH AAAAEEAQ/gAAAAACCMIfAAAAQABB+AMAAAAIIAh/AAAAAAEE4Q8AAAAggCD8AQAAAAQQhD8AAACA AILwBwAAABBAEP4AAAAAAgjCHwAAAEAAQfgDAAAACCAIfwAAAAABBOEPAAAAIIAg/AEAAAAEEIQ/ AAAAgACC8AcAAAAQQBD+AAAAAAIIwh8AAABAAEH4AwAAAAggCH8AAAAAAQThDwAAACCAIPwBAAAA BBCEPwAAAIAAgvAHAAAAEEAQ/gAAAAACCMIfAAAAQABB+AMAAAAIIAh/AAAAAAEE4Q8AAAAggCD8 AQAAAAQQBlUwiebPn+/zcY7jUDkAAAAwHkSogknEMAjfAAAAMKEQPiZTcXGxz8eVSiUqBwAAAMYD ev4mE8v6nnOJYV8AAAAYJwh/k8lfyEP4AwAAgHGC8DeZEP4AAABggiH8TSaEPwAAAJhgCH+TCeEP AAAAJhjC32Tyd8GHv8cBAAAARgnhbzIh/AEAAMAEQ/ibTP4WeUb4AwAAgHGC8DeZ0PMHAAAAEwzh bzL56/nDbd8AAABgnCD8TSb0/AEAAMAEQ/ibTOj5AwAAgAmG8DeZEP4AAABggmF4EQAAACCAoOdv MqHnDwAAACYYev4AAAAAAgh6/iYTev4AAABggqHnDwAAACCAoOdvMuXn56MSAAAAYCIh/E2ylJQU VAIAAABMGAz7AgAAAAQQhD8AAACAAILwBwAAABBAEP4AAAAAAggu+AAAABh3nmOv3P7HbZ1C/8dZ /drH3tiQJRrf4gC9ob1MA0LNJ7/59cZKnhBGvvzBd3+7SOzrWXzR63c8/FWrQAgb+YOnX7k1lZvC 36jp8wd//lZ51A+f+/tNiVP4c44D95EX1j+5y0YZxco/bLz3QrG/5/Hl//nl/Zvq+bOPsLpLH3nj VzmSs494jr/2s0e3tPc6WLDaVY++/ct52OwDtdnAmKKGHY/f8VKegxJCCCNKv+3Vp9aFT9/hNPeB v9zwzD4XJYRL/slLz14bM/yv6s77+82Pf2uhw32+KOOnrz555TSuy8mHowCMmmA5vfuzTdsOFFW1 WokybGbm4tXX/mB5ggob7sT+DKaiwtN8ztlQz1cXFhkEVAzA+KDW43nFzu5AQ/mKvILOK9YE+93x sRE5V16rtvUkoPbCrd+VWYa9iY6y+PmEYWVyKe5zNa4Q/mB03PXf/u1Pr+xrcnftkgz1J/d+Unxo b+6GR++5NAY9EEOgbrdHLB5WNXncbk4sHmSHKLSeOFEvpMax3f8sKmrgUcVoNoM3GzhnjqK8Ew5K CMOyDBUE6i7NPWZefYnWX22zEQuuuWlBzz/5Etfe78osw367URafVAzDiUVDtliB9/ACJYSRzl6Y o0GjHU9uhD8YDWfJB0+/sq/JTbig1BWrl6WFsh0le7ftOtXRtO/VZ8Jinrs5VTr0iwgNm//6Vuvi W65fHCP3v727m/M/fXsbc8391ydPm0hJTQf+/pt/W5euv+XaJfFKvx0GgrV6/6Z3Nu5T3vzX3ywZ ZJco1BQWdV4T5+15oOaThaeR/aajMW42cI5cxbmFVoEQRpa9JLNy/xGT4DyZe9x28TIlKrs/Uc4v //3pLwd/jiP/5bse/6aDEkY+56JFQRg5Gs99iGEfwh+MqgF9sqXGTdnQ5fc9fe+yUI4QQi5bu2r+ Sw/+ZWdTzZaP9lzx6GX6oXaE9oLPNu0/0r6vYP+8q39253UXRkj6P8PTXvjFG//8+ECdnVGR/Wse WKGdHjtXd8WXH+5vaeI/fe7Yt/+77IZbb1iVFtTvKXznqW8+ePuD7aUGnjLch1+uu/Am/9mXesoL i2xrL1IxhBBnyfESN50W9QTj2mzgHH+H0rwCo0AII0q+8IdLZHm5B+3UcSKvyLFsgRy1M2LUkr/z oEEghLDqC1YswNnKeBIadm5GuIZz5ywuOGmnjDj96puXhPZMNWP1C2/+4RwpQx0n807Yhn4V+bzb n3jwhsUx4tajHz35q1/9+eOjrWdDC9958ovn7/3F//1nf70QNu/qe5785fJpkvwIoTanNDJCxjKE 8oaSba/9fsOvn/kkt8nZXbtNuZ888+sNv39tW4mBp4RhZRERUqfNV55j1Vo1SwihzlOFpW5CCCGe isIim9Drb4BmA2OIr8w72iEQQtgZ2dkxWXNSRAwhgvVYbrELlXMOzdpwaEeeRSCEsNoFK+YpUCPj 2nZ3bK9Ezx+cM8HS2eGihNHPnKHvEy8YdcLMMDa/xt3WZhCIcqjowcijF97w4PzVJ7/+8N8fbT/0 7mOFu2fH2gVCTQVv/W7LySorUc5YccstP758brhkOtUfo5193UMvX1qy/eP/fPTNyXa3YKvZv/Hp /d4/UtuBN54+0PVEcXD6Zdf/5PrL0oJ8X/rMhKSmKfOONPGCqejYaT4nleNrj5/wHplUs9JiCw+d HGJauLP5xJ5vdx8+VnK6vtVocwoiuSY4Mj4pPWfxJSsXJGgGv+JasNbk7dq5P7+oorqxzWhzCqxY KlfpgsMiYxISU1KzcuZnxKi48ShOHa1lx44eP1lcerquobGl02JzuHgikqk0+rDo+OTM+UsvWpIR LhvkdMHdenz7/7Z8l1ta12Z0cprIxOwla69etyRecvTFWx7fYequNvHcn7/5xzU6ZgpU3dg1GxgF viovv0UghHARWXMiuSCSPYMtLOcFY0FemSdnNo6sIyO07N153EEJIWzokpVZMtTIOHKX7tnfyKOJ go8N0VB14nS7p2v9Av3MzASdrwDHSGVShiHUajK7Cel9fBGMJjMlhJXKhr8Ri/QZ3//5Myu/v/+z f2/8Mr/UQQkxlBdZQ7OuuP3m61cmTdfeKy4odc2dT61cl7/5/Y2f7j1j5vt00TCsKn7JVetvvPKC qEFrkotLTzuV12QShNai4/VCakzbiRP1AiGEESenJ3kKDw1Slm/Lf//Ff3xe2NZ7kJi3djZUdDZU HNv71QdxF9386zvWJPmeyORpOvDOX1/dXGbs/cF5p83ttJnaG86cyt+75eO3g9b86c2fZ4vGtrjQ suuFR17b22QX+vdquWzGNpuxra68cP/WD9/Nuvae+36U7WsGkdCR+9aTL3xVYel5hY6aE7tqivbv zr37D0uG8eNNXtWNTbOBc99H1h89Ws8TQlht5pwZHGEjs7MiuPJ6XmgvyK3kZ89C3h5Rddbu3nnK QwkhXOTSlWmYojCe+IoDh1sE3OEDfDWOsv/++U/dntxU7OeyAUaRmBLDEmrL37Gv92JyQvu+bYeM AmHDUpJ1I2thjCImY15OWqTcW4yRhKXMnZ8ZP+3HLaUROetuveOaOTq2T0xgNZlX3XH71cM4hMtS 0pJFDCFEqCk80SlYi49X8pQQwsalpQ5We56GHc8+8MSmY23+pgdSwVa967WHH91Y5GONLmo4/Mqj z/6v1MgPPqpIqc+Ox9EVp7ammpaBya/fkzzthR899eSnp90D/mQv/fDJ5/5XbhnwCtTV8N3Lz246 4xn8pSe16sao2cA5EloKcqsEQgijmD0nRUwI4WbMydSxhBCh+WheNa60GhFPxa5d1TwlhHBxF60I sKVdJxpfU1DYKuD2bjAaXNzFq2crGMGc+68/vbytqMnq9tiai7a++MfXDhsFRpb6vVVJ/TZj3nD6 wGf/+NNftzb6OKQ5Go589PSvNjz0+q5aViFnCSNVilsPvPN/v/jFnzburbZN2xXrqK3mwPt/vnvD Q//O7+ybRARj4bt/2PDLJzbuq7YO/vWpOi0tjiWEUE/F8ROdpwpLXJQQwganpkf4H/R0lLz/zGsH W/t3G7Fs3zBBqK38s2df3df/3gLuU5++ubOpV2mGU4TNSJ2dnT171syoIBk7+OzMURbvh+Hk2pCI mPiEGbFhKnHvstRe/unG3R19P7y7fNPLmyrs/nKbs6qkctB5cpNbdWPVbODcCJ1Hcyt5SggjmTUn 3ZuxxSlzMhQMIYSvO5rfgHofAdfJHXsaeUIII0q6aHksUsm4tl1D8cl6nmCdPxgVNnz1htsL/vDK kfaqHa88tOOVnj8wnP6C2+7+XlT3Zkydraf2f7N1644DZe1uyohTDly/+pqz68ML5orvPn7n3S0n 2jycPuOKDT+7uP3V375THr724QeS89964/Ojnzx3bPuXl/3o1htWp0+r+Uvu1sItH/zn010VBm8O YOQRkYq2xnYPZUTBkSG2xiY7tTcc+eTZ/G+SVl73kxvWZof6GRFhI9NT9WxFq0Cdp45u1p6yCIQQ RpaSPpMz+3lzvvrLf31R5erJDawqefXNt/5gaVq4knF2VB/f9dFbHx5s6FrDVujcv/GTtRfeMfvs 2j18+cFDLT0HOUaefNX9v78pJ6TnA/KWxlO5e3Z+/fWeBp9vP7riXZ9ZHp6+YOmSRQvmpCVE6qTd Sxzam45uevFvnxZ1zdmj9uO7D3devLZn+V1qPvTZ1tpeXXsMq0q+7MZrL0pU26sP/ve9zScNg/bI TXLVjV2zgXNBTQW5pR5KCMMlzsnsvi5VljEnVbI3z0mFM3kFLdfERiDEDI/t6M6DHd5JKukrl6Ha xhdfVVktEILwB6PERV32wNOaD15948tjLU5v/wMjDZ9z+e0bfrwwQkSIYKsv2LV127ZdeTVmnjJi fdKyS9auXbU04+yNexynPnj4iY/KzZTVpqy9+a71FyeqSNPnxPtSUQvXP5q9Yt+H/3zrfye2/fOh PVu/97unfpajnhYX/ArtO566+6V8bwcTw6oTLrr+tvWXOjbe9uQuDyGSrNv+tl62Y+NbH+0+YxZ4 Y/mONx49UHD3Px651PcdBLiZGbNkm1ttVDAd3LzLLXgfS58lY/J8v73z+OatlT1DlgwXe8VDj982 W+GtWpk+4cJr7o9XPX7vq/ld9xAQWnZvy79p9uKe6/AczY29utNE6d+7bl5I74zBqSJnr7x+9sp1 1xVVcQM/8yiLE0adcdXvXpi/IEE94HSAlUfMv/GudUe9Nz0khFBPeXGZe+2irvhFzXm7j/bqFGPE 8Vc98vgtaXJCCEnNmJOi+cOD75XY/ca/Sa26sW02MHLUWph3ytuzHpOdHcL2NMjM7CQu/6SH8hW5 BZ2Xr0WND6s2DYe/PWzynqtmrVgcgkobV0J7bZ0N4Q/GhCh8wfo/XnBt6+ny6jYrlYfEJSeGK1iP 4fSBb7du/XrPiWa7QFhFRNbq1WvXXrxgpq7/oVoalzJDoeIX3HjXzatnaVlCCOkzZsLIY5fd+njO iu/efe2d/brkhGmzgiqrX3DZBRsLdhu44IzVP771R5cka1jiPnL2CeKQrCvvfX7F5d9++Pb7X59s 53UXXLZA72/fyMhmZcwU7S9yU8Fp9677wUWmpwb5qy33qYOHzw5GMtI5V12doej7ZDZ8xeUL3yvY 0XWPOMF6PP+Ue3FOd0phmd5P5yv3765d8v24gfPMZJGzU319/dEVJ2xw1srFg9RuSEgwS7rCH6HO hoY2gUR7a89ddrzEeTbasdolP7o29ezabOKEdTddvP3Rzc3CVKy6sW02MHKO43ldF6aGZGfHcr2a XHZWLHvyDE89pbkFpjWX6rBW3ZCEtgPfFtgpIYRVzlu5cNos5DVV0bbmNu9OCeEPBhJfeO+HX9w7 oiKsPDQpKzSJEOpsLd717ratOw6Ud7gpI9IlLFq7ds3qZVmRCj/HH0Y57/YX/ilRKQcbz2UUCSvv +POCGx0y5fQ5jDHqhTfcck2UdMVVi2L93tuE1SRfdseTS9ce/Pw750ULB+nzZINS0yLZopqeueas alZaHEd8L7Uo1J8qNZ0NN2xcZoaP/a44ekYkS7pvECyYq6pahJyuBEUkEVEhLOmevSkY8l6/7xf7 L1p96bIF8zLidEPeUWyUxbt2ZfamokN7DxcUl1fVN7cZzXanRxCojy47auo0URLtfa+Wqpre/X6K 7EVzVX3eT5q2eL5+6+Y2YSpW3dg2GxgpZ3FeoXcJTU3mnD6zmrnY7MyQj840C9RZnHfceslyFep9 CELD7m+L3ZQQwmouWDkfFTbuFW4yWbrW8UBlwBg1Klt9wa6tW7ftyq8x84SVhWVcumrNmksWpeiH nG7EyFXK4bwFq1BOs7U/2aiV628YxvMYeeziG9YP8SQuLn2Wmq3pzhuMKCk9yW/d800NvTu2+LJ3 7rrqnaE+Bu1o7ejpPiNc4qKFEV/+9+z9g6mrtWj7u0Xb32OlutiUjNlz5i1csjgzyk/qH2VxQhzV O9968e3tFUNdMOvlcvVM0RM6Wjto7x8hIb7/XQhFcTPjOeI7/E1+1Y1ps4GRcZfmHvOOUkrT56T2 3cC4pLmZmq+aDQJ1nMg74Vi+CLf6GBx/+rvvTnsoIYTVL7x4Dqpr/Juv09m1v0T4g9HyGCoPf7tt 69d7iprtAuHUcRdcuXrN6hXzYlUsEcwVO//z2dcHiqparUQZNjNryeprrlqeoBqP3ju+5P3f/+07 g4/jNSNbsOH52+dM+8YuSslIFu/I7RrQZOPTZ/nt8aE2k3nkN3+jTrujVyHxrGt/turIU9vq+70S FZyd1Sf2VZ/Yt+W9N+OWXH/Xz67M8LHmz6iK83Vbnn749aPGYV9V2WvNFGq3957Px6q1A+4lxSg0 ajFDfFXRVKg6mDR8Za73xh6MKGXu7H6j/USSOjdd9u0BGxWshXnFrkU502pZ+jHnPrVzdx1PCCFs 2JKVGaisiYTwNx0wI1uyh2GYsTqcUNOBv9/7112tbspIgmddtG7NmsuWpIVKvXtEd+325x977UBz 9/HNUH9yz8fFB/ccvvPh+1bFDdYfyOoX/fSRWKssMmoEH5S6jC1NTR2+wp+8036+3N6KDZ+z+nsK FyGSlPCR/kqMMvt7P/5BtHc6GiNNXhjFEuLni/P8uSxFJvR9OUadc8cTD+v+8epn+U1OX29EBWv1 3rcfPdP00NN35gxMWOdcXGjf+eZ/CvolP4ZTBMfERYVolFIRQwjfWpJb3uF74Fbo8zDLEMbHVuKv EqZC1Y1ls4ER4KtyC1q7JnJWbnr07v/1f4LL6F1SUjAW5JW6czJxmbV/9oId+7yVycUsW5GCNDIB xFIp5z2rRXVPBxw3sv29SDRWxwdGNSMhNspwwSVrVl98Qd9bWTmK333m1QPNHiIOnn3x6iUpwaSz fP+2b0+2NR147emQqL/ePnuQPn5JeMrc8MD8LeNX3nrnynMszAbn/OCWnGE9VSLtc5rNKsPjwhRD TriRhfYfiOSC597w6Ctryg/u2rU/r7C4rN7o6r9qMnXXbXvt/UUv3ZU98IqGcysutB3cdbx3nmck sSvuvPe2i5O0PU2QmnY8dqvv8MdIpFKG9HTEUavFKpC+vdHUabH4696bIlU3ds0Ghk2oz8+v77qC nLc011gGeWrH0dxKPjMVKxb7Qc25Ow8bBUIIw81cviIBFTURWI1GxRAHJRThbzqQyrr62ojPue7d 21rPuJdUKh2rebVs1Lo/vrTOx5t17vtkW62HcFGrHnx6wwXekavL1q5e+K8/PLmlpn7r+9u//8SV Y7uikyhrwzufb0BrGBZGpgtSnr0egXCzrnv8/1ad66V2oqDkZVcnL7uaEI+loeJEYd6R/XsOFDWf vf2G0Lp35/Fbsy+Ujk1xvqq8z/032Ig1v/jlZX0nOFKLyexnTJgJ0usYYuz+p9BQU8eTvh1mQn11 HX8eVB1MKKH5aF7NcGcaCC1H86puTsX9KvxUT8f+b4/aKCGEEaUuvygaHdYTggkJD2FJm4Cev2mB VahVHEM8lFDB7fYQ4nOkgbpcnu7na8b9oip3SeEpB2Ukc67+8fyzc5ZY7dwbr7/gu+cO2EpzC41X RATh2q5JazQx8TG9Egxfc6bGQ0Y/RiVSRaUuikpdtPaG9Udee+jP3zR0TS4WbFWnm4QL49mxKE6d ZrOrd7+fLGV2cv+P7qw+4+82C1xEXLSEqe7uOhRMhXklrpzMXv15/Jkj+S3CeVV1MP68nXneRV6+ //jrd2b6PH7yJW///MH/NgqErz96tP7HiXF+fzmO67qTC+9xn8PHGWXxSa7Lpj07i5yUEMJIZ1+0 NBTNe2KwwbExCrbEhHv7Tg+S4JCuFaWoodPPFHhqN3R414VlZaEhg4c/obMi7/Ahr8O55Z0jv1UR tZnNbkoYdURU3+lKjDwqOpglVDB2GHAHpEndB8zOjDnbJyF07Nu8v5MO9ovWHNpV2N7nNxM8Hr+/ IafPWb2019k8tVv7z7s85+IMJxL1naVH+/d4U0vBgWN+788mm5WRKDr7AkLLro+3n73ylghtuz/6 po6fwlUHk4GaCvLKPJQQwigyspL89ZxwiVmZXeuVVuUWtPjfzTEqrbqrhXR0WEf8E4+y+OTiq7/b We6mhBBGnr1iEdahnDDcjETviSSqfDpg45ISvAO5/Jkjea2+9jbUkHe4lKeEEIabkThj8JEIvvx/ zz3V7dnPT418fjsjV6nEDKHmpgZTn70SdTQ2tguEMCqNBt1+k7oPiF++IunsinKC8dBrT7y+t2bA LZSpo+Xkzg9e+O2Ge575/FSfKU5C546nf/XYOztOtjh8XRRrrqvttaAKI1f1W5NuFMUlYWH63jfv dRTnneid9Kil6KP395v8HnbZkIVL0yRnX4Hajr/9+AtfHm8wWs1NRV+//Ng/jwx2GfGkVx1MBmo9 llvsooQQRjwrK83/LExxWnaajCGEUL4y92jnIM0wLlbNEkIoX5p/3DLS+DbK4pPKXfrtd7Xey3zV 81deiKWdJw6rS8+I5giGfacHRjl36VzlkQMWgTqL3//bRwm/vz5D0yvXU2v55397+0jX7V7Tl10Y NO6hXzxr9izp3gLnsc/eP3rhhpyukV9qPv7hR4dtlOHi5swOwpnH5O4Eolb/6JKtj3/dLHQPL5Zv fu5Xu/6TlJY6M1In53ibxdhWV1l2utHippQQwun6v4TgaMj77MX8z98IT5+XMzstZUZUsE4tZ12m lqoTezdvPWLpOe6x6sSkSHasinMJczO1XzX3HFaF9m9feib4zltWZ0dIbU2lB/+38f2dNZ5BjoZs 6IprVnxW9HVPtwx11e954+E9b5wvVQcTz348t8ib1dmErNmDnbvKZ89NER085qbeW32s9XerD3Ha grnqnbuMgmA9vPGNPUm/uChyJKudjLL4JHIc37nPu+2x2gUr5ynPj089TXBxc7NDP65uQvibFhjt 4huu+argPyV2KlhOfvjwzw/NX7pw9owwjcRjaastPrz3cEWnd7hCPOOKm1ZOwPwKNnj5NZd8fnxL Q8M3T/2m4eLVi2fp2Y7yA9u/Pd7spmzw8utXxeF4NtmtRjnvJ7+6suSxL6p61hqhgq25LL+5bESv QwVbU9G+zUX7Nvt9Jy764lVZkrErLsu+fE3C7g977q9LhY6CD/9c8GHvQizHUF7wlwAVc9ZvWH3y qW11Pq/pZbjw2EhTbZ2/4dYpUnUwgZw93ctcZNbssMF2X4w2M3sGe6ycJ9R1Kq/QeslFfubZKHKu ujLxwLvlTso37Xr+lwUfJ8aFKLomJIgyrnvwuoxBj9CjLD4KQuV7v7rugyH660TJ61946qqBy3VR S/7OA95ZP2zokpVZMjSuCcUlLV4Q9tUXCH/ThCj+Bw/+zvDk8/+rsAiUN505vOXM4QG7JHn8qrsf umHWxFw3qMi6+YHbmh97K7+99cTX7574uvtDcEFz1j9050Lc9nIKYFSZt/zpIfFfXvi02CCM27AR q0r/8a+vTxWPZXHRzGvvuaX0kTcLfH9uhtPPX38J/94nR/3OhGc0OXc8+mv3k//YWW3vt14gq8m4 6b7L65/8S6/wx/ZbTum8qDoYO+6S3AJTV2dVRtYQE2fY8KzsSK68jifUcTzvuOOixX7WtRIlXP27 X9T+30u7G92Uug21JYba7j+JZZcOOSt6lMXPHRV4jzDUdCDB7fPeO9RwaEee9/aKXOTSlWlo3RNN PGv5ksivcBX6ZLrllluCg4PH6MUYedS8i5ckiy0NNXWdjv7L36riF62787f3XJM5nNsFCPWH/ru3 ynvYZETxS69ZEnsuDUUUNGvpijl6wWI0mqwOXqQKS5hzyfW/uPe25dFSRL9Roh2FW7YXm7tu5qHP Wrsqw8/EGUfFd1/mNnkbBCNLvOiqC3sPIjLyyOyVK+eFEWNLY7PR6WuJbFaii5u9aNW162+4NEUn OVuWESu1KhHD201Gs8PnICsj1iUtuWbD/RtWxct8/HFUxTndrCWLZtDGytNNlt6lGU4Ze+E1v37w jkXOg/89VN/9hRhZ0op1F/YdPmVV8QsuXZasJi6bxeZ0uniRKiwhc9nVd937s4ujWw58uqfK3fNJ EpZftyxe1G+Lm6yqgwnHl331xlclFkoII8+55rblcYNHFlZDqrfvrrBTQj1GWfr3FkT562dhVTMW XLwwVuKwWixWh9PDd1+7xMUuuXZp3FA73lEWHxmhdv+n+2uGPQWcDZ7zvVXp/cfHhZbtb7yV2yIQ QrgZl995Qxb6ASYcGxTqyke1T6Zdu3alpKSM+ct6zHWlxeU1Te1mh8BIlfqwuKT01HgdTrBgUIKt 5XR5RU1jq8HkcDMiiVSu0oVERMbEzYjUigfdU/C2trrq2obmlg6T1eZwC4xYptaFRsYlJc8MUwx9 tjGq4oK9pbK4uLKuzexk5drgyJmZmUl6yWh3bELjfx/4+dul3cc5NuzKJ//50wxuylUdAMCIUcMu hL/JNE7hDwCGJHTW14siYtU+Eh21nvjXbx/dXN89asVI59/9xiOX4ppEAJge3JjzBwCBiD/13n3P n4qbO3/+nMzkGTERIRqlVCTYO+vLcrd/+tne+rPzlRhRck6WGskPAKYLMcIfAAQo6m4vP/x1+eGv B30Wq118+XLcgQAAphGczU6mnJwcVAIAAABMJJzOAgAAAAQQ9PxNJlzwATBp3Ma68lPFp06VnCqv buk0mcxms9UhsFKFJig8JiE5I2fxiiVZEbizGgBMP9ixTSaEPwAAAJhguOBjkpWVlaESAAAAYMKg 528ymUwmn4+r1WpUDgAAAIwHXPABAAAAEEAQ/gAAAAACCMIfAAAAQABB+AMAAAAIIAh/AAAAAAEE 4Q8AAAAggCD8AQAAAAQQhD8AAACAAILwBwAAABBAEP4AAAAAAgjCHwAAAEAAQfgDAAAACCAIfwAA AAABBOEPAAAAIIAg/AEAAAAEEIQ/AAAAgACC8AcAAAAQQBD+AAAAAAIIwh8AAABAAEH4AwAAAAgg CH8AAAAAAQThDwAAACCAIPwBAAAABBCEPwAAAIAAgvAHAAAAEEAQ/gAAAAACCMIfAAAAQABB+AMA AAAIIAh/AAAAAAEE4Q8AAAAggCD8AQAAAAQQhD8AAACAAILwBwAAABBAEP4AAAAAAgjCHwAAAEAA QfgDAAAACCAIfwAAAAABBOEPAAAAIIAg/AEAAAAEkP8H0uaWGluj1lgAAAAASUVORK5CYII= --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Note that in the other frame (displaying *Messages*), the mode-line-inactive face has inherited the underline from line-visited. (If I select that window, then the mode-line face has not, that is just in the current buffer.) So remapping a face that has inherited faces leads to side effects in other places... Anyway, what I was thinking of is a really simple solution: Have `face-remap-add-relative' loop over all children and remap them, too. (I haven't actually attempted to write something like that, though. =F0=9F= =98=80) --=20 (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no --=-=-=-- From unknown Tue Aug 19 05:12:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#53636: [External] : bug#53636: 29.0.50; face-remapping broken on master Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 02 Feb 2022 21:13:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 53636 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: Lars Ingebrigtsen , Eli Zaretskii Cc: "53636@debbugs.gnu.org" <53636@debbugs.gnu.org>, "tsdh@gnu.org" Received: via spool by 53636-submit@debbugs.gnu.org id=B53636.16438363448275 (code B ref 53636); Wed, 02 Feb 2022 21:13:01 +0000 Received: (at 53636) by debbugs.gnu.org; 2 Feb 2022 21:12:24 +0000 Received: from localhost ([127.0.0.1]:53785 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nFMvQ-00029P-80 for submit@debbugs.gnu.org; Wed, 02 Feb 2022 16:12:24 -0500 Received: from mx0b-00069f02.pphosted.com ([205.220.177.32]:14042) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nFMvL-00029E-78 for 53636@debbugs.gnu.org; Wed, 02 Feb 2022 16:12:22 -0500 Received: from pps.filterd (m0246631.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 212KwYaS003700; Wed, 2 Feb 2022 21:12:18 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=corp-2021-07-09; bh=1EyWbEytEjBQ2blxcz5O7fnz7vIaGIrg969cERqKHno=; b=u378U7hIDLMWWAGLTAq/lmlXYq7lKMUWIrYV1gq6AU10XJh4vknBwTPevI1Do5vKSNKC SMj7c6XpNmtMoatTodMRE2Vz8yRfqycNQOBSboTmapWnnMHtGI9bnrAcp2STmk3uqZ2B Vx6RELonthDakk387HdutJMFFTpjv5c8wDAWkuYB19X6LOyRrQVcapN8KwAIdMlMKUgS +GkWv/fQzPE+sdjwEokppg/OycF1pQNfSg91TxqnxNcSjYS8HiKFzxKzmRMyEsyUIZTL /+z2aWm7S9rrymMH46q+3vdUZOoDFDdnOHoKeZPlUb0WlVN06uXghPYoV2QcyqyrRz03 Ig== Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by mx0b-00069f02.pphosted.com with ESMTP id 3dxj9vffkb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 02 Feb 2022 21:12:18 +0000 Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1]) by aserp3030.oracle.com (8.16.1.2/8.16.1.2) with SMTP id 212LBkat099045; Wed, 2 Feb 2022 21:12:17 GMT Received: from nam02-bn1-obe.outbound.protection.outlook.com (mail-bn1nam07lp2046.outbound.protection.outlook.com [104.47.51.46]) by aserp3030.oracle.com with ESMTP id 3dvumj6wcm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 02 Feb 2022 21:12:17 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=juoilQpDL/IsP1mRhd00+w7XpPQoQjTGAudJsnNX45oU/1EFKw46Ike/sMJT0GfBeq975Eb0lha8tvOfDq9H8Sf5enYaNT0+/N2oiKyFJIDQ9FLrAwd85xBxeZsnEykMNtpBpTLVolwXOmfv5N95ZuC0un8d5Ok1HVW9Zija3gSZxZfBqFRS00TA0DJVckyVpaVcRTgLAYSLIZWlnzszUh06NxcrNxJMp3pEtRCUjCtP1YP7njKmj0pRfcQGb17VVxeL3iyEWgZOcvL4QLnOuB9qMh4fG7Kib6n3a+wPw0T/lqlNLPsru3BybKf/YovvQV6IiHiwOb5HYfukCBYrmw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=1EyWbEytEjBQ2blxcz5O7fnz7vIaGIrg969cERqKHno=; b=Nkw78EhQR4Cwk19KL9nRHV/S+c508plwjLcrPePHaPvcF7f88hNkSxqYhiGD6fVUhZq+thVl9geIEyLjUQuJ46IpYl2t+mOxgO6u/BId6WeEUES68c10+3if7mchNBELYx9bySJmjRzrKUQG/ALnH70Ar37JKv1l7rX98bocjIHqTAhwTRJvv2PaHZqe7ExZ1KXemjmYttlfcVGuWAfWEKisXa77k1eQVf4f8+RVJt+EkENTTEVe68KPlnesY0AnSpDt4CDRA4Ou1owwGNpWZwMC59boZQxNO0Y9vtOVmIpVyPCTmtKIsP3eDaZBezdRa1RQ89VdmmAQtHTKIWfNFw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1EyWbEytEjBQ2blxcz5O7fnz7vIaGIrg969cERqKHno=; b=u1sHMm1b6PrFCh1zMpfXSifk2x0FXSyTSP1qe6jwZSvSHCR6Jrc+VhIgJWs9bmYDcgkLUrE0nMMQyHJ6F8kfXQDNuOd39eV3n2L4eqMGNFk38z1CSNR2xgdc44u9xsWOqEURF0iQO5J5hpqDr4DVAusWDICGAUnZ7exGVdf57s4= Received: from SJ0PR10MB5488.namprd10.prod.outlook.com (2603:10b6:a03:37e::19) by BN6PR10MB1859.namprd10.prod.outlook.com (2603:10b6:404:fe::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4951.12; Wed, 2 Feb 2022 21:12:15 +0000 Received: from SJ0PR10MB5488.namprd10.prod.outlook.com ([fe80::99a4:696f:5f30:36b3]) by SJ0PR10MB5488.namprd10.prod.outlook.com ([fe80::99a4:696f:5f30:36b3%6]) with mapi id 15.20.4930.022; Wed, 2 Feb 2022 21:12:15 +0000 From: Drew Adams Thread-Topic: [External] : bug#53636: 29.0.50; face-remapping broken on master Thread-Index: AQHYGHR9mMsBy9qE2E6+IK4lN66oBqyAvaDg Date: Wed, 2 Feb 2022 21:12:15 +0000 Message-ID: References: <87o83tib13.fsf@gnu.org> <871r0p9l4f.fsf@gnus.org> <83ee4p9izg.fsf@gnu.org> <87mtjd8485.fsf@gnus.org> <83a6fd9glm.fsf@gnu.org> <835yq19dk1.fsf@gnu.org> <87czk97yt6.fsf@gnus.org> <8335l49jwu.fsf@gnu.org> <835ypz8zbm.fsf@gnu.org> <87fsp2v0ky.fsf@gnus.org> <83leyu73i8.fsf@gnu.org> <87k0edrvxm.fsf@gnus.org> <83sft15egx.fsf@gnu.org> <871r0loxr9.fsf@gnus.org> In-Reply-To: <871r0loxr9.fsf@gnus.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e0c56c64-88a9-4632-24c5-08d9e690aff5 x-ms-traffictypediagnostic: BN6PR10MB1859:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: KmpaNkpYcD0cWZeHwiZ+W5aEtUf0TKS6D677dwcJZotCk06+KhJHVtNvLjaxbMGo08MfgjRztIHziUXAsJMtxqWRORw+GXfEWpK0gcYwlO7ZSqvOP4F4DYrsXl1ScVrJDI33cieYSyVsFY2n42XXPG5Q7TPfUMy7uSp2mvlphxcirwShzqnoZYtt3tvg3upBqK7sOMDHopK0TNlr5JdOxoU7W3VEkAOPluoAWkEtqMYUYNL84liXCm3eY+0j7rDs9OP5bh1PEX8tinsh6DIaMTuoOfi3JBeKY45/EjVCC85ZBtgf6H761krIEfJYVPll4moxIH5Iiot32cKdo59T37tY9RjRVMNSmnVUm2NZ/zP+M+bOOxgUU8IxMbXtifupK3UuPcmtBVBKIA7xLrj+VvX6tQrEkumhzdXwqvOOAb8+AJM5QWX4BUbPoRizv+jN/HX5d9ahBxHQANuZITfKTq+Q063a4O3ES79baVXbTBCZfhtQMn1lRo5WHN3HX40KDWUSAf7Xb9887ggOnvB+QhNAHxIJZQ0fwRjS+S+sOvCbZ00JV9L/IPe1p6135KqCUyRbFo5t9n2mUuoXksGhqBVoy+yERf/QU1D/dThD9EnE5RmnJ3TanzIaTjCarA5VuVqXsyDZFpqAwokdnfFFpfcnABaQnRlnSumlIOy6+h14qkbY1hb66FAwntQF8vluM6SO1rdm9TBS6MWHwYygtQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SJ0PR10MB5488.namprd10.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(366004)(71200400001)(9686003)(8676002)(508600001)(8936002)(316002)(4326008)(6506007)(7696005)(110136005)(33656002)(55016003)(54906003)(64756008)(66446008)(66556008)(66476007)(76116006)(66946007)(52536014)(86362001)(2906002)(38100700002)(26005)(186003)(44832011)(5660300002)(38070700005)(122000001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: A0QGl3KyGCJOD8YHeqT7cJemyB6whN1HWT+goeXxUfFzrR53o+3I/Ur8hVW4C6qurruZb8a+WXtjw+eDvqUVZV0o3RlIi9yBfvYBkQ3jlDy3tGZD4oVDWMlLnjObNW0D0/HvgW5GSOYy2RK8v5ct3UrYvXbQC2PJ3X3LAxBb3AsbQHAkBzGtc8dIiQcGaQSs87Gf1HbhwOlnl+RCsmVmHwLY55BXdFNTa9BZKdhLLm6fSR6qdVNwJwdNlwXFvzYK4V/Tcq6Rrb3fhF6fqWREO9USjkW/CrkPKnarKhdGvKho2Fi/0Dh0VoZothrrCUYSf2vsM7NpXWDHOJxlAiWLr5FyqyCKrjOqAc2Kz6xwk0EauJVsQnVTit99kZ+QXEejC7QJJ55OgGC+fp7wOmokHa96//McrA83p/JVkb6Ta6xGbn7mj+oKe/P0UlQGFKTV8GMFRUHXZFmxnQol5sQRtgitQqilnlEIP/HIKGbSajvmGV5ermec4eZbfMjQuC9d1JqjUa1O2hVWyE45Ob0+hCgV0cFUWLNhnmNLS0ApG4tQy0J9p9J/LI1twi6F/0P4sTRfzPXEgINDje9fs0H92IztfelPi5SKPqX78bebFlQRx1hejKcoxUmbx8+d5Eii2tgfM0IMhCi0V7uiX9bY9HHN0bX5khQDOh8xNkAWwxCVuT4Lx+RwJnTaOdw8L/qLH3HhY/CiBv5is8kpjZ55zcjWbiAkdD9/LkqbPuSKoS0i/nEFAIwNwvxxfded+dcZOSYVN08Me9+sKvXeixqquiiSDBlBwXUS65pcUpvSf7fctBwpNwomOIhSxd/ZpzfzUzd/XpVI8pqO0F5410JgiE8yexkw/a7GuktHbEZpRFKlq2+48WTK1fmo2KZ1+M8a6K8PS+ZUQqAAcev+5eb52bUh03VG/n5VwgCVe8Jh/4H+my6vG0Tx2+pqlmHrdp29QlsoTbmrVOy2rOKk1+Ciz5DRsOAk9sEDX8x0ruZxzsoBxPAacbn9UBDJ11ktsoyfdOssABGZo5/vWNVEBDvpNElgfl7HaIg5zUxUFzeJgzDL27URNXhDhEzpSIc41mkKlJSkfCOmTxHLpIyX2e5qFkThVraeIljed3TeJ14W660yx9gA/CIHh4KfMahI3L3oRZXQKU/ZWU0FKnfWSyhkaFKMUGeP21uEImaPJldqKjKJCCDUcPfxY3BygaQbYAXOr4sLwhgN0eCWS+4kwOTGUfB2c5CWTFkWBd1AtVZajvjYlIDrmQC+oxRv2bDfoSvCenMilHD3tbRjDPnxrb+4TM3oSnKBHAcF80HYY950GJythC84PlgOELwpBL4s8N68itDnWIEJpdD422znwArInRkqP3DTuRpxv8hrTtnsOUZcepO7zF5OPpaN2JugqmQ36jgKnyWvc/QDfLgdBYMTlTXYVb2mx7x/cIO16HpNeNzAmHygJVAYmUrBRDwRq2W448vvgjtI4LtpwvYosQXopZc1wGA3WK3axHO7ac31Kg+ANu24IuULhejor4cVMTuR6APHrNvme6VrE47zSdy34cu7gHGzBBYPxmRyURRt9wbaqfXz1Orvo+uY+L5e+OTuZB5n3VmFeN61+EkaJYu97w== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SJ0PR10MB5488.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: e0c56c64-88a9-4632-24c5-08d9e690aff5 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Feb 2022 21:12:15.0456 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: BSpDDcls0KhBJQDchtAZJEW26G1pS7cHmoKzambEjlf68p9T6K17cF30iPAawZbLyuz17khF1OXSxeoqvRDPPw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR10MB1859 X-Proofpoint-Virus-Version: vendor=nai engine=6300 definitions=10246 signatures=673430 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 malwarescore=0 phishscore=0 mlxscore=0 adultscore=0 suspectscore=0 mlxlogscore=625 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2201110000 definitions=main-2202020116 X-Proofpoint-ORIG-GUID: 0LSJ3GWKTdV4iuC8xLM9vtF9uctb0T8G X-Proofpoint-GUID: 0LSJ3GWKTdV4iuC8xLM9vtF9uctb0T8G X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) =20 > >> OK, you want to change the header-line and mode-line-inactive faces so > >> that they no longer inherit from the mode-line face? > > > > Yes, I think this is the best way forward. Though it will be somewhat > > backward-incompatible, if someone customizes mode-line and expects > > header-line to follow suit. >=20 > I think this would break a lot more than the current situation does. > Lots of people expect these faces to inherit the way they do, and have > set up stuff based on that. FWIW, I think folks should _not_ depend on any such predefined inheritances. Emacs shouldn't encourage it and should instead warn against it. (I'm not a fan of such predefined inheritance.) > Programmatic remapping of the `mode-line' > face, on the other hand, is a much smaller issue, Why do you think it's a much smaller issue? > we can just say "use `mode-line-active' instead". You can "just say" anything you like. This bug report is the kind of thing you'll see, as a starter. FWIW, I'm not in favor of changing what used to be face `mode-line' to face `mode-line-active'. I don't think that should have been necessary. Let's see why it came to this... You said earlier: > The new mode-line-active face was supposed to > fix the decoupling of mode-line and header-line. The answer for how to decouple those should have been for header-line to _not_ inherit mode-line. Never should have had that inheritance in the first place, IMO. Face inheritance is over(ab)used. Shouldn't be done by `emacs -Q` itself. From unknown Tue Aug 19 05:12:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#53636: 29.0.50; face-remapping broken on master Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 03 Feb 2022 06:54:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 53636 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: Lars Ingebrigtsen Cc: 53636@debbugs.gnu.org, tsdh@gnu.org Received: via spool by 53636-submit@debbugs.gnu.org id=B53636.164387120821942 (code B ref 53636); Thu, 03 Feb 2022 06:54:02 +0000 Received: (at 53636) by debbugs.gnu.org; 3 Feb 2022 06:53:28 +0000 Received: from localhost ([127.0.0.1]:54240 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nFVzk-0005ho-Hk for submit@debbugs.gnu.org; Thu, 03 Feb 2022 01:53:28 -0500 Received: from eggs.gnu.org ([209.51.188.92]:58942) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nFVzh-0005hb-92 for 53636@debbugs.gnu.org; Thu, 03 Feb 2022 01:53:27 -0500 Received: from [2001:470:142:3::e] (port=56504 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nFVza-0003kw-1i; Thu, 03 Feb 2022 01:53:18 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=uoyZm/gvui68yYkOIGgzvTTDxTvlAnvZvKfrKq3p6zY=; b=D9WzqYhyxIxjJxdMoQaP vtolgrQpWfIDSDkgw7jadxQxd+bQMz8LVyYBNXa7Qpjvsev8mZvGnbAmRLwAQjxCy5KGTVgHZm5ih oBg+V1IEXANdg/9RjwTaSAgY4JuUgBR83dth3dqXU9Hzjk0VThuu7WqXc0egQpC33lPdR/7BMMEGb wtHyOtn9QfW842VyO2dsex+rIQzbZBlC84tG/BUg3v18VTiuGIvx9CBmBRrcyKjFTtJhuRi6RLlRF +AOC46zB8qH6YVPVZJoq8uRq+xj8XvWK15OVg0fI4b9Rr/Sj+SUqvlz3s9fbwraRuujmjR8gg5K9V HMs5RskfNvCjNw==; Received: from [87.69.77.57] (port=3418 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nFVzO-0007yZ-Gt; Thu, 03 Feb 2022 01:53:08 -0500 Date: Thu, 03 Feb 2022 08:53:10 +0200 Message-Id: <83mtj85tm1.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <871r0loxr9.fsf@gnus.org> (message from Lars Ingebrigtsen on Wed, 02 Feb 2022 20:48:42 +0100) References: <87o83tib13.fsf@gnu.org> <871r0p9l4f.fsf@gnus.org> <83ee4p9izg.fsf@gnu.org> <87mtjd8485.fsf@gnus.org> <83a6fd9glm.fsf@gnu.org> <835yq19dk1.fsf@gnu.org> <87czk97yt6.fsf@gnus.org> <8335l49jwu.fsf@gnu.org> <835ypz8zbm.fsf@gnu.org> <87fsp2v0ky.fsf@gnus.org> <83leyu73i8.fsf@gnu.org> <87k0edrvxm.fsf@gnus.org> <83sft15egx.fsf@gnu.org> <871r0loxr9.fsf@gnus.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen > Cc: 53636@debbugs.gnu.org, tsdh@gnu.org > Date: Wed, 02 Feb 2022 20:48:42 +0100 > > >> OK, you want to change the header-line and mode-line-inactive faces so > >> that they no longer inherit from the mode-line face? > > > > Yes, I think this is the best way forward. Though it will be somewhat > > backward-incompatible, if someone customizes mode-line and expects > > header-line to follow suit. > > I think this would break a lot more than the current situation does. Yes, it will. But if we want to break the link between mode-line and header-line, I see no better way. > Lots of people expect these faces to inherit the way they do, and have > set up stuff based on that. Programmatic remapping of the `mode-line' > face, on the other hand, is a much smaller issue, and we can just say > "use `mode-line-active' instead". That'd be fine with meas well,if it's acceptable. > Note that in the other frame (displaying *Messages*), the > mode-line-inactive face has inherited the underline from line-visited. > (If I select that window, then the mode-line face has not, that is just > in the current buffer.) So remapping a face that has inherited faces > leads to side effects in other places... When you remap a face, the faces that inherit from it are affected only on new frames, because when we create a frame, we recompute the set of the basic faces for it from scratch and thoroughly. That's exactly the other side of the issue which started this discussion: the inheriting faces on the original frame aren't affected by the remapping of the parent face, but those same faces on new frames are. > Anyway, what I was thinking of is a really simple solution: Have > `face-remap-add-relative' loop over all children and remap them, too. > (I haven't actually attempted to write something like that, though. 😀) Why not leave this to the (small number of) applications that want to do this? From unknown Tue Aug 19 05:12:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#53636: 29.0.50; face-remapping broken on master Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 03 Feb 2022 18:31:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 53636 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: Lars Ingebrigtsen Cc: 53636@debbugs.gnu.org, tsdh@gnu.org Received: via spool by 53636-submit@debbugs.gnu.org id=B53636.164391304831870 (code B ref 53636); Thu, 03 Feb 2022 18:31:01 +0000 Received: (at 53636) by debbugs.gnu.org; 3 Feb 2022 18:30:48 +0000 Received: from localhost ([127.0.0.1]:57713 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nFgsa-0008Hy-4r for submit@debbugs.gnu.org; Thu, 03 Feb 2022 13:30:48 -0500 Received: from eggs.gnu.org ([209.51.188.92]:35040) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nFgsZ-0008Hg-7f for 53636@debbugs.gnu.org; Thu, 03 Feb 2022 13:30:47 -0500 Received: from [2001:470:142:3::e] (port=36252 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nFgsT-0006Hz-SM; Thu, 03 Feb 2022 13:30:41 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=IjEdt1EMq2LdPpPgGa6iwF853zMOILoonmsaeptgtN0=; b=V8CzbrsDBHTn N2cD8QaPy1TkeSI5pgcJl7oAUwTPYcvc+gIvn/GHTmTcTNKkjbsf9pnFawpJ0I0+ab++htr47BXOd JleybAsvjF4VCKYW+aKVVV0xocRpfQKjQbXSLZUAzoM1xn0atEwQJTKEXYkDNboPEh6CQDMPamtkk b8C0nIsfUInPsh3skThwZ6k1kJYrJd9l1keOO1JSUv77jUMZJGZdKsYe2Xi73Q4Qgw9DIkuo7jJ29 yjjmy+UiC3lKbXSLNie3SKOTHg2dLhRjJNzNC6W3d2lHPAtav8OFLgIt1Wwr5puT8ZnMKjnCq8crA CaTN4n8fD2j5pOVFdMiHEw==; Received: from [87.69.77.57] (port=2751 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nFgsE-0001NT-Rl; Thu, 03 Feb 2022 13:30:40 -0500 Date: Thu, 03 Feb 2022 20:30:30 +0200 Message-Id: <835ypv4xbt.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <871r0loxr9.fsf@gnus.org> (message from Lars Ingebrigtsen on Wed, 02 Feb 2022 20:48:42 +0100) References: <87o83tib13.fsf@gnu.org> <871r0p9l4f.fsf@gnus.org> <83ee4p9izg.fsf@gnu.org> <87mtjd8485.fsf@gnus.org> <83a6fd9glm.fsf@gnu.org> <835yq19dk1.fsf@gnu.org> <87czk97yt6.fsf@gnus.org> <8335l49jwu.fsf@gnu.org> <835ypz8zbm.fsf@gnu.org> <87fsp2v0ky.fsf@gnus.org> <83leyu73i8.fsf@gnu.org> <87k0edrvxm.fsf@gnus.org> <83sft15egx.fsf@gnu.org> <871r0loxr9.fsf@gnus.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen > Cc: 53636@debbugs.gnu.org, tsdh@gnu.org > Date: Wed, 02 Feb 2022 20:48:42 +0100 > > Anyway, what I was thinking of is a really simple solution: Have > `face-remap-add-relative' loop over all children and remap them, too. That'd mean looping over all the known faces for each change in face-remapping-alist, wouldn't it? Because we don't track which faces inherit from a given face, we can only tell the reverse: from which faces a given face inherits. From unknown Tue Aug 19 05:12:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#53636: 29.0.50; face-remapping broken on master Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 03 Feb 2022 19:25:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 53636 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: Eli Zaretskii Cc: 53636@debbugs.gnu.org, tsdh@gnu.org Received: via spool by 53636-submit@debbugs.gnu.org id=B53636.164391625722233 (code B ref 53636); Thu, 03 Feb 2022 19:25:01 +0000 Received: (at 53636) by debbugs.gnu.org; 3 Feb 2022 19:24:17 +0000 Received: from localhost ([127.0.0.1]:57839 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nFhiL-0005mX-Hj for submit@debbugs.gnu.org; Thu, 03 Feb 2022 14:24:17 -0500 Received: from quimby.gnus.org ([95.216.78.240]:54036) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nFhiK-0005mJ-Cf for 53636@debbugs.gnu.org; Thu, 03 Feb 2022 14:24:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID :In-Reply-To:Date:References:Subject:Cc:To:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=/ABpL9GLi8Q7JOcGHDoJXTVgwoL6BYGNgVhWzyZPe6M=; b=JuqPSzPAIDrA3aDHeB0vTfQTDO QchLnUT+ON28pYLDERko+m39d2HsqgKlp5AfJ+/7Bi0y1n9YU0UzyFG7zyFK1CRPEGwZiBVl3A703 WWrR46rzoY3br08CXnLSCS9v/B4brcPXZ5O8h8U3Qez0sbnfI2Kq2joxay8tSWHFJczg=; Received: from [84.212.220.105] (helo=giant) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nFhiA-0003fO-Nw; Thu, 03 Feb 2022 20:24:09 +0100 From: Lars Ingebrigtsen References: <87o83tib13.fsf@gnu.org> <871r0p9l4f.fsf@gnus.org> <83ee4p9izg.fsf@gnu.org> <87mtjd8485.fsf@gnus.org> <83a6fd9glm.fsf@gnu.org> <835yq19dk1.fsf@gnu.org> <87czk97yt6.fsf@gnus.org> <8335l49jwu.fsf@gnu.org> <835ypz8zbm.fsf@gnu.org> <87fsp2v0ky.fsf@gnus.org> <83leyu73i8.fsf@gnu.org> <87k0edrvxm.fsf@gnus.org> <83sft15egx.fsf@gnu.org> <871r0loxr9.fsf@gnus.org> <83mtj85tm1.fsf@gnu.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAElBMVEXftaDTkHOeamBJ Nj+GeIP///9UTBKyAAAAAWJLR0QF+G/pxwAAAAd0SU1FB+YCAxI5JEmZsMQAAAGFSURBVDjLbZQN bsMgDIXN1gMAu8Cwd4DVzgGqJfc/055NkkJaS5Uqf/jvGUKU6YNb6VaZuRHs0ygR8QSWG8DNKGeA chiAbkSJjUo+MlEHtoFsRvUokSl1sGwPopWYhMOLzFHEPORPqCVB8eytUI9wsAr9VgAEwZ/cD4Bc q9E9gGnJpYjtpmKkVVpJYmgAh/2MA7S71BW+KncqTiv3kIjgMKrGLbpyEwDzEg4Uf84yDqquD7QF sNppBHfhWlrKtZXbj+gJWH2ukqhy8ol4BNCkhMh9wg4wW8nQD8d9yDoBNwch8BWUWGQdUlmsoxVx sGsygsQawJ4gVp5TrP4VIJVcge8iQekQV0bQsHMxe6q+Azhyqu/AXtVFkwmoLyjmuwI+zSYAhdk1 H/wH8J/YaB2oXtwH6MPzO8DjDCPQqfITaPfKDNhBXI+53e+AjBvOUyo8ppjd7+mYKvuj1iA6RcC+ /KH4Q7YLwODSk12BR+h0/gTzcAcQ4xcNLT4oS2J+F2G/VF9C/gEWf6lMTPjvrwAAACV0RVh0ZGF0 ZTpjcmVhdGUAMjAyMi0wMi0wM1QxODo1NzozNSswMDowMPeAsBUAAAAldEVYdGRhdGU6bW9kaWZ5 ADIwMjItMDItMDNUMTg6NTc6MzUrMDA6MDCG3QipAAAAAElFTkSuQmCC X-Now-Playing: Richard And Linda Thompson's _Pour Down Like Silver_: "Dimming Of The Day-Dargai" Date: Thu, 03 Feb 2022 20:24:03 +0100 In-Reply-To: <83mtj85tm1.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 03 Feb 2022 08:53:10 +0200") Message-ID: <87wnibn48c.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii writes: > When you remap a face, the faces that inherit from it are affected > only on new frames, because when we create a frame, we recompute the > set of the basic faces for it from scratch and thoroughly. [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: > When you remap a face, the faces that inherit from it are affected > only on new frames, because when we create a frame, we recompute the > set of the basic faces for it from scratch and thoroughly. That's > exactly the other side of the issue which started this discussion: the > inheriting faces on the original frame aren't affected by the > remapping of the parent face, but those same faces on new frames are. Right. There's two issues here, though, and I think both of them should be fixed (but I don't know how difficult it would be). 1) `face-map-add-relative' is supposed to be buffer-local. But the example shows that faces that inherit from remapped faces are affected in other (new) frames. (The remapped faces themselves are not affected.) 2) Remapping these base faces behave differently from other faces, and it'd be nice to fix that. >> Anyway, what I was thinking of is a really simple solution: Have >> `face-remap-add-relative' loop over all children and remap them, too. >> (I haven't actually attempted to write something like that, though. =F0= =9F=98=80) > > Why not leave this to the (small number of) applications that want to > do this? My feeling is that all users of face remapping would want this. Eli Zaretskii writes: >> Anyway, what I was thinking of is a really simple solution: Have >> `face-remap-add-relative' loop over all children and remap them, too. > > That'd mean looping over all the known faces for each change in > face-remapping-alist, wouldn't it? Because we don't track which faces > inherit from a given face, we can only tell the reverse: from which > faces a given face inherits. Yes, but the number of faces is pretty small, so doing this looping in `face-map-add-relative' would not impose a significant penalty overall. --=20 (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From unknown Tue Aug 19 05:12:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#53636: 29.0.50; face-remapping broken on master Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 03 Feb 2022 19:55:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 53636 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: Lars Ingebrigtsen Cc: 53636@debbugs.gnu.org, tsdh@gnu.org Received: via spool by 53636-submit@debbugs.gnu.org id=B53636.16439180431798 (code B ref 53636); Thu, 03 Feb 2022 19:55:02 +0000 Received: (at 53636) by debbugs.gnu.org; 3 Feb 2022 19:54:03 +0000 Received: from localhost ([127.0.0.1]:57948 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nFiB8-0000St-Pc for submit@debbugs.gnu.org; Thu, 03 Feb 2022 14:54:03 -0500 Received: from eggs.gnu.org ([209.51.188.92]:53614) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nFiB3-0000SD-F7 for 53636@debbugs.gnu.org; Thu, 03 Feb 2022 14:54:00 -0500 Received: from [2001:470:142:3::e] (port=37026 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nFiAw-0002lo-UD; Thu, 03 Feb 2022 14:53:51 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=IT9bdUx7hDhRixF2rJapRVha2lm1RBJnpiCMmvu7BrA=; b=Dh3AkFj47gDp 67DJ/f24MZFQX12RJ6OIzVbexdkNmkTmuVzbshspOoudbusftPmm5lSTn15qHSCyU3KioRr3e1rVX JwNOOBVkhtIk9QCBiFv8l8dSqr24jOcHzhFtoEU7qhmrlQ+iVfaUT6QMAjI1R/SmyQI56Sh40o241 R6i9nxT5zPP21rw9PYU/7RvrlULis5V2ppuVoYwIyUUe3X/nr+xhaFq2jqNLS25PhHki3nYLjFZeB Oj2j7NHjy+/5yg66UF+4VBcWN++tL80cuwFtRSLwZPJScczTmeZh93rMMV7OmiYBLZdLyqEQzb1qZ 8KSGOTXY+/lwWxZHX7B7yg==; Received: from [87.69.77.57] (port=3847 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nFiAu-0002qa-54; Thu, 03 Feb 2022 14:53:49 -0500 Date: Thu, 03 Feb 2022 21:53:53 +0200 Message-Id: <8335kz4tgu.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87wnibn48c.fsf@gnus.org> (message from Lars Ingebrigtsen on Thu, 03 Feb 2022 20:24:03 +0100) References: <87o83tib13.fsf@gnu.org> <871r0p9l4f.fsf@gnus.org> <83ee4p9izg.fsf@gnu.org> <87mtjd8485.fsf@gnus.org> <83a6fd9glm.fsf@gnu.org> <835yq19dk1.fsf@gnu.org> <87czk97yt6.fsf@gnus.org> <8335l49jwu.fsf@gnu.org> <835ypz8zbm.fsf@gnu.org> <87fsp2v0ky.fsf@gnus.org> <83leyu73i8.fsf@gnu.org> <87k0edrvxm.fsf@gnus.org> <83sft15egx.fsf@gnu.org> <871r0loxr9.fsf@gnus.org> <83mtj85tm1.fsf@gnu.org> <87wnibn48c.fsf@gnus.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen > Cc: 53636@debbugs.gnu.org, tsdh@gnu.org > Date: Thu, 03 Feb 2022 20:24:03 +0100 > > Eli Zaretskii writes: > > >> Anyway, what I was thinking of is a really simple solution: Have > >> `face-remap-add-relative' loop over all children and remap them, too. > > > > That'd mean looping over all the known faces for each change in > > face-remapping-alist, wouldn't it? Because we don't track which faces > > inherit from a given face, we can only tell the reverse: from which > > faces a given face inherits. > > Yes, but the number of faces is pretty small No, it isn't. We had examples with hundreds of faces, back when we decided to store faces in a hash-table. From unknown Tue Aug 19 05:12:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#53636: 29.0.50; face-remapping broken on master Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 05 Feb 2022 06:22:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 53636 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: Eli Zaretskii Cc: 53636@debbugs.gnu.org, tsdh@gnu.org Received: via spool by 53636-submit@debbugs.gnu.org id=B53636.164404207411438 (code B ref 53636); Sat, 05 Feb 2022 06:22:01 +0000 Received: (at 53636) by debbugs.gnu.org; 5 Feb 2022 06:21:14 +0000 Received: from localhost ([127.0.0.1]:33479 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nGERZ-0002yL-7G for submit@debbugs.gnu.org; Sat, 05 Feb 2022 01:21:14 -0500 Received: from quimby.gnus.org ([95.216.78.240]:41836) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nGERX-0002y6-Me for 53636@debbugs.gnu.org; Sat, 05 Feb 2022 01:21:08 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=GOPZnmKrasQwcgaAOJwiDvsBDQlXo0PI4Cal1VpnCGg=; b=u8mszJjxYREZxOFy/g5sSy6ezK F24QUmpDYtdeVlEPyuc7K2L1VGUFVyGZfsDaU9dPLWSOk6YuMZjFy1fYkXADVjbL0Lq9ZlVXFrtJX scxsXPCr5rkEQEtgVqXOEw6qMM9vPLgKgakJZTnoapDeFeaNCMTtyJGUaDDrcIcsmDvw=; Received: from [84.212.220.105] (helo=giant) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nGERO-00050k-K4; Sat, 05 Feb 2022 07:21:01 +0100 From: Lars Ingebrigtsen References: <87o83tib13.fsf@gnu.org> <871r0p9l4f.fsf@gnus.org> <83ee4p9izg.fsf@gnu.org> <87mtjd8485.fsf@gnus.org> <83a6fd9glm.fsf@gnu.org> <835yq19dk1.fsf@gnu.org> <87czk97yt6.fsf@gnus.org> <8335l49jwu.fsf@gnu.org> <835ypz8zbm.fsf@gnu.org> <87fsp2v0ky.fsf@gnus.org> <83leyu73i8.fsf@gnu.org> <87k0edrvxm.fsf@gnus.org> <83sft15egx.fsf@gnu.org> <871r0loxr9.fsf@gnus.org> <83mtj85tm1.fsf@gnu.org> <87wnibn48c.fsf@gnus.org> <8335kz4tgu.fsf@gnu.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAFVBMVEXh39ixp6Xk4tyC paqLtdhwmln///9J99hjAAAAAWJLR0QGYWa4fQAAAAlwSFlzAAAuIwAALiMBeKU/dgAAAAd0SU1F B+YCBQYEAs84KfcAAAFwSURBVDjLfZTLbgIxDEUdq907PPZOKj4Addi3mmFf2ub/fwXbeUwyAowE wSf32glmAB6HW5cEjggAowZbyt6ZvAAGZFamKduATKqKliuSuAmUlwJs32t42SweuFUEvxNnFYRd n2cvINd21AMnwJpCWeIgEJCbcufmxfBtIFpTsrT+3xaJDcjJDmhX6lqyn8syVyAte78vwHcKiB2Y nymWBqAD85Tt2jlCVRwqIANYweVvBDHsDVxSmgarorimlP4bgAImEyTzOouVTQE6A0mjgjJCL8Es 6UsarazG1RRTD/SuHgF8CQ4FfOWSGeglApwM2O8OHvLJWe4mBs3f8kQA5QllnR5W8FNGBYtCp4qP An7X6VpnWsE6qrCC92fglI4r4I58CMCuhJwjQ74BxQFYf/IJsdkONZiHfw90u/LWDRAfbUU8eQBM rDdKAcl1TwaMQVDwDXB7jgTnKByBkITVpFZgzz448Lwjj52gPWm6uAPVZ4pWjBaclQAAAA5lWElm SUkqAAgAAAAAAAAAAABvylxHAAAAJXRFWHRkYXRlOmNyZWF0ZQAyMDIyLTAyLTA1VDA2OjA0OjAy KzAwOjAwErAaGwAAACV0RVh0ZGF0ZTptb2RpZnkAMjAyMi0wMi0wNVQwNjowNDowMiswMDowMGPt oqcAAAAASUVORK5CYII= X-Now-Playing: Genesis's _Duke_: "Duke's End" Date: Sat, 05 Feb 2022 07:20:57 +0100 In-Reply-To: <8335kz4tgu.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 03 Feb 2022 21:53:53 +0200") Message-ID: <87ee4hg7g6.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii writes: > No, it isn't. We had examples with hundreds of faces, back when we > decided to store faces in a hash-table. Sorry, I don't follow -- examples of what that had hundreds of faces? Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: > No, it isn't. We had examples with hundreds of faces, back when we > decided to store faces in a hash-table. Sorry, I don't follow -- examples of what that had hundreds of faces? I'm saying that finding the faces that inherit from a specific face is not prohibitively expensive -- iterating over all the symbols and finding that info would be pretty fast. If it's not, then extending defface to keep track of this information would be simple enough, too. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From unknown Tue Aug 19 05:12:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#53636: 29.0.50; face-remapping broken on master Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 05 Feb 2022 07:51:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 53636 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: Lars Ingebrigtsen Cc: 53636@debbugs.gnu.org, tsdh@gnu.org Received: via spool by 53636-submit@debbugs.gnu.org id=B53636.164404743014600 (code B ref 53636); Sat, 05 Feb 2022 07:51:02 +0000 Received: (at 53636) by debbugs.gnu.org; 5 Feb 2022 07:50:30 +0000 Received: from localhost ([127.0.0.1]:33652 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nGFq1-0003nQ-W8 for submit@debbugs.gnu.org; Sat, 05 Feb 2022 02:50:30 -0500 Received: from eggs.gnu.org ([209.51.188.92]:47822) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nGFq1-0003nD-1H for 53636@debbugs.gnu.org; Sat, 05 Feb 2022 02:50:29 -0500 Received: from [2001:470:142:3::e] (port=54644 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nGFpu-0007oQ-Hi; Sat, 05 Feb 2022 02:50:22 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=ZY7lpseMto3tgY/SeMBbMMT3qtKApAF3Lx3UK1LfMa8=; b=THynEAIfUN1N 4X80y5lSd+330lm/IvUcSHv9kFDoTGLhUWzvOHLeznAtIcHzvY1eh5FDHzD6+DaIrYVku7la+AigP xHjr8rOHy4CSMIUo5d8CNSoMwI02f2OSyxlZ8bLuh/IZb/5M3J9i0XI34T/pTozPVYYHcOK/3Y5y0 koDWqHptj78/iHoCr6tTmPbKP2qNxVoIERNPM4IU8gUB3FFWEsrhACgLd5mcTaMLUjcgR7RlxFLnz P3mkEnjegFoEwBXAcdbVkX+eRaU2B9a6xKJGhbVPdVWPGh6OZsfrdU3gUDWG+nsS6UvcgkMFpuMH0 loKzhOhU1jTtT18F+bKtJA==; Received: from [87.69.77.57] (port=4601 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nGFps-0008FJ-Jh; Sat, 05 Feb 2022 02:50:21 -0500 Date: Sat, 05 Feb 2022 09:50:01 +0200 Message-Id: <83y22p21na.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87ee4hg7g6.fsf@gnus.org> (message from Lars Ingebrigtsen on Sat, 05 Feb 2022 07:20:57 +0100) References: <87o83tib13.fsf@gnu.org> <871r0p9l4f.fsf@gnus.org> <83ee4p9izg.fsf@gnu.org> <87mtjd8485.fsf@gnus.org> <83a6fd9glm.fsf@gnu.org> <835yq19dk1.fsf@gnu.org> <87czk97yt6.fsf@gnus.org> <8335l49jwu.fsf@gnu.org> <835ypz8zbm.fsf@gnu.org> <87fsp2v0ky.fsf@gnus.org> <83leyu73i8.fsf@gnu.org> <87k0edrvxm.fsf@gnus.org> <83sft15egx.fsf@gnu.org> <871r0loxr9.fsf@gnus.org> <83mtj85tm1.fsf@gnu.org> <87wnibn48c.fsf@gnus.org> <8335kz4tgu.fsf@gnu.org> <87ee4hg7g6.fsf@gnus.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen > Cc: 53636@debbugs.gnu.org, tsdh@gnu.org > Date: Sat, 05 Feb 2022 07:20:57 +0100 > > Eli Zaretskii writes: > > > No, it isn't. We had examples with hundreds of faces, back when we > > decided to store faces in a hash-table. > > Sorry, I don't follow -- examples of what that had hundreds of faces? People reported they have hundreds of faces defined in their Emacs sessions. See this message, for example: https://lists.gnu.org/archive/html/emacs-devel/2021-05/msg01031.html It reports to have 600 to 800 faces defined (with 129 in "emacs -Q"). > I'm saying that finding the faces that inherit from a specific face is > not prohibitively expensive -- iterating over all the symbols and > finding that info would be pretty fast. You'd need to loop through all those hundreds of faces for each change in face-remapping-alist. Imagine what this will do to "C-x C-=" and its ilk. > If it's not, then extending defface to keep track of this > information would be simple enough, too. Still a major complication, since inheritance is recursive. All that just to have one face that mode-line-* and header-line etc. can inherit from? Doesn't this look like a tail wagging the dog? From unknown Tue Aug 19 05:12:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#53636: [External] : bug#53636: 29.0.50; face-remapping broken on master Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 05 Feb 2022 16:15:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 53636 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: Eli Zaretskii , Lars Ingebrigtsen Cc: "53636@debbugs.gnu.org" <53636@debbugs.gnu.org>, "tsdh@gnu.org" Received: via spool by 53636-submit@debbugs.gnu.org id=B53636.16440776561753 (code B ref 53636); Sat, 05 Feb 2022 16:15:02 +0000 Received: (at 53636) by debbugs.gnu.org; 5 Feb 2022 16:14:16 +0000 Received: from localhost ([127.0.0.1]:35473 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nGNhX-0000SB-Jz for submit@debbugs.gnu.org; Sat, 05 Feb 2022 11:14:15 -0500 Received: from mx0a-00069f02.pphosted.com ([205.220.165.32]:41262) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nGNhR-0000Rx-S8 for 53636@debbugs.gnu.org; Sat, 05 Feb 2022 11:14:14 -0500 Received: from pps.filterd (m0246627.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 215BwEjK009016; Sat, 5 Feb 2022 16:14:08 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=corp-2021-07-09; bh=S86w8lUDjuUjI6eHejdM2O7TNcO9537e0tID2Ps2IzM=; b=VcRJPN/Q6vmIdpfF5bossWh0CWCQhVfKO/WIgKSvFfu02R7PVcgEJ2XpOYnjAaqHHh2d u0fDtADQrdyQH8XuY2hdzEZ8ZJej3UOkHpCN7NHbHIStJmzMDw3uIjv9ePiNkx4iWMus 4S6OZ6R+H63DEPctQ4r9NzNk2mozJt9Z401Ul1C7wYzjixi/brRMoflaos1SMzoCY6b8 Lh3nGGrKa6mVc4dzWv9J/HuG1c1AXsKdJnuwPDDRRpoaGr17msFQdNY4nHeazsoNH+VZ 7x4lnHGPf3z3rbuxTrBSo2GqdqBEuvghkI5aO2mDv/M6WHBYojqbxe3fl849v15VyJtb DQ== Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79]) by mx0b-00069f02.pphosted.com with ESMTP id 3e1fu2h9qu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 05 Feb 2022 16:14:08 +0000 Received: from pps.filterd (userp3020.oracle.com [127.0.0.1]) by userp3020.oracle.com (8.16.1.2/8.16.1.2) with SMTP id 215G66v0095086; Sat, 5 Feb 2022 16:14:07 GMT Received: from nam11-bn8-obe.outbound.protection.outlook.com (mail-bn8nam11lp2169.outbound.protection.outlook.com [104.47.58.169]) by userp3020.oracle.com with ESMTP id 3e1jpjk1jj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 05 Feb 2022 16:14:07 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mYymSEdYexs1NjGOmmEyPm5tJf/iNWCLYWh2TFfJN7CyoKTuVDbAQ8dKKny7C0d0XLS9pJX/hQ7bIRV7/R1AX7BTLQQWy7Ui5ax1bmC8ZXIbMpelld+HhWZgAm8IhqZ5DnoEjLyohA7ValDbszwaXUkLAFl5/S4EZWMuHYu00hGEWTgj1mRL7iYyxlj+2IHcJ322K1HzkE7MGXPTzfc/GM1qKKXi6gVDY0XSlrV0Fc3vslPuLCPH6hBl05nv6hrWefi1CBgbpXQZ28C5XZeJ47PmFptq7iSkeT3zrnf90v/MHTErdwHsG9ukxALaArOw2utF4chwAztV/vtfrFBjTg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=S86w8lUDjuUjI6eHejdM2O7TNcO9537e0tID2Ps2IzM=; b=XShgEzj/AoHF2nF03xA6fab9mMJ8Egn+/fuWOMgF4t5SiQHfNLqEZ1Jy/YQ0VZB4jBCuXRJNr45ePmMIypmQJiD8RvrzxpGz4C5LBGHcH6C930a8Z83SP45Z+8TdFcpvA7K/lfttsINr5Hxghq/aPl1z9wflJJwJzyisqIfJi3+LF8y8ltdbx5eLV0ueN1Dw6lZPKnYpecfpIasXQQNFMQd4jgEpfJovPxZ0T9Jp0QE4hcvt3pkQJxhyC0rB+JkGH91LZWXmDa9wYQtG8fsZl3GgaulI3TfRvCguqWaSI3IpWRNAZhHiKoNn2XGAJZuwvNrb1B/gn6tNnWcXE0cy4w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=S86w8lUDjuUjI6eHejdM2O7TNcO9537e0tID2Ps2IzM=; b=O2cP5n34qSKTHZVnhgGPYTaYlIumf1yznvoiXP7SDF/r/fsQXOHK7BTQkpXucoXCvQ8vC6vTQ4HYUTDXF0kA5gL6xqRKUgj3hSHmNxVTGOw+PbpFqLMAHq+cuWKA+9cYkNZ2n+dqZWSjOR1gG7aXuRKPXmBwo8yNo13TCWjqyKM= Received: from SJ0PR10MB5488.namprd10.prod.outlook.com (2603:10b6:a03:37e::19) by BY5PR10MB4370.namprd10.prod.outlook.com (2603:10b6:a03:20b::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4951.11; Sat, 5 Feb 2022 16:14:05 +0000 Received: from SJ0PR10MB5488.namprd10.prod.outlook.com ([fe80::99a4:696f:5f30:36b3]) by SJ0PR10MB5488.namprd10.prod.outlook.com ([fe80::99a4:696f:5f30:36b3%7]) with mapi id 15.20.4951.018; Sat, 5 Feb 2022 16:14:05 +0000 From: Drew Adams Thread-Topic: [External] : bug#53636: 29.0.50; face-remapping broken on master Thread-Index: AQHYGmXiH8P8V8Z4RkqYYLy6oIfwvayFIUpw Date: Sat, 5 Feb 2022 16:14:04 +0000 Message-ID: References: <87o83tib13.fsf@gnu.org> <871r0p9l4f.fsf@gnus.org> <83ee4p9izg.fsf@gnu.org> <87mtjd8485.fsf@gnus.org> <83a6fd9glm.fsf@gnu.org> <835yq19dk1.fsf@gnu.org> <87czk97yt6.fsf@gnus.org> <8335l49jwu.fsf@gnu.org> <835ypz8zbm.fsf@gnu.org> <87fsp2v0ky.fsf@gnus.org> <83leyu73i8.fsf@gnu.org> <87k0edrvxm.fsf@gnus.org> <83sft15egx.fsf@gnu.org> <871r0loxr9.fsf@gnus.org> <83mtj85tm1.fsf@gnu.org> <87wnibn48c.fsf@gnus.org> <8335kz4tgu.fsf@gnu.org> <87ee4hg7g6.fsf@gnus.org> <83y22p21na.fsf@gnu.org> In-Reply-To: <83y22p21na.fsf@gnu.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 619795dc-cc7b-4bb6-8a54-08d9e8c287e0 x-ms-traffictypediagnostic: BY5PR10MB4370:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: y9Y1i2NWqlHweXVNswtE0q5e/0Vih46R0o6SnTIAzLhwS4Z8x3phycV7kI6MbBhybj+bh7yDAdWQpK6lV/aS0+cT4zEy+3ZJIe0rucmgQgfVjZUmMYwfMsWD1I9UIGCBKxhnW4uxQlDFn4++fuPXzRR+xMPOhcH+PdAbWrjC0mFXYNGJgTvx4ViKfRa/LkW1tlRvxG/xoArtumZBkaY6rFeIPqhWiJFjSNE3no5ZoBv2ROfEbDypTWHdttnKwqu+sHOIgPpJ9spTY/wyRsDqlzygiVBGANMUkfkPpdX+LowfbGFZKZcTKZuNr9r/WyWjUsW6PxqPVyD2eAUqyDm6Rm+o8SeUmnyFu6sPoWLxDuapc722cUl9kxji5940sTa8zC6k3Z3pe9eZpFZj/Lb6YhEo5n53EMaKAMLXfcVmapB0vMozVvfEzT3CoD/6zyZ6OMBaYoduLgVe6fHJgxH6qf+uYDPaGi3uG3vFKrBYvk0+kuUTq+2Rq7e9SUaTUFpcV8EI2fHorpcGChAp3PsajUAT9kIJpBkwO5atHJsEQ4MGNr+CvOE6/JwCQn6WarU9rW7vIX0f1Vh8uUupO1S6C4xicTemz9BQ7kgYE6SLNDMnrp/n2UAB9iayjEVrk4Z8aeAXxGI6QoE0mI7WGHrscH7RJ6Ybk/tmY6gcAOK/EKiZrV5uZksYpD+yiIaAQkLIfHsyDt/bpLX5TxJaoyJc0Dhsr9AW8DRmgqio8t9IMAgAcdOK2/7AtOnzaVv+onpNhsqDLpJpIxuc28LDZ2QZ7KyG6bwU8O9YNl5VuDUQpIU= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SJ0PR10MB5488.namprd10.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(366004)(55016003)(66476007)(86362001)(71200400001)(508600001)(66556008)(38070700005)(6506007)(7696005)(9686003)(83380400001)(33656002)(26005)(186003)(4326008)(54906003)(64756008)(110136005)(8936002)(8676002)(316002)(66946007)(76116006)(66446008)(966005)(38100700002)(4744005)(122000001)(44832011)(52536014)(2906002)(5660300002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: 7In0lifO8jge4m48o9rr11xRcGRZK7KAHNYrdsaNMjfE7VZcaaBuoptThl8xqxolIotcs717usHk8zA4Z3hvaojdFkl5DXsqyhVm4+5MPIHIx6ctj8D+8evVZHZAciYXN/X+/iPso3oqrph2lwRZ/220YH2akOJNFpV8vYaRKzEmIHamIqkSCjBCW0rXBODCcfOysUfaBNfVq7TEylbBv/GNKhFQc4bcEA75GQwk8nmduyZ+l5fdu+b4BXTBHLco4Ri1beq95dPN/Dfy4zaNZA0ggngIPHW/VyaHnKRqMdOZUeNjkBDUccRtKvruVAHlU0W9VCadvoeUNhjYYU5VyS3Umx9shWGCdxAnY++xJG3f58g70/Q8wQW7GO4HjqRSkf7yfzDvtxw5r+t91XEK2ON2j5GLw24amwab1VT560tYNwzSNhZmx78DiGviJ8wEj6jgjNdZX9HbBAg6aI3i29UZFq7GbbbFPv28gcmVBzt2sI0kbntGise0eAU4DF/yHhKANiDeNqflpz7WQbMw0lUO3CaXx8EaO8znXUj3GN66pPLpzRymFwfwKdU5Ze5ISfUg3rpEk0FJYu/h01HLbDVEIPdgdKhdm6asJQ4xAiREASIiDM2kUry1NlE97BBUxt77vYyv9z55ottQTiTXaDRq9GNntwZhAq/1+WXAij7WlduWz2e32ebXBcKKI7H3DoJ4IeLcMoFenoh7ryuRAEJAAOcudAKBm7GrUiFNJ5QuljKB5/oaPmxf2S3Mr3PigGxZ+l084kpz+0l/BNHZkYsWWo2E4ZuLdUFtZG8P1O3clDRMgnJnSHMNFZj+j0qK3Rx4ashEauTao5K8w8T3l0YWbAZ2YjRHH+Giz983C5gKjeT5ioUKQOTQvRBPY2yEemakr8y/CpWB1D9kWTTxBWPl8Yp0VcyadpQ0huzsxt3lZnoohKCeWHixd2ifC2Z2neGr7fhaCWFoXDWqcTo5MZsHEqWSYWnsxmvu8GYAqUMvLZNml48Zr6N7YbhwXkVd1X1TdRqaLTcwznsINrjeYgjYctLBVMNAPc/H/2Sj+/RWYGTGt8kDQQeKb3ONlU5eSP9Gd4Hh5rcBjsaEZFE2wiSaYVKShhTn4U5j7L6MlNG8ZQN3YAHRp4ltIjB4K21+F2xF8XhJUWfGTqFTJjjn2d2RZ45Mo1sKiGz5eYlRl9RdkwHU127i2QNLdauTF6MYupORY/DFRw2l2KR4AN4Bd7qjrsoC/aRDM0/laB2UHGxfZlhXKPNeCE3AhfBNnPdCAZUv/RSljVcG6+VKUtORJtEwy8+/GeDPPbBPmHJKrkqQQOMhZfntq0DbUZCe/T4/W2PjdnkXKhfObji4b67N10Bz/zv45jPHYCYd0B6uHVpdAENa8s7aw7U3flfluwS9I9azl5S0gaAsQqN6rwzjsS0oqmLkdt9sBDcH0eMcUlAz8hUXmYAom2S2T0GvXZc5adOvZ/DKZdIBJUkZT/g7F63KcG+njrxJvPPUpZi4tmpKqdA6a/WEoUTq76H8+LKT4EC9F+QiLlF029BzmdpZxL+7UoZLstl4PDHGfPBT/bzxBkpFs0Nr9c5j8ot8uYGVMwJGzpjqeIE49IPvI5yewA== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SJ0PR10MB5488.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 619795dc-cc7b-4bb6-8a54-08d9e8c287e0 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Feb 2022 16:14:04.9637 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: OR+64dXgfjHBjRabCxq4I16Nfi0zrcpB25T0oSquMFEYgsCFOkPn4gjKtoItPdOiidtzK+dzQ4f0AjTLIsoGsw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR10MB4370 X-Proofpoint-Virus-Version: vendor=nai engine=6300 definitions=10249 signatures=673430 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=541 mlxscore=0 bulkscore=0 malwarescore=0 suspectscore=0 phishscore=0 adultscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2201110000 definitions=main-2202050109 X-Proofpoint-ORIG-GUID: GtMDJxeJtVwmhJmB8paRnRsVD9OKGwN9 X-Proofpoint-GUID: GtMDJxeJtVwmhJmB8paRnRsVD9OKGwN9 X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > > > No, it isn't. We had examples with hundreds of faces, back when we > > > decided to store faces in a hash-table. > > > > Sorry, I don't follow -- examples of what that had hundreds of faces? >=20 > People reported they have hundreds of faces defined in their Emacs > sessions. See this message, for example: >=20 > https://urldefense.com/v3/__https://lists.gnu.org/archive/html/emacs- > devel/2021- > 05/msg01031.html__;!!ACWV5N9M2RV99hQ!eDGeVB_SQ0DAF1rV2RiFjVAIlEJnGK9tdVR- > 2Epb6b7dlLp0UTSPD7Lm6l0_-q5Y$ >=20 > It reports to have 600 to 800 faces defined (with 129 in "emacs -Q"). Yes. FWIW, I have 475. > All that just to have one face that mode-line-* and header-line > etc. can inherit from? Doesn't this look like a tail wagging the dog? Right. IMO, no such inheritance should be predefined. If any user ever _wants_ a particular face to inherit from another face she can easily do so. Emacs should not be predefining any such couplings. From unknown Tue Aug 19 05:12:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#53636: 29.0.50; face-remapping broken on master Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 05 Feb 2022 22:28:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 53636 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: Eli Zaretskii Cc: 53636@debbugs.gnu.org, tsdh@gnu.org Received: via spool by 53636-submit@debbugs.gnu.org id=B53636.164410007213617 (code B ref 53636); Sat, 05 Feb 2022 22:28:02 +0000 Received: (at 53636) by debbugs.gnu.org; 5 Feb 2022 22:27:52 +0000 Received: from localhost ([127.0.0.1]:35794 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nGTX6-0003XZ-C0 for submit@debbugs.gnu.org; Sat, 05 Feb 2022 17:27:52 -0500 Received: from quimby.gnus.org ([95.216.78.240]:49744) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nGTX5-0003XM-8G for 53636@debbugs.gnu.org; Sat, 05 Feb 2022 17:27:51 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=XXGl9x2lNUpBiwZtbd1XEDQlw+JxqWYsk8xE8thaOaI=; b=FmIKRQE7SYyofBWfzum5GCExUz 7zFNDePal61tyZUCKRK7IasJgwqOYT4UMTWEajemTzTfhgTdqObnvLdSAy7wrq9Z8xEKmiSp7u9LI EVFWHLyyDbvEoxur6WFyTdrEocy3fXpn8XwLJcd2bdCtnkQCXtEVreH4l93VNJ2dngJU=; Received: from [84.212.220.105] (helo=giant) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nGTWs-0004TB-RA; Sat, 05 Feb 2022 23:27:44 +0100 From: Lars Ingebrigtsen References: <87o83tib13.fsf@gnu.org> <871r0p9l4f.fsf@gnus.org> <83ee4p9izg.fsf@gnu.org> <87mtjd8485.fsf@gnus.org> <83a6fd9glm.fsf@gnu.org> <835yq19dk1.fsf@gnu.org> <87czk97yt6.fsf@gnus.org> <8335l49jwu.fsf@gnu.org> <835ypz8zbm.fsf@gnu.org> <87fsp2v0ky.fsf@gnus.org> <83leyu73i8.fsf@gnu.org> <87k0edrvxm.fsf@gnus.org> <83sft15egx.fsf@gnu.org> <871r0loxr9.fsf@gnus.org> <83mtj85tm1.fsf@gnu.org> <87wnibn48c.fsf@gnus.org> <8335kz4tgu.fsf@gnu.org> <87ee4hg7g6.fsf@gnus.org> <83y22p21na.fsf@gnu.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAIVBMVEX78dv9/e/S1dvG vre3x9iBgXagpaCLhnhfaGAxLiX///9a+C/aAAAAAWJLR0QKaND0VgAAAAd0SU1FB+YCBRYNAgLc Mc4AAAGjSURBVDjLndTPT8IwFAfwbvPgcTA08aYdAbk5qgWuSIxHMRmZN02zpzuqifHoj1C6m4mJ rv+thQ19AzTq99hP+95rFyAkj1VBcfO1yqq4C3t/BZX/gU2/EmCoD2bp9yn1h4swXTVpXC/BdNn3 +WkO1ifk+8XBMwabFnAsOqGFSvmkno/Uhc59gICTtRxi4OoClWqT4iYAPELgOsTuF9CIgjLM1hlA U1UwWM5MhAQuS0DIdp1uO0JO+AmCqm05gabNGzGW3RcMzo4fvNOtV5CTdAHshqReeisnVy/l5l4v o46+vZvsPsxuVgAh1Z5+8nSkxs1HdGJTOCLRKtU6zUqlNlSbJRpGOkv1GQaPcUj0CLRUSpemopR3 dRym93MomlcZY7sZQAIA0XAJDtutJ/NeO6hUbcBYL2Os9Wp2BOhEzZQwU0HyxjkUQOaglJKRZIyX wJSah5dKDcyn4+aYWOxxxIF1VawEh/gcT7Vvrh6FYWgaqQfXmrbIgcfqM/jZNxTKI4L172BzZOqP YJrLEL/VivwZ3JXgta3Vv3Nvz/rpL+ObfACVHLLUhFTUewAAACV0RVh0ZGF0ZTpjcmVhdGUAMjAy Mi0wMi0wNVQyMjoxMzowMiswMDowMBA1cJkAAAAldEVYdGRhdGU6bW9kaWZ5ADIwMjItMDItMDVU MjI6MTM6MDIrMDA6MDBhaMglAAAAAElFTkSuQmCC X-Now-Playing: Pink Floyd's _Wish You Were Here_: "Shine On You Crazy Diamond (Part 2)" Date: Sat, 05 Feb 2022 23:27:36 +0100 In-Reply-To: <83y22p21na.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 05 Feb 2022 09:50:01 +0200") Message-ID: <871r0haqzr.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii writes: >> Sorry, I don't follow -- examples of what that had hundreds of faces? > > People reported they have hundreds of faces defined in their Emacs > sessions. See this message, for example: > > https://l [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: >> Sorry, I don't follow -- examples of what that had hundreds of faces? > > People reported they have hundreds of faces defined in their Emacs > sessions. See this message, for example: > > https://lists.gnu.org/archive/html/emacs-devel/2021-05/msg01031.html > > It reports to have 600 to 800 faces defined (with 129 in "emacs -Q"). But people aren't remapping all those faces, so the number of faces in total doesn't seem to matter that much here. (And looping over 800 faces to pick out dependencies is probably not very expensive.) > You'd need to loop through all those hundreds of faces for each change > in face-remapping-alist. Imagine what this will do to "C-x C-=" and > its ilk. It would have no impact on those ilks, because the looping will be done in `face-remap-add-relative' and nowhere else? >> If it's not, then extending defface to keep track of this >> information would be simple enough, too. > > Still a major complication, since inheritance is recursive. > > All that just to have one face that mode-line-* and header-line > etc. can inherit from? Doesn't this look like a tail wagging the dog? Well, fixing bugs is nice anyway. :-) So here's a reproducer for the first problem: These two forms, both from "emacs -Q", have different effects on the new frame: (progn (face-remap-add-relative 'mode-line 'link-visited) (make-frame)) vs (progn (face-remap-add-relative 'mode-line 'link-visited) (switch-to-buffer "*Messages*") (make-frame)) In the first case, the new frame will have mode-line remapped to link-visited in all windows, while in the latter it won't. So it looks like a pretty simple bug -- `make-frame' (when computing the faces for the new frame) is using the buffer-local value of `face-remapping-alist' instead of the global one. But after poking at the code for a couple minutes, I'm not sure where the computation for faces is done for new faces. Hm... is it `face-spec-recalc'? Hm... but that doesn't access `face-remapping-alist'... Is this done at a lower level? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From unknown Tue Aug 19 05:12:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#53636: 29.0.50; face-remapping broken on master Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 06 Feb 2022 07:14:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 53636 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: Lars Ingebrigtsen Cc: 53636@debbugs.gnu.org, tsdh@gnu.org Received: via spool by 53636-submit@debbugs.gnu.org id=B53636.164413159020939 (code B ref 53636); Sun, 06 Feb 2022 07:14:01 +0000 Received: (at 53636) by debbugs.gnu.org; 6 Feb 2022 07:13:10 +0000 Received: from localhost ([127.0.0.1]:36246 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nGbjR-0005Rf-Rv for submit@debbugs.gnu.org; Sun, 06 Feb 2022 02:13:10 -0500 Received: from eggs.gnu.org ([209.51.188.92]:50040) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nGbjQ-0005RQ-4u for 53636@debbugs.gnu.org; Sun, 06 Feb 2022 02:13:08 -0500 Received: from [2001:470:142:3::e] (port=52190 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nGbjK-0002EQ-Or; Sun, 06 Feb 2022 02:13:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=NKXFJ725VO5wj0V3AfLHoc7lqUsOROK6bnSXSYlAQV4=; b=gvT618GYO9v8 oIYgpt0OLNGPcgAaaWwk0/mmTmypW2PO8MDFTD48YVIRJYdFxW8gFD0SKktVuyuGnsD94qXOGWH1K PZeck+hmMwQRHdvEY/hId7Nwt3g2bLXIJoN//je/FlTtF1eGQF0P92EaxXu/P+Jy6lP4Hzh+QGnDc +ZvE6ghqwpo2WQDiCE8vzGxxe1a2uftmUov9wLCBdcDnIkfJ4Bgof3eE2jPQTAtWvpOP/VHbyKwNk y/DXFmMLOnqJzQh9nBO78AlJbtsxn8KcFMeG6gtTzndJMn6/9l+W8O6Lw8L2yyq8ErJ3Mm4NKL/4d 8fqHCXaJhlVh8k5B8IFd7g==; Received: from [87.69.77.57] (port=3387 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nGbjJ-0003Sw-To; Sun, 06 Feb 2022 02:13:02 -0500 Date: Sun, 06 Feb 2022 09:12:45 +0200 Message-Id: <8335kw1n9u.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <871r0haqzr.fsf@gnus.org> (message from Lars Ingebrigtsen on Sat, 05 Feb 2022 23:27:36 +0100) References: <87o83tib13.fsf@gnu.org> <871r0p9l4f.fsf@gnus.org> <83ee4p9izg.fsf@gnu.org> <87mtjd8485.fsf@gnus.org> <83a6fd9glm.fsf@gnu.org> <835yq19dk1.fsf@gnu.org> <87czk97yt6.fsf@gnus.org> <8335l49jwu.fsf@gnu.org> <835ypz8zbm.fsf@gnu.org> <87fsp2v0ky.fsf@gnus.org> <83leyu73i8.fsf@gnu.org> <87k0edrvxm.fsf@gnus.org> <83sft15egx.fsf@gnu.org> <871r0loxr9.fsf@gnus.org> <83mtj85tm1.fsf@gnu.org> <87wnibn48c.fsf@gnus.org> <8335kz4tgu.fsf@gnu.org> <87ee4hg7g6.fsf@gnus.org> <83y22p21na.fsf@gnu.org> <871r0haqzr.fsf@gnus.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen > Cc: 53636@debbugs.gnu.org, tsdh@gnu.org > Date: Sat, 05 Feb 2022 23:27:36 +0100 > > (progn > (face-remap-add-relative 'mode-line 'link-visited) > (make-frame)) > > vs > > (progn > (face-remap-add-relative 'mode-line 'link-visited) > (switch-to-buffer "*Messages*") > (make-frame)) > > In the first case, the new frame will have mode-line remapped to > link-visited in all windows, while in the latter it won't. So it looks > like a pretty simple bug -- `make-frame' (when computing the faces for > the new frame) is using the buffer-local value of > `face-remapping-alist' instead of the global one. But which case is considered a bug? In the first case, the mode line of *scratch* is affected in the second frame; in the second case the remapping doesn't show in that buffer on _any_ frame, although face-remapping-alist is updated. > But after poking at the code for a couple minutes, I'm not sure where > the computation for faces is done for new faces. Hm... is it > `face-spec-recalc'? Hm... but that doesn't access > `face-remapping-alist'... Is this done at a lower level? What is "this" and "the computation" which you are asking about here? From unknown Tue Aug 19 05:12:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#53636: 29.0.50; face-remapping broken on master Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 06 Feb 2022 23:17:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 53636 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: Eli Zaretskii Cc: 53636@debbugs.gnu.org, tsdh@gnu.org Received: via spool by 53636-submit@debbugs.gnu.org id=B53636.164418937910383 (code B ref 53636); Sun, 06 Feb 2022 23:17:02 +0000 Received: (at 53636) by debbugs.gnu.org; 6 Feb 2022 23:16:19 +0000 Received: from localhost ([127.0.0.1]:40217 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nGqlX-0002hO-Hm for submit@debbugs.gnu.org; Sun, 06 Feb 2022 18:16:19 -0500 Received: from quimby.gnus.org ([95.216.78.240]:32972) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nGqlV-0002hB-SB for 53636@debbugs.gnu.org; Sun, 06 Feb 2022 18:16:18 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=7YGf5kwufdpZ+wj4kktWoY/J5K6AGCfUh5wS7ikq1D4=; b=duMxwpwfN/1mBT3BaGdypNjVdh 90vHH5dBNyqd4DIlKwoyjROJvPi9d4q9syYj2KFXhuzoeiYBKFo7Dx4CqiMRlRAoPqnoDFzfmxpRh kfD2yGjf9zauhfXbpmxwVQHsEngd65tkq0lJemrbiAwejWw2uHlacwTXwz7a63DvmvCI=; Received: from [84.212.220.105] (helo=giant) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nGqlM-0000tK-KU; Mon, 07 Feb 2022 00:16:11 +0100 From: Lars Ingebrigtsen References: <87o83tib13.fsf@gnu.org> <871r0p9l4f.fsf@gnus.org> <83ee4p9izg.fsf@gnu.org> <87mtjd8485.fsf@gnus.org> <83a6fd9glm.fsf@gnu.org> <835yq19dk1.fsf@gnu.org> <87czk97yt6.fsf@gnus.org> <8335l49jwu.fsf@gnu.org> <835ypz8zbm.fsf@gnu.org> <87fsp2v0ky.fsf@gnus.org> <83leyu73i8.fsf@gnu.org> <87k0edrvxm.fsf@gnus.org> <83sft15egx.fsf@gnu.org> <871r0loxr9.fsf@gnus.org> <83mtj85tm1.fsf@gnu.org> <87wnibn48c.fsf@gnus.org> <8335kz4tgu.fsf@gnu.org> <87ee4hg7g6.fsf@gnus.org> <83y22p21na.fsf@gnu.org> <871r0haqzr.fsf@gnus.org> <8335kw1n9u.fsf@gnu.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAGFBMVEUQCgxdMDliTJNL PYLCWjejTiPejHr///+9aF0aAAAAAWJLR0QHFmGI6wAAAAd0SU1FB+YCBhcDLFP+1FYAAAGfSURB VDjLbZJNbsMgEIVxo2Rt2rBvSA4QixO4HVgHCfZNRbj/ETrDf9y8yLHMN+8Ng80YY3wQS5rzTQ46 s4nxSS3XAi5SftHf5YQmMb9/X9k0F0cC8rzwedkpOYCcJBWSs5TXbQ+pPpbdK6AUX5RSrx0IVAK/ Gwtp3jiUEj7p9gQUz6teuw4WTrWukAZOJcE/g5OvwRXAjb19slqtGTvqbEBwuLPacEW3a2Z0jGDf wOGnBrsVX9PUmmOULmQVOG+xJ4f2BXFbgS+gyvIOUB1wSBj3P9Mb1N0QdboR2N8Gh4tkoaNExwhM DLnA/gMpCw95bI7nHgugAXtzzh2CR3UgaHvCJBPq5FN6CZbGJlC7VweO5LRIQI8AZ3UxGAJQwZ6i OLe0SALoZ0VApEW6jKXmc57D8iPF06bArD4dSXJYDzkqAMS7qJPTV4EgRLwMxIfwUIAALMQ1EyEA 7RfyB5cMAePjFnhIQkTSOCs8A/yhhAate3MACgQNgZ7aWaFH47OmAvJ34HJ8hKIS5XMbU9pjRQeO YprBd5BdWOBci3qpPzUxBQ9waXW8AAAAJXRFWHRkYXRlOmNyZWF0ZQAyMDIyLTAyLTA2VDIzOjAz OjQ0KzAwOjAwwn/57gAAACV0RVh0ZGF0ZTptb2RpZnkAMjAyMi0wMi0wNlQyMzowMzo0NCswMDow MLMiQVIAAAAASUVORK5CYII= X-Now-Playing: Alice Coltrane's _Eternity_: "Los Caballos" Date: Mon, 07 Feb 2022 00:16:08 +0100 In-Reply-To: <8335kw1n9u.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 06 Feb 2022 09:12:45 +0200") Message-ID: <87mtj34mdj.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii writes: > But which case is considered a bug? In the first case, the mode line > of *scratch* is affected in the second frame; in the second case the > remapping doesn't show in that buffer on _any_ frame, al [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: > But which case is considered a bug? In the first case, the mode line > of *scratch* is affected in the second frame; in the second case the > remapping doesn't show in that buffer on _any_ frame, although > face-remapping-alist is updated. The bug I'm talking about here is that `face-remap-add-relative' is supposed to be buffer-local, but calling it, and then creating a new frame (with point in that buffer) will have the remapping take place in all buffer in the new frame. >> But after poking at the code for a couple minutes, I'm not sure where >> the computation for faces is done for new faces. Hm... is it >> `face-spec-recalc'? Hm... but that doesn't access >> `face-remapping-alist'... Is this done at a lower level? > > What is "this" and "the computation" which you are asking about here? The computation of the faces for the new frame. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From unknown Tue Aug 19 05:12:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#53636: 29.0.50; face-remapping broken on master Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 07 Feb 2022 15:05:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 53636 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: Lars Ingebrigtsen Cc: 53636@debbugs.gnu.org, tsdh@gnu.org Received: via spool by 53636-submit@debbugs.gnu.org id=B53636.16442462521255 (code B ref 53636); Mon, 07 Feb 2022 15:05:02 +0000 Received: (at 53636) by debbugs.gnu.org; 7 Feb 2022 15:04:12 +0000 Received: from localhost ([127.0.0.1]:43188 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nH5Yq-0000KB-7k for submit@debbugs.gnu.org; Mon, 07 Feb 2022 10:04:12 -0500 Received: from eggs.gnu.org ([209.51.188.92]:34154) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nH5Ym-0000Jw-Gk for 53636@debbugs.gnu.org; Mon, 07 Feb 2022 10:04:10 -0500 Received: from [2001:470:142:3::e] (port=54004 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nH5YJ-0004YG-CD; Mon, 07 Feb 2022 10:04:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=zfM+KwBtq9QUXaOEdv2rQg3bVm0IEQRCxLUe5qpVLp8=; b=WHgzhcTeZUg7 SilPU2og54Q34srK8T35TMIqWVQuBpW4FtDOnQ+tOvKMQocFmxOu3fX1j/h7vf7s2hMFZEjXH0yfO m9WGavR8trU7Kalbep7i2lczc1sf89/tcKTnqF9QU7rEsZgrPi4H8DF28JdfQDIkgIxUjXJJyhz/O AIVLHAWyhUi5KEgJUu7bSfXpIoij6Z/g/SUWSnBZMEGpx56E9B3Ypuvla+j+FCURIn57qvpqA9JVJ 7KzzAC6d9hcFIucB0SBz3h5oAygtmtXnGYyn0why5LrhRXuZcfzXkKAvO9omDjSQ4LuuFGIvrOwOR 2C3L7ySEGS6t+Tin5fGdwA==; Received: from [87.69.77.57] (port=1053 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nH5YH-0007ak-QA; Mon, 07 Feb 2022 10:03:38 -0500 Date: Mon, 07 Feb 2022 17:03:24 +0200 Message-Id: <837da6yb0j.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87mtj34mdj.fsf@gnus.org> (message from Lars Ingebrigtsen on Mon, 07 Feb 2022 00:16:08 +0100) References: <87o83tib13.fsf@gnu.org> <871r0p9l4f.fsf@gnus.org> <83ee4p9izg.fsf@gnu.org> <87mtjd8485.fsf@gnus.org> <83a6fd9glm.fsf@gnu.org> <835yq19dk1.fsf@gnu.org> <87czk97yt6.fsf@gnus.org> <8335l49jwu.fsf@gnu.org> <835ypz8zbm.fsf@gnu.org> <87fsp2v0ky.fsf@gnus.org> <83leyu73i8.fsf@gnu.org> <87k0edrvxm.fsf@gnus.org> <83sft15egx.fsf@gnu.org> <871r0loxr9.fsf@gnus.org> <83mtj85tm1.fsf@gnu.org> <87wnibn48c.fsf@gnus.org> <8335kz4tgu.fsf@gnu.org> <87ee4hg7g6.fsf@gnus.org> <83y22p21na.fsf@gnu.org> <871r0haqzr.fsf@gnus.org> <8335kw1n9u.fsf@gnu.org> <87mtj34mdj.fsf@gnus.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen > Cc: 53636@debbugs.gnu.org, tsdh@gnu.org > Date: Mon, 07 Feb 2022 00:16:08 +0100 > > Eli Zaretskii writes: > > > But which case is considered a bug? In the first case, the mode line > > of *scratch* is affected in the second frame; in the second case the > > remapping doesn't show in that buffer on _any_ frame, although > > face-remapping-alist is updated. > > The bug I'm talking about here is that `face-remap-add-relative' is > supposed to be buffer-local, but calling it, and then creating a new > frame (with point in that buffer) will have the remapping take place in > all buffer in the new frame. And what happens when you call make-frame from another buffer is not a bug? Is face-remapping-alist supposed to affect the buffer in which it is set on all frames or just on the single frame where face-remap-add-relative was called? > >> But after poking at the code for a couple minutes, I'm not sure where > >> the computation for faces is done for new faces. Hm... is it > >> `face-spec-recalc'? Hm... but that doesn't access > >> `face-remapping-alist'... Is this done at a lower level? > > > > What is "this" and "the computation" which you are asking about here? > > The computation of the faces for the new frame. You mean init_frame_faces, which calls realize_basic_faces? Or do you mean some other kind of "face computation"? From unknown Tue Aug 19 05:12:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#53636: 29.0.50; face-remapping broken on master Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 08 Feb 2022 06:09:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 53636 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: Eli Zaretskii Cc: 53636@debbugs.gnu.org, tsdh@gnu.org Received: via spool by 53636-submit@debbugs.gnu.org id=B53636.164430052123469 (code B ref 53636); Tue, 08 Feb 2022 06:09:01 +0000 Received: (at 53636) by debbugs.gnu.org; 8 Feb 2022 06:08:41 +0000 Received: from localhost ([127.0.0.1]:44830 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nHJg9-00066T-3c for submit@debbugs.gnu.org; Tue, 08 Feb 2022 01:08:41 -0500 Received: from quimby.gnus.org ([95.216.78.240]:47996) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nHJg7-00066F-Df for 53636@debbugs.gnu.org; Tue, 08 Feb 2022 01:08:39 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=IfrYIOVYiRHvVdM07yLEyj1uuO+7RpBA0ms75FOXglg=; b=ReEmBInrDi8Fdt/fFl+Y7/UZyQ V4XYy94TcFY6jgpJDsku+FevTwEyWrb1BeV+xvoGruewCyQtB2rndK5PWaU/0jdLVXKWixiLCkB1k pH9swQ1q7fQxHR4IPNmuK6apV3Z3piutKALcRBUBfnPJRuArBKTrqI7GoqENnna3PE7k=; Received: from [84.212.220.105] (helo=giant) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nHJfy-0001cO-BZ; Tue, 08 Feb 2022 07:08:33 +0100 From: Lars Ingebrigtsen References: <87o83tib13.fsf@gnu.org> <87mtjd8485.fsf@gnus.org> <83a6fd9glm.fsf@gnu.org> <835yq19dk1.fsf@gnu.org> <87czk97yt6.fsf@gnus.org> <8335l49jwu.fsf@gnu.org> <835ypz8zbm.fsf@gnu.org> <87fsp2v0ky.fsf@gnus.org> <83leyu73i8.fsf@gnu.org> <87k0edrvxm.fsf@gnus.org> <83sft15egx.fsf@gnu.org> <871r0loxr9.fsf@gnus.org> <83mtj85tm1.fsf@gnu.org> <87wnibn48c.fsf@gnus.org> <8335kz4tgu.fsf@gnu.org> <87ee4hg7g6.fsf@gnus.org> <83y22p21na.fsf@gnu.org> <871r0haqzr.fsf@gnus.org> <8335kw1n9u.fsf@gnu.org> <87mtj34mdj.fsf@gnus.org> <837da6yb0j.fsf@gnu.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAElBMVEWooZvx7uZjXVqE fnkyLi3///8QUN7IAAAAAWJLR0QF+G/pxwAAAAd0SU1FB+YCCAYCFJ/c4/0AAAG6SURBVDjLZZMN coQgDIWDeABsL+AEDpBCT0Bz/zP1PWTVdTO7I+Yj/1Fku8sStpRiVVWx7Sn2FQn2N5OEnw4RtXAH AfpMX6JZwhYusKkCdgITyASyhUV/khaCFqPJYSMxVKvaWgXgI7dhlGLLVU33qAMgXIM/lCDMp2uu wwKSq0lkKL6UPUmcQNUijeo49y3VE+TW2gTeLe4q8QTIos1r8W+RxJTyAIx5REfVkCWLoZJpOszh FOmnaImVJxbKGM60RjNkO1s8ktmlNnlOIzU4Wqx+ACAUtMinhYQR9tMijWm/W8yXmdAl3383LliY MVm8rf0MjkCVY0gTCC8ZOlM6hrlxeskIDMuQutamE2Br2gC8gh5q7YLeRosoWMKvdzE5Fq7LWC8s HaxW94xLx7AEYcYOS2vFXXMW9tddrikoAPzXCXi+gwz/B6B0ant5nR7A6eKlH64I6GaqJoCOiBne 9Vi4ad1cTzewjocrHks+8qRkrTJv9MXfPJUJfF9vWprK68al7yLrCe7XsTz+CUZv3MsTqBkrqg+L zj1fvHMAd8BvSuLq+3IDvXQsP6X4Xq7uWqAWf3z6xQn+AWl4oE3+7z5XAAAAJXRFWHRkYXRlOmNy ZWF0ZQAyMDIyLTAyLTA4VDA2OjAyOjIwKzAwOjAww14+UQAAACV0RVh0ZGF0ZTptb2RpZnkAMjAy Mi0wMi0wOFQwNjowMjoyMCswMDowMLIDhu0AAAAASUVORK5CYII= X-Now-Playing: Melanie de Biasio's _Blackened Cities_: "Blackened Cities" Date: Tue, 08 Feb 2022 07:08:29 +0100 In-Reply-To: <837da6yb0j.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 07 Feb 2022 17:03:24 +0200") Message-ID: <87k0e5vqjm.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii writes: > And what happens when you call make-frame from another buffer is not a > bug? Is face-remapping-alist supposed to affect the buffer in which > it is set on all frames or just on the single frame whe [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: > And what happens when you call make-frame from another buffer is not a > bug? Is face-remapping-alist supposed to affect the buffer in which > it is set on all frames or just on the single frame where > face-remap-add-relative was called? I'm not sure. But the current behaviour (affecting all buffers on the new frame) has to be a bug. >> The computation of the faces for the new frame. > > You mean init_frame_faces, which calls realize_basic_faces? Or do you > mean some other kind of "face computation"? I don't know? I'm looking for the code that leads to the behaviour I described. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From unknown Tue Aug 19 05:12:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#53636: 29.0.50; face-remapping broken on master Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 08 Feb 2022 08:59:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 53636 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: Lars Ingebrigtsen , Eli Zaretskii Cc: 53636@debbugs.gnu.org, tsdh@gnu.org Received: via spool by 53636-submit@debbugs.gnu.org id=B53636.16443107205105 (code B ref 53636); Tue, 08 Feb 2022 08:59:02 +0000 Received: (at 53636) by debbugs.gnu.org; 8 Feb 2022 08:58:40 +0000 Received: from localhost ([127.0.0.1]:45233 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nHMKd-0001KH-TK for submit@debbugs.gnu.org; Tue, 08 Feb 2022 03:58:40 -0500 Received: from mout.gmx.net ([212.227.17.22]:45487) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nHMKc-0001K4-BC for 53636@debbugs.gnu.org; Tue, 08 Feb 2022 03:58:38 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1644310712; bh=6EmYbA9WaR6z42/7QzrDWHVxuEZw/LP34Oqgqpz9GBY=; h=X-UI-Sender-Class:Date:Subject:To:Cc:References:From:In-Reply-To; b=fpdDLV9YEvQ1AE9emUOOm+/XPdAtByTcSwv+8c0Csn5Tr6NlKGWH47O3+K6IPoqA1 JH/GsKYor97awTVocdEG4xsJhhuDCq+LL5+IIHtrQDlQR4yJ6x+tYvN+DwLs027mkU GrelFrwVAtrx1I7mcXNeGGbeqoAXNfcJRoWwZoqo= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.102] ([212.95.5.151]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MxDkm-1oEx7o0NZ2-00xd6T; Tue, 08 Feb 2022 09:58:32 +0100 Message-ID: <916b44c9-56dc-65b9-8894-cb5954e1bd9c@gmx.at> Date: Tue, 8 Feb 2022 09:58:31 +0100 MIME-Version: 1.0 Content-Language: en-US References: <87o83tib13.fsf@gnu.org> <87mtjd8485.fsf@gnus.org> <83a6fd9glm.fsf@gnu.org> <835yq19dk1.fsf@gnu.org> <87czk97yt6.fsf@gnus.org> <8335l49jwu.fsf@gnu.org> <835ypz8zbm.fsf@gnu.org> <87fsp2v0ky.fsf@gnus.org> <83leyu73i8.fsf@gnu.org> <87k0edrvxm.fsf@gnus.org> <83sft15egx.fsf@gnu.org> <871r0loxr9.fsf@gnus.org> <83mtj85tm1.fsf@gnu.org> <87wnibn48c.fsf@gnus.org> <8335kz4tgu.fsf@gnu.org> <87ee4hg7g6.fsf@gnus.org> <83y22p21na.fsf@gnu.org> <871r0haqzr.fsf@gnus.org> <8335kw1n9u.fsf@gnu.org> <87mtj34mdj.fsf@gnus.org> <837da6yb0j.fsf@gnu.org> <87k0e5vqjm.fsf@gnus.org> From: martin rudalics In-Reply-To: <87k0e5vqjm.fsf@gnus.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:vJWzqLdKadOHde38/fTLDJVC4fAX5VBZsMojN2uygw8M0g1yCM0 eOQKknu7iTEWLNQREj38yy51fuLYXaL8nnnMVSX6LEHRSKu9J+sQiOdM7xCn2Xp1grrRW7i y0bT5wY/hP7r48cyBhIs9KLzwL0ubDXJOugoFyoqz8SdGm8bc+uwNjhmt5vupS1LcShqAoK wMrV7rL6YQOiVUrFZNUMg== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:qu4oJrJuYfw=:wW3QyW+3yYKLZkUbTzaFMI zHI3t7g5OGQ8oJ6nWxpMnHpSTrWov5tULmh9l1+t/u2CtaIhUuQ1HssaHqqluKmljQNkRvI/S FC3SKgmAuDYWeunfD+H7QcNnOUwU8Vtm3evjniNGWeExwJ1p7hwdWXGPVLJ3uXl6BXLCD+ynq 5ieO/PwaGUbWURuoWHezmJ4I112o45b5ta9IMXostUYX8UsoX0stIxuDStJWVSS1Qi4aXMjqq vxcByChaInnIZR1PDjpUNZpxNjGpl34WwqpsK2ibVWWZUTJbFlcMiszX5tmrfXIbk/pbZOhnB YTguHCYWXDxGdFsOMioDrMHKG/jNRN4m7YIcn0/aET5rps1eOuXN10mxh009GylvwNMwdrD2s kVjUEoCeHEBynU+j2QisSchx/UjoJwGR+rdMu8qpcJQGvV1Nhg5BbgjtMpz6vFqjTeZAXWC1i aEhXumUhJ3Tn+tHdPwhZCDH/TlkRldv9s7HpP3v3rbPBhtphdu6++FBpADAwmgjHPUWwtbBo1 HoinQJj6GUG+qFBn2oFsAm8/DwjB9h1vwhGMQhQVh7LM1Ue9YW4nUDlUss6o82vLD6WMUQyVg B5Bg784SgD9ZBDG4VoVsz2bd7TwQey6otSCqrwSfT7OhZSpyxJ+wLWd8fz0EegdKnzmsHOrSE K6hnQNSMnKxtFNuwpG/K0wMjrkqT1jS6tRGYl5L8GZxEL+9UcCCvLZ55usIQTY6m4eIlYlIPF PTUvHDwJKUfE5Zu2zcEvy55jEUkHPi6nHs64y6lWtcxjQlydd9VpRX47LVqOgC4Q6s0LltZiz L9II90nRR/6DRxsC6Immue++Ypw7NN25GVxpHLL9kEwBBj2ml4/YzrBcZntGIsQZi2Z7PKoN0 TiHEp1cvAVuDD8Z5HHacIwEb8PpR8EZPU5zEqt6SY+d5cTfaASyVZARaPFOIVfC4FcCAivET8 YSfEMRjsL+yAED5GtSnCW+NLlnxKrkoVtK83AjzDzyHoo2EBaQPpiMjhzdBf2m0iYiFRTwDfi wIFLcBtB4rm9NrkryqMNedi07LDEVrfVW9BCCvzVM1O9leWxrZ8mtJT5uAmwyvwfOSu8gBsQ8 4uLLwLkSx6kWFs= X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) >> And what happens when you call make-frame from another buffer is not a >> bug? Is face-remapping-alist supposed to affect the buffer in which >> it is set on all frames or just on the single frame where >> face-remap-add-relative was called? > > I'm not sure. But the current behaviour (affecting all buffers on the > new frame) has to be a bug. Face remapping has never been properly synchronized with windows and frames. What's needed is a simple hierarchy window > window's buffer > window's frame where the first should be implemented with the help of a 'face-remapping' window parameter and the last with the help of a 'face-remapping' frame parameter. Just like we (should) do for things like the scroll bars or fringes. But we need a consensus on this first. martin From unknown Tue Aug 19 05:12:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#53636: 29.0.50; face-remapping broken on master Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 08 Feb 2022 12:30:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 53636 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: Lars Ingebrigtsen Cc: 53636@debbugs.gnu.org, tsdh@gnu.org Received: via spool by 53636-submit@debbugs.gnu.org id=B53636.164432339330702 (code B ref 53636); Tue, 08 Feb 2022 12:30:02 +0000 Received: (at 53636) by debbugs.gnu.org; 8 Feb 2022 12:29:53 +0000 Received: from localhost ([127.0.0.1]:45744 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nHPd3-0007z8-GN for submit@debbugs.gnu.org; Tue, 08 Feb 2022 07:29:53 -0500 Received: from eggs.gnu.org ([209.51.188.92]:40032) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nHPd1-0007yw-V5 for 53636@debbugs.gnu.org; Tue, 08 Feb 2022 07:29:52 -0500 Received: from [2001:470:142:3::e] (port=55396 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nHPcw-0002fE-MX; Tue, 08 Feb 2022 07:29:46 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=cZWaV3JXdt6P6gIaYLf/59J1WAPA6/jcLRfXfIcIusI=; b=KT2KAyqokeCa Z+7IkTWGJTcm1/G58DMHPzS9EOnWjOF4aZjE09bJ054p3CfdTGjoNgK+2lpk7eDQdmkt/AKz5havk eGoHxe3qdg3Zbfmh8Un88z68PD1Uu9CR9a7SFETd8XYeRu7D1o+/JXlhkiSPvwBAJHgVriphtQeLt DXBNz3ao4oZs2TO1w4D4Scwi7SQYMdWmnp43+0Y7BbJJihi9/Qt5qivAOJiPRI9aVgQv7SzNv98m7 YZR9RuNmVsI2ljwgqU2RtB9ZPhYgsycyRGeW1BcLR5UT2FxVoX+oR2mEj5rjNZAjRFJZUDhX7blVK glxDZgFs2wCy6XLDNNfUWw==; Received: from [87.69.77.57] (port=3976 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nHPcv-0007fJ-Mc; Tue, 08 Feb 2022 07:29:46 -0500 Date: Tue, 08 Feb 2022 14:29:35 +0200 Message-Id: <83o83hwngw.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87k0e5vqjm.fsf@gnus.org> (message from Lars Ingebrigtsen on Tue, 08 Feb 2022 07:08:29 +0100) References: <87o83tib13.fsf@gnu.org> <87mtjd8485.fsf@gnus.org> <83a6fd9glm.fsf@gnu.org> <835yq19dk1.fsf@gnu.org> <87czk97yt6.fsf@gnus.org> <8335l49jwu.fsf@gnu.org> <835ypz8zbm.fsf@gnu.org> <87fsp2v0ky.fsf@gnus.org> <83leyu73i8.fsf@gnu.org> <87k0edrvxm.fsf@gnus.org> <83sft15egx.fsf@gnu.org> <871r0loxr9.fsf@gnus.org> <83mtj85tm1.fsf@gnu.org> <87wnibn48c.fsf@gnus.org> <8335kz4tgu.fsf@gnu.org> <87ee4hg7g6.fsf@gnus.org> <83y22p21na.fsf@gnu.org> <871r0haqzr.fsf@gnus.org> <8335kw1n9u.fsf@gnu.org> <87mtj34mdj.fsf@gnus.org> <837da6yb0j.fsf@gnu.org> <87k0e5vqjm.fsf@gnus.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen > Cc: 53636@debbugs.gnu.org, tsdh@gnu.org > Date: Tue, 08 Feb 2022 07:08:29 +0100 > > Eli Zaretskii writes: > > > And what happens when you call make-frame from another buffer is not a > > bug? Is face-remapping-alist supposed to affect the buffer in which > > it is set on all frames or just on the single frame where > > face-remap-add-relative was called? > > I'm not sure. But the current behaviour (affecting all buffers on the > new frame) has to be a bug. > > >> The computation of the faces for the new frame. > > > > You mean init_frame_faces, which calls realize_basic_faces? Or do you > > mean some other kind of "face computation"? > > I don't know? I'm looking for the code that leads to the behaviour I > described. We need to agree on what "this behavior" is. Or at least I need to understand what you mean by that, in order to be able to provide information that could help you. So: in the scenario you've shown, do we want *scratch* to have its mode-line remapped on the new frame, or don't we? IOW, I agree that the result ideally shouldn't depend on the buffer where make-frame is called, but I need to know what is the desired behavior in order to find code which produces the undesired results. From unknown Tue Aug 19 05:12:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#53636: 29.0.50; face-remapping broken on master Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 08 Feb 2022 12:45:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 53636 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: martin rudalics Cc: larsi@gnus.org, 53636@debbugs.gnu.org, tsdh@gnu.org Received: via spool by 53636-submit@debbugs.gnu.org id=B53636.16443242548383 (code B ref 53636); Tue, 08 Feb 2022 12:45:01 +0000 Received: (at 53636) by debbugs.gnu.org; 8 Feb 2022 12:44:14 +0000 Received: from localhost ([127.0.0.1]:45763 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nHPqw-0002B9-7C for submit@debbugs.gnu.org; Tue, 08 Feb 2022 07:44:14 -0500 Received: from eggs.gnu.org ([209.51.188.92]:43240) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nHPqv-0002Ax-0J for 53636@debbugs.gnu.org; Tue, 08 Feb 2022 07:44:13 -0500 Received: from [2001:470:142:3::e] (port=55504 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nHPqp-0004tM-2x; Tue, 08 Feb 2022 07:44:07 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=s8czNajqHb8u7Hk4g+O16an4xSsTMA74V/WJG2FJeSE=; b=nlI4yAc7xJon 5tZ2ldg7Asid4qB4ESIUEBH/RJ03ZQ8qZaS8lBWDGHH7BkjM9HyKLhzuWgn2yOaae+Qsp7XZMwqpN 9N0Bz5omKRdTsOcNcFR7Lr0NtZX+mRGLQY9dnG3QOk+uStqGj4vJnwGdf4nfdpGQk/SR93EwGk5UO q2nr1jXsPvYV9G6IGglQRqOTXnl4oPTw9RC/ESeN1pErjeIjSgbTxSKhwqanw7l9bODeokT6zxrgt 0cEo/ncnWrXOrHyGS5tboGsyH99hOT0kzrX3Y4kZLLXA+bBrTHnJXr3264RIaR47Mt5GzA76cqPXS h/PeoH3k0Ybl2Lc0FTPj5w==; Received: from [87.69.77.57] (port=4777 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nHPof-0003ak-4Y; Tue, 08 Feb 2022 07:42:50 -0500 Date: Tue, 08 Feb 2022 14:41:43 +0200 Message-Id: <83leylwmwo.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <916b44c9-56dc-65b9-8894-cb5954e1bd9c@gmx.at> (message from martin rudalics on Tue, 8 Feb 2022 09:58:31 +0100) References: <87o83tib13.fsf@gnu.org> <87mtjd8485.fsf@gnus.org> <83a6fd9glm.fsf@gnu.org> <835yq19dk1.fsf@gnu.org> <87czk97yt6.fsf@gnus.org> <8335l49jwu.fsf@gnu.org> <835ypz8zbm.fsf@gnu.org> <87fsp2v0ky.fsf@gnus.org> <83leyu73i8.fsf@gnu.org> <87k0edrvxm.fsf@gnus.org> <83sft15egx.fsf@gnu.org> <871r0loxr9.fsf@gnus.org> <83mtj85tm1.fsf@gnu.org> <87wnibn48c.fsf@gnus.org> <8335kz4tgu.fsf@gnu.org> <87ee4hg7g6.fsf@gnus.org> <83y22p21na.fsf@gnu.org> <871r0haqzr.fsf@gnus.org> <8335kw1n9u.fsf@gnu.org> <87mtj34mdj.fsf@gnus.org> <837da6yb0j.fsf@gnu.org> <87k0e5vqjm.fsf@gnus.org> <916b44c9-56dc-65b9-8894-cb5954e1bd9c@gmx.at> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Tue, 8 Feb 2022 09:58:31 +0100 > Cc: 53636@debbugs.gnu.org, tsdh@gnu.org > From: martin rudalics > > >> And what happens when you call make-frame from another buffer is not a > >> bug? Is face-remapping-alist supposed to affect the buffer in which > >> it is set on all frames or just on the single frame where > >> face-remap-add-relative was called? > > > > I'm not sure. But the current behaviour (affecting all buffers on the > > new frame) has to be a bug. > > Face remapping has never been properly synchronized with windows and > frames. What's needed is a simple hierarchy window > window's buffer > > window's frame where the first should be implemented with the help of a > 'face-remapping' window parameter and the last with the help of a > 'face-remapping' frame parameter. Just like we (should) do for things > like the scroll bars or fringes. But we need a consensus on this first. I don't think I understand this remark. While what you describe might be a useful addition, I don't see why we must have it, or else. Surely, Emacs has gobs of features that depend only on the buffer, but not on the window nor the frame where that buffer is displayed? Why cannot we have a reasonable behavior with face-remapping-alist being specific to a buffer, no matter in what window we display it? From unknown Tue Aug 19 05:12:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#53636: 29.0.50; face-remapping broken on master Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 08 Feb 2022 18:25:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 53636 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: Eli Zaretskii Cc: larsi@gnus.org, 53636@debbugs.gnu.org, tsdh@gnu.org Received: via spool by 53636-submit@debbugs.gnu.org id=B53636.164434466921508 (code B ref 53636); Tue, 08 Feb 2022 18:25:02 +0000 Received: (at 53636) by debbugs.gnu.org; 8 Feb 2022 18:24:29 +0000 Received: from localhost ([127.0.0.1]:48615 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nHVAD-0005aq-Ff for submit@debbugs.gnu.org; Tue, 08 Feb 2022 13:24:29 -0500 Received: from mout.gmx.net ([212.227.17.22]:59071) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nHVAB-0005aY-Gn for 53636@debbugs.gnu.org; Tue, 08 Feb 2022 13:24:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1644344662; bh=7Vpfpv7R33veUKIGboK1tL2/qQ0oKeotv5AltV67XFs=; h=X-UI-Sender-Class:Date:Subject:To:Cc:References:From:In-Reply-To; b=Gdkq2T+spgR2uS3/mlS7WR9Jx0gqwAORTBVDZY63/m6jW1zidEP6ZHb4/UZbPDDX3 BwMz096K9QURFXJ1Cct3LDEEdhis3ApaOG1J1lJhyOBTe3qakoZ2xtNoqZQ6L+JvlW 5K/R67BqmpQQ7R5b/deMoWID1c6JkQwA/1KZTU98= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.102] ([212.95.5.151]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1M7b6b-1nPSi828bN-0085K2; Tue, 08 Feb 2022 19:24:21 +0100 Message-ID: <517f576b-6a6b-3e1e-b899-b67bcf9ad512@gmx.at> Date: Tue, 8 Feb 2022 19:24:19 +0100 MIME-Version: 1.0 Content-Language: en-US References: <87o83tib13.fsf@gnu.org> <87mtjd8485.fsf@gnus.org> <83a6fd9glm.fsf@gnu.org> <835yq19dk1.fsf@gnu.org> <87czk97yt6.fsf@gnus.org> <8335l49jwu.fsf@gnu.org> <835ypz8zbm.fsf@gnu.org> <87fsp2v0ky.fsf@gnus.org> <83leyu73i8.fsf@gnu.org> <87k0edrvxm.fsf@gnus.org> <83sft15egx.fsf@gnu.org> <871r0loxr9.fsf@gnus.org> <83mtj85tm1.fsf@gnu.org> <87wnibn48c.fsf@gnus.org> <8335kz4tgu.fsf@gnu.org> <87ee4hg7g6.fsf@gnus.org> <83y22p21na.fsf@gnu.org> <871r0haqzr.fsf@gnus.org> <8335kw1n9u.fsf@gnu.org> <87mtj34mdj.fsf@gnus.org> <837da6yb0j.fsf@gnu.org> <87k0e5vqjm.fsf@gnus.org> <916b44c9-56dc-65b9-8894-cb5954e1bd9c@gmx.at> <83leylwmwo.fsf@gnu.org> From: martin rudalics In-Reply-To: <83leylwmwo.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:VUgONNcWsCjhTaITyhcej1Z7ZOTwtcBHtUZO4jkxLWquDQT2vGn Yqp1HcjWICLZmb7ojhsAk1gFtuKd2SBlaHGOjX9nFL07Byw+C1t2AAw0NOWMuciAJjM/4N0 7Oilg/md19efTspjE2fr2DluY1Pyt9NMHZj6BT/vgbdUkPKa6oLaq856ZAY2ltMfhRK+Vov +OOIU2zOlysQzfo0s6LJw== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:u3dN/sj/AcM=:qoMiJv3LWOHumznJxr0LOO bn5jhqm9IzFZOZYC5ccNvkKIE640lqImBwyHXrffzPSkyKmU0E5M6RPkONBEcPoHbDqHR/ZVt hAfgLkN8fXEZY6vLWWkDDQtjLAaRZQxnIgtLjwwgHckBXz6icDghY5NbcteudMAG04AdQAAqX RxxvMfTH5xzzsJ1psP8UyT0mu68Iq1H1yHlu/96IrlN10NCWaDUD0viAYANP5EPeui1YsS68b zPmPIoTpubadCzd8A+Z0ZOjzt8nMUnN3i3WhBEDgPBH3SKoqDtfslbQKIHN0c+OtX7Zkc3B2e wtzIslHptdxeOm2BF1wcxLd4RyR3NbeDiKtYxdmxzELGAMVTpDBJBz78a9Ac2OeXjHsIiUcEM 5qDkS8Ok8WofRhXPOiK+6z0AZwQPkzUdx+662BPcasXzs8xe8bowrIubynwN/xQSYbBapSn6v r5BScB12wfNFSENmMP3i6SlxqFI31UTJwnxveIWlbb3A/wY+Cm6vMItpygX66ayKt5i2z1Njy mX9UwVngb0Y2inu33vO5j9AWeWmrroigUiBE2Vb60+fv8lPAUFPS8F3iOfk+WEV6BNrnYSBsS 9W/wO0/ZmBlKbrfXid9lqs0GesAgIZlQtkr/IDdoxqSM8u6pb9Hir6AIpN+//ac4amL0d/yjN +dH/++tIPGdP0YEFamCx4BBjlJ5RNiOq7p4ob4VwD5wp8WexNxC0uj+GZ6vAW/MnIdlVMm9PR +IuSFHY/ODw5F3+RrIOkWCUOquH3zuuL1vNt+9JG2Ah3Rxs4kgDS2WTHxuzM3RfEwdASKnStn dsjNsIC2c1y2LOWI7jYS6B7NenoGbnWxpdP0N5IUUrFDS1bVcXALZHdLIAI+vH/Z5Yk0RwmQc iWPAPSBOsu1UNSvGPjpRrTmagbcGlbLbEStY/w3h7UVZ1Az4UTVTEMP/C3MmefI17f+zHqU7t eNHkke3tdLcJ1mviZexKSYCJTIqZUAlmMIw1kDttoXUf/A9ywacJW+fVdDu6HNh/vRi0RH2un 4ogWRmc+fjWIOhp9E9tpMU2cTaMKb1l0Eh3Auv0ecykWb2UdmrSEVJDNRt8xWAhxCMGq1mMPD UNOy8rIJTrIyPs= X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) >> Face remapping has never been properly synchronized with windows and >> frames. What's needed is a simple hierarchy window > window's buffer > >> window's frame where the first should be implemented with the help of a >> 'face-remapping' window parameter and the last with the help of a >> 'face-remapping' frame parameter. Just like we (should) do for things >> like the scroll bars or fringes. But we need a consensus on this first. > > I don't think I understand this remark. While what you describe might > be a useful addition, I don't see why we must have it, or else. > Surely, Emacs has gobs of features that depend only on the buffer, but > not on the window nor the frame where that buffer is displayed? Why > cannot we have a reasonable behavior with face-remapping-alist being > specific to a buffer, no matter in what window we display it? What makes you think that this is not part of my proposal? What I mean is to have a clear rule how, for example, a buffer local setting of 'face-remapping-alist' may affect the creation of a new frame and the display of buffers in it. martin From unknown Tue Aug 19 05:12:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#53636: 29.0.50; face-remapping broken on master Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 08 Feb 2022 18:58:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 53636 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: martin rudalics Cc: larsi@gnus.org, 53636@debbugs.gnu.org, tsdh@gnu.org Received: via spool by 53636-submit@debbugs.gnu.org id=B53636.164434667725049 (code B ref 53636); Tue, 08 Feb 2022 18:58:01 +0000 Received: (at 53636) by debbugs.gnu.org; 8 Feb 2022 18:57:57 +0000 Received: from localhost ([127.0.0.1]:48642 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nHVga-0006Vx-MD for submit@debbugs.gnu.org; Tue, 08 Feb 2022 13:57:56 -0500 Received: from eggs.gnu.org ([209.51.188.92]:44646) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nHVgY-0006Vh-Tr for 53636@debbugs.gnu.org; Tue, 08 Feb 2022 13:57:55 -0500 Received: from [2001:470:142:3::e] (port=38086 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nHVgJ-0003Gb-RU; Tue, 08 Feb 2022 13:57:47 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=LheQUptVoXyy7/Euj5a7PoGbJeCo5d6RNijabRUWCyc=; b=HxJvxntjj9kX PcCJLGksXs1T4CJ5cDHxGpiLjK1TasCx5UiEVh4coUOIyF0FPdxq73ntqCkJvaekpmVjiat6hSb5o fQ9jKYNY93jVvnm02Vj6N7qefbQxP7w7Ac+kEIKZAZ+wnim4fIZj6xCWsT7loRx7k6FOHOSg8NtDk y37nRyolyIYR8XSjoQ8B6OfY1xlScE2S+W8/pdFOd4p8yZ+22q1DOfoJb8mp3S0O7V810HGy7l/2+ //HuP875d3ybQB1jE64Z8nxPHc0Y1TjjCr7Q2gXldfXMxqn+b8zs5mSxdl8wAwcIa79LPrZ1iVx8b L+053kTv6ZPBp8NUIHNCpQ==; Received: from [87.69.77.57] (port=4046 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nHVgI-0002X5-W0; Tue, 08 Feb 2022 13:57:39 -0500 Date: Tue, 08 Feb 2022 20:57:28 +0200 Message-Id: <835yppw5if.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <517f576b-6a6b-3e1e-b899-b67bcf9ad512@gmx.at> (message from martin rudalics on Tue, 8 Feb 2022 19:24:19 +0100) References: <87o83tib13.fsf@gnu.org> <87mtjd8485.fsf@gnus.org> <83a6fd9glm.fsf@gnu.org> <835yq19dk1.fsf@gnu.org> <87czk97yt6.fsf@gnus.org> <8335l49jwu.fsf@gnu.org> <835ypz8zbm.fsf@gnu.org> <87fsp2v0ky.fsf@gnus.org> <83leyu73i8.fsf@gnu.org> <87k0edrvxm.fsf@gnus.org> <83sft15egx.fsf@gnu.org> <871r0loxr9.fsf@gnus.org> <83mtj85tm1.fsf@gnu.org> <87wnibn48c.fsf@gnus.org> <8335kz4tgu.fsf@gnu.org> <87ee4hg7g6.fsf@gnus.org> <83y22p21na.fsf@gnu.org> <871r0haqzr.fsf@gnus.org> <8335kw1n9u.fsf@gnu.org> <87mtj34mdj.fsf@gnus.org> <837da6yb0j.fsf@gnu.org> <87k0e5vqjm.fsf@gnus.org> <916b44c9-56dc-65b9-8894-cb5954e1bd9c@gmx.at> <83leylwmwo.fsf@gnu.org> <517f576b-6a6b-3e1e-b899-b67bcf9ad512@gmx.at> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Tue, 8 Feb 2022 19:24:19 +0100 > Cc: larsi@gnus.org, 53636@debbugs.gnu.org, tsdh@gnu.org > From: martin rudalics > > >> Face remapping has never been properly synchronized with windows and > >> frames. What's needed is a simple hierarchy window > window's buffer > > >> window's frame where the first should be implemented with the help of a > >> 'face-remapping' window parameter and the last with the help of a > >> 'face-remapping' frame parameter. Just like we (should) do for things > >> like the scroll bars or fringes. But we need a consensus on this first. > > > > I don't think I understand this remark. While what you describe might > > be a useful addition, I don't see why we must have it, or else. > > Surely, Emacs has gobs of features that depend only on the buffer, but > > not on the window nor the frame where that buffer is displayed? Why > > cannot we have a reasonable behavior with face-remapping-alist being > > specific to a buffer, no matter in what window we display it? > > What makes you think that this is not part of my proposal? What I mean > is to have a clear rule how, for example, a buffer local setting of > 'face-remapping-alist' may affect the creation of a new frame and the > display of buffers in it. OK, then we need first to agree on what is the reasonable expected behavior in such cases. From unknown Tue Aug 19 05:12:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#53636: 29.0.50; face-remapping broken on master Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 09 Feb 2022 08:02:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 53636 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: Eli Zaretskii Cc: 53636@debbugs.gnu.org, tsdh@gnu.org Received: via spool by 53636-submit@debbugs.gnu.org id=B53636.16443937008673 (code B ref 53636); Wed, 09 Feb 2022 08:02:02 +0000 Received: (at 53636) by debbugs.gnu.org; 9 Feb 2022 08:01:40 +0000 Received: from localhost ([127.0.0.1]:49603 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nHhv2-0002FV-7y for submit@debbugs.gnu.org; Wed, 09 Feb 2022 03:01:40 -0500 Received: from quimby.gnus.org ([95.216.78.240]:60918) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nHhv0-00029w-2Z for 53636@debbugs.gnu.org; Wed, 09 Feb 2022 03:01:38 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=gcXU2OW2Mhb6IjzYTeshkRBCRjTSDMLk069vj0AU2LA=; b=SVFOgkQYRaSOKpG8JJUe81MzE2 6K0BeE0B2dLk9m3G+8D4NWiPIS/h/zivSkFIByWBMMWcqFNYzTkIU5GvZJR5zt8Ygum3B0BaG9V+e EuaD827udSvG8ukQNpVEd8AeWcB/UcTK+sJ3gbhjim8usexc7MJe8rqBNwxcB4VuTzUM=; Received: from [84.212.220.105] (helo=giant) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nHhur-0007kg-2W; Wed, 09 Feb 2022 09:01:32 +0100 From: Lars Ingebrigtsen References: <87o83tib13.fsf@gnu.org> <835yq19dk1.fsf@gnu.org> <87czk97yt6.fsf@gnus.org> <8335l49jwu.fsf@gnu.org> <835ypz8zbm.fsf@gnu.org> <87fsp2v0ky.fsf@gnus.org> <83leyu73i8.fsf@gnu.org> <87k0edrvxm.fsf@gnus.org> <83sft15egx.fsf@gnu.org> <871r0loxr9.fsf@gnus.org> <83mtj85tm1.fsf@gnu.org> <87wnibn48c.fsf@gnus.org> <8335kz4tgu.fsf@gnu.org> <87ee4hg7g6.fsf@gnus.org> <83y22p21na.fsf@gnu.org> <871r0haqzr.fsf@gnus.org> <8335kw1n9u.fsf@gnu.org> <87mtj34mdj.fsf@gnus.org> <837da6yb0j.fsf@gnu.org> <87k0e5vqjm.fsf@gnus.org> <83o83hwngw.fsf@gnu.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwAgMAAAAqbBEUAAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAADFBMVEVcFyGRTzbWtYL/ //+WhK8dAAAAAWJLR0QDEQxM8gAAAAd0SU1FB+YCCQc4BB68ILIAAAF5SURBVCjPTdHBTsQgEAbg fzalB0+QlIuP4FMwyeLBEySlsZ7NRvcp9A3axDXRkyausTylM1s1khT4gA4w4PzNIt8CdszAXsB3 gFsEdRLsA3ZLtvhCA64LqqJDQ6XWz3oUNPBeUGvMnSKz9J9MbiBBez/U+rCiGBYEBfmQPO0/cJop MJQuJpATZFAy9zGRzuQAj76zmAUhyJTtE80GSAHwzsWSFbaUYXnug2KyhyJlZF0220cnyzwxgebm IEctxVHEZoqHl+E4jg6EzRzvX3e7l6MXtDOPgtfFCM4Wt0aL/1Di1OK85h/0XvBWn/e1LjFknNXP qeOArAE2koxSAthLBiB4lIa9lfpCkgEQax+4YUUb9F6BdIQMBJayNsY4qSUDCNa3TyzzPemAv5n4 FIDkWbqWG6zFFHZ/IM346UG0C8R+3RTJ/IICTAxwQxJ08l1v0Vwdf/5XDEtaI99t5ak+ygmdonkv aYXscTmXXpG/5MB59noXcgrLBd+qV3T8tGh9swAAACV0RVh0ZGF0ZTpjcmVhdGUAMjAyMi0wMi0w OVQwNzo1NjowMyswMDowMLvRZ50AAAAldEVYdGRhdGU6bW9kaWZ5ADIwMjItMDItMDlUMDc6NTY6 MDMrMDA6MDDKjN8hAAAAAElFTkSuQmCC X-Now-Playing: Erik Satie's _Vexations_: "Vexations" Date: Wed, 09 Feb 2022 09:01:27 +0100 In-Reply-To: <83o83hwngw.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 08 Feb 2022 14:29:35 +0200") Message-ID: <87leykpiy0.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii writes: > So: in the scenario you've shown, do we want *scratch* to have its > mode-line remapped on the new frame, or don't we? IOW, I agree that > the result ideally shouldn't depend on the buffer where mak [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: > So: in the scenario you've shown, do we want *scratch* to have its > mode-line remapped on the new frame, or don't we? IOW, I agree that > the result ideally shouldn't depend on the buffer where make-frame is > called, but I need to know what is the desired behavior in order to > find code which produces the undesired results. Yes, I don't think that the results in the new frame should depend on the current buffer when `make-frame' is called. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From unknown Tue Aug 19 05:12:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#53636: 29.0.50; face-remapping broken on master Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 09 Feb 2022 13:59:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 53636 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: Lars Ingebrigtsen Cc: 53636@debbugs.gnu.org, tsdh@gnu.org Received: via spool by 53636-submit@debbugs.gnu.org id=B53636.164441508530914 (code B ref 53636); Wed, 09 Feb 2022 13:59:01 +0000 Received: (at 53636) by debbugs.gnu.org; 9 Feb 2022 13:58:05 +0000 Received: from localhost ([127.0.0.1]:50268 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nHnTx-00082Y-CR for submit@debbugs.gnu.org; Wed, 09 Feb 2022 08:58:05 -0500 Received: from eggs.gnu.org ([209.51.188.92]:59618) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nHnTs-00081z-Rb for 53636@debbugs.gnu.org; Wed, 09 Feb 2022 08:58:04 -0500 Received: from [2001:470:142:3::e] (port=57422 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nHnTY-0007kg-NB; Wed, 09 Feb 2022 08:57:55 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=j7qMUbE+PIOgg1jy0K+7nfzK6QLKFxOCGPjW/UCK39s=; b=hgUc3Ic773kJ sDGdiJazRP3/9Wlxu60jzIcr5Y//MjGxmG3ZzMP3YNmJ4+9IEEdXQ32OpvezsQFmxB7SZzyMawYfr OSvRdwea6dm33vvUVVUggKdvsT80f3zyAao4BdiurPTENq4IoYXDljgFPAw5mPgpAbbTm2JtDQsp8 hiSVNAJUeP/eoyN0Zkc0/Zgg566fNJ++B0/O91A9Bq3DfdnS9AfhBeZKqc8kTlAbnT8/9wrrsx/5N ghsZqkVSETNzXOyuKJ7tFmJBZLH+0vC+GrUOXn5rSrgzfC8cM42Sns10+Bdso2/hs0kTQzgpqVrB0 wC5srJoXjEMqBpFYXWi8rQ==; Received: from [87.69.77.57] (port=2715 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nHnTF-0000DL-RJ; Wed, 09 Feb 2022 08:57:24 -0500 Date: Wed, 09 Feb 2022 15:57:14 +0200 Message-Id: <83sfssuoqt.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87leykpiy0.fsf@gnus.org> (message from Lars Ingebrigtsen on Wed, 09 Feb 2022 09:01:27 +0100) References: <87o83tib13.fsf@gnu.org> <835yq19dk1.fsf@gnu.org> <87czk97yt6.fsf@gnus.org> <8335l49jwu.fsf@gnu.org> <835ypz8zbm.fsf@gnu.org> <87fsp2v0ky.fsf@gnus.org> <83leyu73i8.fsf@gnu.org> <87k0edrvxm.fsf@gnus.org> <83sft15egx.fsf@gnu.org> <871r0loxr9.fsf@gnus.org> <83mtj85tm1.fsf@gnu.org> <87wnibn48c.fsf@gnus.org> <8335kz4tgu.fsf@gnu.org> <87ee4hg7g6.fsf@gnus.org> <83y22p21na.fsf@gnu.org> <871r0haqzr.fsf@gnus.org> <8335kw1n9u.fsf@gnu.org> <87mtj34mdj.fsf@gnus.org> <837da6yb0j.fsf@gnu.org> <87k0e5vqjm.fsf@gnus.org> <83o83hwngw.fsf@gnu.org> <87leykpiy0.fsf@gnus.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen > Cc: 53636@debbugs.gnu.org, tsdh@gnu.org > Date: Wed, 09 Feb 2022 09:01:27 +0100 > > Eli Zaretskii writes: > > > So: in the scenario you've shown, do we want *scratch* to have its > > mode-line remapped on the new frame, or don't we? IOW, I agree that > > the result ideally shouldn't depend on the buffer where make-frame is > > called, but I need to know what is the desired behavior in order to > > find code which produces the undesired results. > > Yes, I don't think that the results in the new frame should depend on > the current buffer when `make-frame' is called. OK, I think I know where this happens. Let me dig a bit. From unknown Tue Aug 19 05:12:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#53636: 29.0.50; face-remapping broken on master Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 12 Feb 2022 12:21:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 53636 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: larsi@gnus.org Cc: 53636@debbugs.gnu.org, tsdh@gnu.org Received: via spool by 53636-submit@debbugs.gnu.org id=B53636.164466842510954 (code B ref 53636); Sat, 12 Feb 2022 12:21:01 +0000 Received: (at 53636) by debbugs.gnu.org; 12 Feb 2022 12:20:25 +0000 Received: from localhost ([127.0.0.1]:33676 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nIrO5-0002qb-D8 for submit@debbugs.gnu.org; Sat, 12 Feb 2022 07:20:25 -0500 Received: from eggs.gnu.org ([209.51.188.92]:34648) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nIrO4-0002qQ-7q for 53636@debbugs.gnu.org; Sat, 12 Feb 2022 07:20:24 -0500 Received: from [2001:470:142:3::e] (port=38246 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nIrNy-0005pl-Tz; Sat, 12 Feb 2022 07:20:18 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=4hDOZ7P6NXB6GotbccqgJGO+bosxgG8Gg1Rh23kuJ4A=; b=lUYmeVHDW1I6 uTBcviJjlk3m8/vF3HeGRM4xWTawMq3BNKwfuRMLYAYJU3NwssDcAwCJ/qvUtMuOCbnzJnM7ni1LK nXVgIp+bNi55z+QYYpJUkUziB9B7ojcNUTuy3J0H/jBhtdJhZRniQ5bNcoNKYxUAR7AusD4RKP4kj P6FHdgPHOdyU0FoDef2KmarpPOdog11QjsGiyMT31QzIcB1WIcF+7mCB/sEH2RBzxcuxUPQeIATG2 3gFeukbqPjqmtiPegBdtgEsW0GbAF7URGNATv8bx6+Na8tF1zkmeXmMh/uHfnrIigWmQXHfkdv5L/ noZX4b14bziAUAfVGnq+pA==; Received: from [87.69.77.57] (port=3441 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nIrNy-0000pT-BB; Sat, 12 Feb 2022 07:20:18 -0500 Date: Sat, 12 Feb 2022 14:20:11 +0200 Message-Id: <83a6ews2dg.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <83sfssuoqt.fsf@gnu.org> (message from Eli Zaretskii on Wed, 09 Feb 2022 15:57:14 +0200) References: <87o83tib13.fsf@gnu.org> <835yq19dk1.fsf@gnu.org> <87czk97yt6.fsf@gnus.org> <8335l49jwu.fsf@gnu.org> <835ypz8zbm.fsf@gnu.org> <87fsp2v0ky.fsf@gnus.org> <83leyu73i8.fsf@gnu.org> <87k0edrvxm.fsf@gnus.org> <83sft15egx.fsf@gnu.org> <871r0loxr9.fsf@gnus.org> <83mtj85tm1.fsf@gnu.org> <87wnibn48c.fsf@gnus.org> <8335kz4tgu.fsf@gnu.org> <87ee4hg7g6.fsf@gnus.org> <83y22p21na.fsf@gnu.org> <871r0haqzr.fsf@gnus.org> <8335kw1n9u.fsf@gnu.org> <87mtj34mdj.fsf@gnus.org> <837da6yb0j.fsf@gnu.org> <87k0e5vqjm.fsf@gnus.org> <83o83hwngw.fsf@gnu.org> <87leykpiy0.fsf@gnus.org> <83sfssuoqt.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Wed, 09 Feb 2022 15:57:14 +0200 > From: Eli Zaretskii > Cc: 53636@debbugs.gnu.org, tsdh@gnu.org > > > From: Lars Ingebrigtsen > > Cc: 53636@debbugs.gnu.org, tsdh@gnu.org > > Date: Wed, 09 Feb 2022 09:01:27 +0100 > > > > Eli Zaretskii writes: > > > > > So: in the scenario you've shown, do we want *scratch* to have its > > > mode-line remapped on the new frame, or don't we? IOW, I agree that > > > the result ideally shouldn't depend on the buffer where make-frame is > > > called, but I need to know what is the desired behavior in order to > > > find code which produces the undesired results. > > > > Yes, I don't think that the results in the new frame should depend on > > the current buffer when `make-frame' is called. > > OK, I think I know where this happens. Let me dig a bit. After digging into this, I'm sorry to say that this is unworkable: if a basic face inherits from some other face, and that other face is remapped via a buffer-local value of face-remapping-alist, the result will be unpredictable. For a simple demonstration of the unpredictable nature of the result, try this simple variation of your recipe, which just adds the last step: . emacs -Q . M-: (progn (face-remap-add-relative 'mode-line 'link-visited) (make-frame)) RET . C-x C-f src/xdisp.c RET Now all the buffers on the new frame have the mode line rendered with the default attributes, whereas all the buffers on the old frame suddenly get the mode line rendered with the link-visited face. IOW, just visiting a file on the new frame causes the mode line to be displayed differently than it was before you visit that file. This is due to how we handle the basic faces. There's "face realization" and "face look up". The former means we recompute all the face's attributes and load the necessary GUI resources (colors, fonts, etc.) from scratch; the latter means we just look up in the frame's face cache the attributes that were already computed. Face realization is obviously much more expensive than look up, so we only realize the basic faces when the frame's face cache is empty. A new frame has its cache empty, but there are other situations when the face cache could become empty: for example, when attributes of a named face change. So fundamentally, whether using a basic face will go through "face realization" or just "face look up" is unpredictable and can happen at any moment. Here is the crucial point: face inheritance is only considered in "face realization", not in "face look up". (That is why we empty the face cache when a named face is modified in the first place.) So if a basic face inherits from another face, and that other face is remapped, the effect of the remapping will make the result of "face realization" different from "face look up", although no face has changed the attributes. And since it is unpredictable when Emacs will use "face realization" and when it will settle with "face look up", you get unpredictable results. Moreover, Emacs expects a remapped face to have a different face ID internally (the ID is just the index of the remapped face in the frame's face cache). But "face realization" when a parent face is remapped doesn't yield a new face ID, it just influences the attributes recorded under the original face ID. The bottom line is that if "face realization" is called when the current buffer happens to be one with non-nil face-remapping-alist, the default face ID will use the attributes of the remapped face, but Emacs will not know that the face was effectively remapped. And that is the root cause of what you see in your recipes. Contrast this with a perfectly correct and expected behavior with these slightly modified recipes: (progn (face-remap-add-relative 'mode-line-active 'link-visited) (make-frame)) (progn (face-remap-add-relative 'mode-line-active 'link-visited) (switch-to-buffer "*Messages*") (make-frame)) Now the only mode line that is affected is the one of the *scratch* buffer (when it is the current buffer), no matter how many other files you visit after creating the new frame, and no matter which frame displays what buffer. So I can just reiterate what I said up-thread: basic faces cannot inherit from other faces, if we want to support remapping of those parent faces. Our internal infrastructure for handling the basic faces simply doesn't support this. From unknown Tue Aug 19 05:12:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#53636: 29.0.50; face-remapping broken on master Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 13 Feb 2022 08:21:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 53636 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: Eli Zaretskii Cc: 53636@debbugs.gnu.org, tsdh@gnu.org Received: via spool by 53636-submit@debbugs.gnu.org id=B53636.164474043710710 (code B ref 53636); Sun, 13 Feb 2022 08:21:02 +0000 Received: (at 53636) by debbugs.gnu.org; 13 Feb 2022 08:20:37 +0000 Received: from localhost ([127.0.0.1]:36191 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nJA7Z-0002mg-3e for submit@debbugs.gnu.org; Sun, 13 Feb 2022 03:20:37 -0500 Received: from quimby.gnus.org ([95.216.78.240]:50532) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nJA7W-0002mQ-Ky for 53636@debbugs.gnu.org; Sun, 13 Feb 2022 03:20:35 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=bD2/AnJNAJ5Rq47ZtYm/19oolD3xGaTap+cPquSnCs0=; b=Wn7GsQRduW5j5oTXCjDZN68DAX zZ863fiF6BoeBcSWdin67L8C5CnFiBshjim/9wcKptbxVyuAAnn6CIk5XL7RwCsuvL28DnW4at84t /tkkKQt809WPN6ciiHAtELEPA0YrQZWPipjVmzDi6lGYurus9bEQs1AI2TZe8XQupHos=; Received: from [84.212.220.105] (helo=giant) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nJA7N-0000VM-9u; Sun, 13 Feb 2022 09:20:28 +0100 From: Lars Ingebrigtsen References: <87o83tib13.fsf@gnu.org> <835ypz8zbm.fsf@gnu.org> <87fsp2v0ky.fsf@gnus.org> <83leyu73i8.fsf@gnu.org> <87k0edrvxm.fsf@gnus.org> <83sft15egx.fsf@gnu.org> <871r0loxr9.fsf@gnus.org> <83mtj85tm1.fsf@gnu.org> <87wnibn48c.fsf@gnus.org> <8335kz4tgu.fsf@gnu.org> <87ee4hg7g6.fsf@gnus.org> <83y22p21na.fsf@gnu.org> <871r0haqzr.fsf@gnus.org> <8335kw1n9u.fsf@gnu.org> <87mtj34mdj.fsf@gnus.org> <837da6yb0j.fsf@gnu.org> <87k0e5vqjm.fsf@gnus.org> <83o83hwngw.fsf@gnu.org> <87leykpiy0.fsf@gnus.org> <83sfssuoqt.fsf@gnu.org> <83a6ews2dg.fsf@gnu.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAElBMVEXY2MaplDYvPSg6 Wi1FaDD///8TZ0UnAAAAAWJLR0QF+G/pxwAAAAd0SU1FB+YCDQgNNB5qAsIAAAFmSURBVDjLnZTr kYMwDIS5EphJBZAKkBogq/5rutXLmFzy5zwwZPx59VhElp9dYSoGs7j9IYplSQDfRMM9gUB5KRCA BLtJKESEakOHsgYg0AiSxM9lKKiDsVhKAl9D4ZcmMB4YxZ52ASpH2ljHCEWkHQue3LLBFnAXpwP2 VJ3HWT4liyoFK+KGevlxJPoqhVdL7zwMPThYfjZIhSfSNJIAXa6WE1FBeJcA0UlZdoF0BBIm80BY NAGk+Wzi2C+FBUg7hVUd2YeDklhGmhS+K163uKKBp1BvUP8oUFUhFceoKhMjfrGqApiAhVevAdBA 3kKhRkKmHCrhqkY7BJPt6oarJ+aAyWWip8hYilJ4qG2TY4u11+y9GnxaBLLJPLgWb8Zz6DNGc30M 4KYRPOc5L0WDcz3XilKh3hW3HM/7qMfgfQEclAZEjwloA8Vd0X8AbpHF++bto6fjnUPmRDj9+1jW j+tf4Mv6BUmW4HKok9CDAAAAJXRFWHRkYXRlOmNyZWF0ZQAyMDIyLTAyLTEzVDA4OjEzOjUyKzAw OjAwV9N+0QAAACV0RVh0ZGF0ZTptb2RpZnkAMjAyMi0wMi0xM1QwODoxMzo1MiswMDowMCaOxm0A AAAASUVORK5CYII= X-Now-Playing: Sidsel Endresen's _Undertow_: "Distances" Date: Sun, 13 Feb 2022 09:20:24 +0100 In-Reply-To: <83a6ews2dg.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 12 Feb 2022 14:20:11 +0200") Message-ID: <87r187yy7r.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii writes: > So I can just reiterate what I said up-thread: basic faces cannot > inherit from other faces, if we want to support remapping of those > parent faces. Our internal infrastructure for handling the ba [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: > So I can just reiterate what I said up-thread: basic faces cannot > inherit from other faces, if we want to support remapping of those > parent faces. Our internal infrastructure for handling the basic > faces simply doesn't support this. Thanks for the analysis here -- it indeed seems like a much more complex problem than I'd assumed. I guess we should just document that face remapping doesn't work reliably when remapping parent faces to the basic faces? And for this bug report, the answer is "you have to use mode-line-active instead of mode-line". -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From unknown Tue Aug 19 05:12:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#53636: 29.0.50; face-remapping broken on master Resent-From: Tassilo Horn Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 13 Feb 2022 08:35:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 53636 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: Lars Ingebrigtsen Cc: Eli Zaretskii , 53636@debbugs.gnu.org Received: via spool by 53636-submit@debbugs.gnu.org id=B53636.164474126520954 (code B ref 53636); Sun, 13 Feb 2022 08:35:02 +0000 Received: (at 53636) by debbugs.gnu.org; 13 Feb 2022 08:34:25 +0000 Received: from localhost ([127.0.0.1]:36221 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nJAKv-0005Ru-JD for submit@debbugs.gnu.org; Sun, 13 Feb 2022 03:34:25 -0500 Received: from eggs.gnu.org ([209.51.188.92]:57782) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nJAKu-0005Ri-97 for 53636@debbugs.gnu.org; Sun, 13 Feb 2022 03:34:24 -0500 Received: from [2001:470:142:3::e] (port=60518 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nJAKo-0000Jq-PO; Sun, 13 Feb 2022 03:34:19 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:In-reply-to:Date:Subject:To:From: References; bh=0TtHOmmneQ9pyfU9h4Sz+VQfA8sUc3kNvcDUYQ2rMLE=; b=RQyCjISaqeSju9 5Yk7skXTip6jlf3/7bsiCIVBKUaMaKBGDNKz6xKo+fUHWJGG+MiS/nn9acd9QFMm2NPPKYKN55uuI vea1qjjCkyl13NKbPpWRanGfCsFOdmy1Tb1f6mennhPCSGgPWrKP5QgiIJK/clWbxlY+AjDnpCHJJ ODypjlkVv5uU5vc/P4C17qbIl2lfhK6tNXUbEUYaJqDpC16TzGrk6SsIpX0ultiQBv+D49LyA/bFn 3hxT83aRkScXf3O5koIdnAtdRBlfflUIDjQu9Lgq/3Jevc+/v57cUazAevGMZrtowM9LcEl/ZWqNH s7rCaRyPj+cCQHiXZEHA==; Received: from auth1-smtp.messagingengine.com ([66.111.4.227]:35231) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nJAKo-0003VH-Gg; Sun, 13 Feb 2022 03:34:18 -0500 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailauth.nyi.internal (Postfix) with ESMTP id 0D65827C0054; Sun, 13 Feb 2022 03:34:18 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Sun, 13 Feb 2022 03:34:18 -0500 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrieelgddukecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpehffgfhvffuffgjkfggtgesthdtredttdertdenucfhrhhomhepvfgrshhsihhl ohcujfhorhhnuceothhsughhsehgnhhurdhorhhgqeenucggtffrrghtthgvrhhnpeevve eikeetkeeviefgfeffiedvteeguddvffeuueduveegtddthedvhfeuveffhfenucevlhhu shhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhorhhnodhmvg hsmhhtphgruhhthhhpvghrshhonhgrlhhithihqdekieejfeekjeekgedqieefhedvleek qdhtshguhheppehgnhhurdhorhhgsehfrghsthhmrghilhdrfhhm X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 13 Feb 2022 03:34:16 -0500 (EST) References: <87o83tib13.fsf@gnu.org> <87fsp2v0ky.fsf@gnus.org> <83leyu73i8.fsf@gnu.org> <87k0edrvxm.fsf@gnus.org> <83sft15egx.fsf@gnu.org> <871r0loxr9.fsf@gnus.org> <83mtj85tm1.fsf@gnu.org> <87wnibn48c.fsf@gnus.org> <8335kz4tgu.fsf@gnu.org> <87ee4hg7g6.fsf@gnus.org> <83y22p21na.fsf@gnu.org> <871r0haqzr.fsf@gnus.org> <8335kw1n9u.fsf@gnu.org> <87mtj34mdj.fsf@gnus.org> <837da6yb0j.fsf@gnu.org> <87k0e5vqjm.fsf@gnus.org> <83o83hwngw.fsf@gnu.org> <87leykpiy0.fsf@gnus.org> <83sfssuoqt.fsf@gnu.org> <83a6ews2dg.fsf@gnu.org> <87r187yy7r.fsf@gnus.org> User-agent: mu4e 1.7.7; emacs 29.0.50 From: Tassilo Horn Date: Sun, 13 Feb 2022 09:31:32 +0100 In-reply-to: <87r187yy7r.fsf@gnus.org> Message-ID: <87wnhzyxkp.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Lars Ingebrigtsen writes: > And for this bug report, the answer is "you have to use > mode-line-active instead of mode-line". If that's the case, I'd submit a PR to the doom-themes package where I've encountered the problem, i.e., use `mode-line-active' instead of `mode-line' if `(facep 'mode-line-active)'. Bye, Tassilo From unknown Tue Aug 19 05:12:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#53636: 29.0.50; face-remapping broken on master Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 13 Feb 2022 11:59:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 53636 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: Lars Ingebrigtsen Cc: 53636@debbugs.gnu.org, tsdh@gnu.org Received: via spool by 53636-submit@debbugs.gnu.org id=B53636.164475350624213 (code B ref 53636); Sun, 13 Feb 2022 11:59:02 +0000 Received: (at 53636) by debbugs.gnu.org; 13 Feb 2022 11:58:26 +0000 Received: from localhost ([127.0.0.1]:36729 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nJDWL-0006IT-NB for submit@debbugs.gnu.org; Sun, 13 Feb 2022 06:58:25 -0500 Received: from eggs.gnu.org ([209.51.188.92]:44030) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nJDWJ-0006IF-Hy for 53636@debbugs.gnu.org; Sun, 13 Feb 2022 06:58:23 -0500 Received: from [2001:470:142:3::e] (port=34352 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nJDWC-0005ZO-0y; Sun, 13 Feb 2022 06:58:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=cGbXnRBowhHKCcNs0sst0T+FBhNETzyzxui7u2Mim6A=; b=rKEHY1vDWZB9 onlPIUHEAGytVucv6w3HPQyVW/5/sULhVZDkTNkjzl7c/kM8Ux7gSnF+B9HYaBKPk2jKbdKlZY/2M iBDhurTdsoEPP2HVpoLuYBmUfrPo9JyjJXnae+R2zNIUjVpJROvv/2TAtMN5w7f2VTsGsf0azAMX3 8L0ScQ5Kh6oIh1EF0bA190TTdUsBOEx2HxubzTKWcLJsuGtDzsA+jqJWaNXOw4PperDRCTiNsE3MW 0mQq4g3MnTpUZ4jiz5/t8wGTMsZVKI2ddAoyByOZiDelAmQ2hnJQmVGoaVJbn/aB5MXOKoT0VwP/7 mWSGH0qmdGkRaqAr3MB1JA==; Received: from [87.69.77.57] (port=2373 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nJDW5-0003sY-0R; Sun, 13 Feb 2022 06:58:10 -0500 Date: Sun, 13 Feb 2022 13:58:06 +0200 Message-Id: <83iltjq8q9.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87r187yy7r.fsf@gnus.org> (message from Lars Ingebrigtsen on Sun, 13 Feb 2022 09:20:24 +0100) References: <87o83tib13.fsf@gnu.org> <835ypz8zbm.fsf@gnu.org> <87fsp2v0ky.fsf@gnus.org> <83leyu73i8.fsf@gnu.org> <87k0edrvxm.fsf@gnus.org> <83sft15egx.fsf@gnu.org> <871r0loxr9.fsf@gnus.org> <83mtj85tm1.fsf@gnu.org> <87wnibn48c.fsf@gnus.org> <8335kz4tgu.fsf@gnu.org> <87ee4hg7g6.fsf@gnus.org> <83y22p21na.fsf@gnu.org> <871r0haqzr.fsf@gnus.org> <8335kw1n9u.fsf@gnu.org> <87mtj34mdj.fsf@gnus.org> <837da6yb0j.fsf@gnu.org> <87k0e5vqjm.fsf@gnus.org> <83o83hwngw.fsf@gnu.org> <87leykpiy0.fsf@gnus.org> <83sfssuoqt.fsf@gnu.org> <83a6ews2dg.fsf@gnu.org> <87r187yy7r.fsf@gnus.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen > Cc: 53636@debbugs.gnu.org, tsdh@gnu.org > Date: Sun, 13 Feb 2022 09:20:24 +0100 > > I guess we should just document that face remapping doesn't work > reliably when remapping parent faces to the basic faces? Yes, I think so. > And for this bug report, the answer is "you have to use mode-line-active > instead of mode-line". Right. From unknown Tue Aug 19 05:12:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#53636: 29.0.50; face-remapping broken on master Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 14 Feb 2022 10:39:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 53636 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: Eli Zaretskii Cc: 53636@debbugs.gnu.org, tsdh@gnu.org Received: via spool by 53636-submit@debbugs.gnu.org id=B53636.16448351298057 (code B ref 53636); Mon, 14 Feb 2022 10:39:02 +0000 Received: (at 53636) by debbugs.gnu.org; 14 Feb 2022 10:38:49 +0000 Received: from localhost ([127.0.0.1]:39935 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nJYkr-00025t-9W for submit@debbugs.gnu.org; Mon, 14 Feb 2022 05:38:49 -0500 Received: from quimby.gnus.org ([95.216.78.240]:34880) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nJYkn-00025X-5X for 53636@debbugs.gnu.org; Mon, 14 Feb 2022 05:38:48 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=+0gK1ZFEbCbeMScw4jrQWUWvIllwo+xceTxFj518qGc=; b=Kpz5rEotvXGHsyRFld+sMGdZ2p SHSIix+JzB5FYSchhEaXqv3sDzxBpJNAGLug3m0IgS9KEK8UIhZcymsq8a52CQ0LaxTJ1EmTO/p2y powfTcmohOAjCUAVYfs4tRWnV3RoxwckBVpFebC4j1VOLz9H03Eg6R/TXt57v9/bJCZA=; Received: from [84.212.220.105] (helo=giant) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nJYkd-0006xT-Uv; Mon, 14 Feb 2022 11:38:38 +0100 From: Lars Ingebrigtsen References: <87o83tib13.fsf@gnu.org> <83leyu73i8.fsf@gnu.org> <87k0edrvxm.fsf@gnus.org> <83sft15egx.fsf@gnu.org> <871r0loxr9.fsf@gnus.org> <83mtj85tm1.fsf@gnu.org> <87wnibn48c.fsf@gnus.org> <8335kz4tgu.fsf@gnu.org> <87ee4hg7g6.fsf@gnus.org> <83y22p21na.fsf@gnu.org> <871r0haqzr.fsf@gnus.org> <8335kw1n9u.fsf@gnu.org> <87mtj34mdj.fsf@gnus.org> <837da6yb0j.fsf@gnu.org> <87k0e5vqjm.fsf@gnus.org> <83o83hwngw.fsf@gnu.org> <87leykpiy0.fsf@gnus.org> <83sfssuoqt.fsf@gnu.org> <83a6ews2dg.fsf@gnu.org> <87r187yy7r.fsf@gnus.org> <83iltjq8q9.fsf@gnu.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAALVBMVEUzLzBMTDdBPTRn ajqZoDivxTjb5S4PDQ01O0M5SExVWVg7RDlBPUKLlG7///+ItTPNAAAAAWJLR0QOb70wTwAAAAd0 SU1FB+YCDgoeNoC6WfwAAAGDSURBVDjL1ZOxboMwEIYPltDSShyeqi6EN7BM+wLQvkBDnyBh7paV EbaM0C7MFkjJ1oglc6S+QfMutREQkxB16dJDGPF/uv/OJxvgHwS64F5imnUBMOo6J5KjywRvRm1V 1d0pIjqgPyx81UyXMkGZEgyAIHbrQHG0vBbYNowCNp4Alj6e8GtM/gxMzoGRynU5ApIGnJtI3SiW b+2vud423zTjeZ5nqw5c83YOiZDzWFi1QMNuQEYSNzU6YN31xVcqAFz31eNL+4uPOzdkkzfiacof wWeSXGVxCbzYSYkXx+QEkrS4Lb85lABVMXBOy8PXoar4jlcnk3gvS873APtyCNKVKdY1nMU2+6g3 23ykfbPGDaGIA/FevLWNG8bQdgag1igVgyQMFd2Rp88LfUQNVSAvkPYUBjNx1imxVCPhEQSLkHoU iQ2OIhPqhVE0R2SEUeyOrsYIoew5iiKRwBglHUCcIsVHAV4IMp/2G9FRF8B7jcIFC3xU2kIZxIvm oc8s6MEPo/hbI+3QpFIAAAAldEVYdGRhdGU6Y3JlYXRlADIwMjItMDItMTRUMTA6MzA6NTQrMDA6 MDC9rYNHAAAAJXRFWHRkYXRlOm1vZGlmeQAyMDIyLTAyLTE0VDEwOjMwOjU0KzAwOjAwzPA7+wAA AABJRU5ErkJggg== X-Now-Playing: Spitfire's _Still in a Dream (3)_: "Translucent" Date: Mon, 14 Feb 2022 11:38:35 +0100 In-Reply-To: <83iltjq8q9.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 13 Feb 2022 13:58:06 +0200") Message-ID: <878rudu40k.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii writes: >> I guess we should just document that face remapping doesn't work >> reliably when remapping parent faces to the basic faces? > > Yes, I think so. > >> And for this bug report, the answer is "you ha [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: >> I guess we should just document that face remapping doesn't work >> reliably when remapping parent faces to the basic faces? > > Yes, I think so. > >> And for this bug report, the answer is "you have to use mode-line-active >> instead of mode-line". > > Right. Now done, and I added a section in the "incompatible lisp changes" to the NEWS file. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 14 05:38:56 2022 Received: (at control) by debbugs.gnu.org; 14 Feb 2022 10:38:56 +0000 Received: from localhost ([127.0.0.1]:39938 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nJYky-00026D-GX for submit@debbugs.gnu.org; Mon, 14 Feb 2022 05:38:56 -0500 Received: from quimby.gnus.org ([95.216.78.240]:34894) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nJYkx-000261-5b for control@debbugs.gnu.org; Mon, 14 Feb 2022 05:38:55 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Subject:From:To:Message-Id:Date:Sender:Reply-To:Cc: MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=P3BjbO5w2GRuA+oAlZ3odcr0GQUeTFB4/eZ5nqKnVh4=; b=QE5KPoZs9gHhxKUePa6Qlfjv8z jnOelaGzatTlMqbMN7u+it53C95wl8YaUEJCseNRil13Kg3dPQRdWMqMZyro3HeK/O+D44cP0CJKV b21o10DlmLJUaGZkmTvNVeT60L43R5TPZ/AjMwKYF+SyQuOVy3dPZBt1Zt4A91B1VPSk=; Received: from [84.212.220.105] (helo=giant) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nJYko-0006xb-Jl for control@debbugs.gnu.org; Mon, 14 Feb 2022 11:38:49 +0100 Date: Mon, 14 Feb 2022 11:38:45 +0100 Message-Id: <877d9xu40a.fsf@gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #53636 X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: close 53636 quit Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) close 53636 quit From unknown Tue Aug 19 05:12:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#53636: 29.0.50; face-remapping broken on master Resent-From: Tassilo Horn Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 15 Feb 2022 09:33:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 53636 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: Lars Ingebrigtsen Cc: Eli Zaretskii , 53636@debbugs.gnu.org Received: via spool by 53636-submit@debbugs.gnu.org id=B53636.164491756610086 (code B ref 53636); Tue, 15 Feb 2022 09:33:02 +0000 Received: (at 53636) by debbugs.gnu.org; 15 Feb 2022 09:32:46 +0000 Received: from localhost ([127.0.0.1]:43517 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nJuCT-0002cc-MW for submit@debbugs.gnu.org; Tue, 15 Feb 2022 04:32:45 -0500 Received: from eggs.gnu.org ([209.51.188.92]:48208) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nJuCT-0002cQ-0t for 53636@debbugs.gnu.org; Tue, 15 Feb 2022 04:32:45 -0500 Received: from [2001:470:142:3::e] (port=51878 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nJuCN-0008Sk-NR; Tue, 15 Feb 2022 04:32:39 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:In-reply-to:Date:Subject:To:From: References; bh=ybIIl2Tw1c9NY3AEN5a4B7W++LNI2fMSH7/GjHndgWI=; b=as4MSq8G8ozlf+ Ni5+1OEduaJcldnKn+x6QBP2tckP0IS0me/2puBzR9ktfMaQftHa+0ajql+K3DlVEjJGffEiBIwTx doAtd8tcTuxkEIY3aYsipTLqwoFZi3MSgXJ/1B+FAn+k7718Ozb3zwiJhJzwsXwHajBWyKsEEAQBU LBe2HpENm2mErsiRGSuyPEafE9GH5bMlIRvvgz8U5woeWFewOQpBl5d4VI6L5eq/yoeqXxEHJ4i2p Le371yuFFgJwQH2hdXL4B0is9HS12XovJfAzZmRCHNLnflq6+nlFXuvbOwXU/RxX266zt22e3MSEs 5x7d9aIzMnJp1vBQEXqg==; Received: from auth2-smtp.messagingengine.com ([66.111.4.228]:58453) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nJuCN-000457-Cq; Tue, 15 Feb 2022 04:32:39 -0500 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailauth.nyi.internal (Postfix) with ESMTP id A277B27C0060; Tue, 15 Feb 2022 04:32:38 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Tue, 15 Feb 2022 04:32:38 -0500 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrjeeggddtgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpehffgfhvffuffgjkfggtgesthdtredttdertdenucfhrhhomhepvfgrshhsihhl ohcujfhorhhnuceothhsughhsehgnhhurdhorhhgqeenucggtffrrghtthgvrhhnpedvhf duveeuvddtveeifeefhedvffeugeehjedtfffhieevledvgfehueejgfehffenucffohhm rghinhepghhithhhuhgsrdgtohhmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrg hmpehmrghilhhfrhhomhepthhhohhrnhdomhgvshhmthhprghuthhhphgvrhhsohhnrghl ihhthidqkeeijeefkeejkeegqdeifeehvdelkedqthhsughhpeepghhnuhdrohhrghesfh grshhtmhgrihhlrdhfmh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 15 Feb 2022 04:32:37 -0500 (EST) References: <87o83tib13.fsf@gnu.org> <83leyu73i8.fsf@gnu.org> <87k0edrvxm.fsf@gnus.org> <83sft15egx.fsf@gnu.org> <871r0loxr9.fsf@gnus.org> <83mtj85tm1.fsf@gnu.org> <87wnibn48c.fsf@gnus.org> <8335kz4tgu.fsf@gnu.org> <87ee4hg7g6.fsf@gnus.org> <83y22p21na.fsf@gnu.org> <871r0haqzr.fsf@gnus.org> <8335kw1n9u.fsf@gnu.org> <87mtj34mdj.fsf@gnus.org> <837da6yb0j.fsf@gnu.org> <87k0e5vqjm.fsf@gnus.org> <83o83hwngw.fsf@gnu.org> <87leykpiy0.fsf@gnus.org> <83sfssuoqt.fsf@gnu.org> <83a6ews2dg.fsf@gnu.org> <87r187yy7r.fsf@gnus.org> <87wnhzyxkp.fsf@gnu.org> User-agent: mu4e 1.7.7; emacs 29.0.50 From: Tassilo Horn Date: Tue, 15 Feb 2022 10:31:57 +0100 In-reply-to: <87wnhzyxkp.fsf@gnu.org> Message-ID: <87h790scek.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Tassilo Horn writes: >> And for this bug report, the answer is "you have to use >> mode-line-active instead of mode-line". > > If that's the case, I'd submit a PR to the doom-themes package where > I've encountered the problem, i.e., use `mode-line-active' instead of > `mode-line' if `(facep 'mode-line-active)'. Done in https://github.com/doomemacs/themes/pull/705 which has already been merged. Bye, Tassilo