From unknown Fri Sep 05 15:34:44 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#73862 <73862@debbugs.gnu.org> To: bug#73862 <73862@debbugs.gnu.org> Subject: Status: [PATCH] Add `header-line-active` and `header-line-inactive` faces. Reply-To: bug#73862 <73862@debbugs.gnu.org> Date: Fri, 05 Sep 2025 22:34:44 +0000 retitle 73862 [PATCH] Add `header-line-active` and `header-line-inactive` f= aces. reassign 73862 emacs submitter 73862 trevor.m.murphy@gmail.com severity 73862 wishlist tag 73862 patch thanks From debbugs-submit-bounces@debbugs.gnu.org Fri Oct 18 08:57:35 2024 Received: (at submit) by debbugs.gnu.org; 18 Oct 2024 12:57:35 +0000 Received: from localhost ([127.0.0.1]:37510 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t1mXt-0006Nk-U9 for submit@debbugs.gnu.org; Fri, 18 Oct 2024 08:57:34 -0400 Received: from lists.gnu.org ([209.51.188.17]:51104) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t1mXr-0006Nb-EU for submit@debbugs.gnu.org; Fri, 18 Oct 2024 08:57:32 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1t1mXU-0002BO-Q0 for bug-gnu-emacs@gnu.org; Fri, 18 Oct 2024 08:57:08 -0400 Received: from mail-pl1-x632.google.com ([2607:f8b0:4864:20::632]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1t1mXS-0002QX-8X for bug-gnu-emacs@gnu.org; Fri, 18 Oct 2024 08:57:08 -0400 Received: by mail-pl1-x632.google.com with SMTP id d9443c01a7336-20bb39d97d1so19553345ad.2 for ; Fri, 18 Oct 2024 05:57:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1729256224; x=1729861024; darn=gnu.org; h=mime-version:message-id:date:subject:to:from:from:to:cc:subject :date:message-id:reply-to; bh=ZkfWiR8Cq4GMjCCPxwzXK8KZbXu7zNQQPpFHrN+Jk+M=; b=GGtFdz5/F6ZCCWQfyoodYa5MLwHyM+vIAXQr92U518deuRBduAllmKT20C8J2XWVbR 3bXfQw+Wt7U3t4X0H6a/hsxAhaybwp6tkKbw4FFizpSpBwwI1GDcwi9SFcS1knrkpXlm oLiO1per/uipECaEluahOLtQWZhG0SU8Zmskk8jvUddmgYuv9iBNrPmobkCxzaILGz7W p6N7eGXT21D0A8wyjjTV09wkY+mfn7YaHk+VF2AiltNzFLQ7yYuD+JslwkBdNrLP07yP Ye6Bpy8LpxcjoJkgyIp2q9Wt2rdP5EOsH+AFRC2a4xKUkbV+YgmQ+JJsb5spvjXml0qX xhfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729256224; x=1729861024; h=mime-version:message-id:date:subject:to:from:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=ZkfWiR8Cq4GMjCCPxwzXK8KZbXu7zNQQPpFHrN+Jk+M=; b=HmIane0apTM9uiPM7tyqylKpVz0Eu5+DdoFEakfs9Z4yePY1O4iRgYAn1blSYWA1r1 2IYoBtStQ6GgYgKeHhvRY6fGppxzJx8g9/OLCIYZkJuehT2Xr9jC439L6PvtYgX9P8vf F8tmNlCPp3BfLMRaenNKyuZUE+V2QIxmz4DRDdUDDSxkE3iT8g8o5FC7tHi38RN6InRg 8KG8AccomDinBJYWrhORTa643ePQYZn2FWZY+R4c1YhTUZRFkJ6uWf9vlAMMzQOb9T5w IFKnWDwO7DJHcgZTGZHbzkS7ewx2siF6oua1xRlllSSiQ+5Layr5NwGqu4U59MdrmAx3 xN1A== X-Gm-Message-State: AOJu0YyD4Vk+0zWpYehiiD9FabBRIBQ3L9sPWn0I2hseBpZl4CS+CXfX EvZ9PkFQShMQwxRqTNBn5OLuZheN6lppPNn9K4PhCE2ntmDIsQdLAETDUA== X-Google-Smtp-Source: AGHT+IFiztVnFXnaUfjLKPdY0eZ6oyDAB5Q9VFM3905/8FrVJuaaTUOQTNAvYAJNU0BFhftmXsP+kQ== X-Received: by 2002:a17:903:1104:b0:20b:6458:ec83 with SMTP id d9443c01a7336-20e5a728324mr28780545ad.4.1729256223858; Fri, 18 Oct 2024 05:57:03 -0700 (PDT) Received: from yoga ([2601:1c2:b00:dac0::2868]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-20e5a752abasm12074605ad.75.2024.10.18.05.57.02 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 18 Oct 2024 05:57:03 -0700 (PDT) From: trevor.m.murphy@gmail.com To: bug-gnu-emacs@gnu.org Subject: [PATCH] Add `header-line-active` and `header-line-inactive` faces. Date: Fri, 18 Oct 2024 05:56:32 -0700 Message-ID: <87y12lo9hb.fsf@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Received-SPF: pass client-ip=2607:f8b0:4864:20::632; envelope-from=trevor.m.murphy@gmail.com; helo=mail-pl1-x632.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit 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: -2.3 (--) --=-=-= Content-Type: text/plain Tags: patch Got a quick feature request. Over the years I've put more and more information into the header line, and at some point I wanted to get that quick visual indicator of selected vs non-selected windows when I glanced at the header as I already got from the mode line. This was surprisingly hard to achieve! For a few years I used an ugly `buffer-list-update-hook` hack. Then a few months ago I got adventurous and found that it actually wasn't as hard as I'd feared to hack these into the C source. The new faces both inherit from the current `header-line` face, so there shouldn't be any visible impact if users don't customize the new faces. For cases like mine it's easy to customize header-line-inactive to inherit from mode-line-inactive. Thanks in advance for your attention and feedback, Trevor In GNU Emacs 29.4 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.43, cairo version 1.18.0) Repository revision: a92669f7ae7de3172cf883d15af9d7bb9bda7dd9 Repository branch: main System Description: Arch Linux Configured using: 'configure --with-pgtk --with-native-compilation=aot --sysconfdir=/etc --prefix=/usr --libexecdir=/usr/lib --with-tree-sitter --localstatedir=/var --with-cairo --disable-build-details --with-harfbuzz --with-libsystemd --with-modules 'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=3 -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -g -ffile-prefix-map=/home/trevor/pkgbuilds/abs/emacs/src=/usr/src/debug/emacs -flto=auto' 'LDFLAGS=-Wl,-O1 -Wl,--sort-common -Wl,--as-needed -Wl,-z,relro -Wl,-z,now -Wl,-z,pack-relative-relocs -flto=auto' 'CXXFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=3 -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -Wp,-D_GLIBCXX_ASSERTIONS -g -ffile-prefix-map=/home/trevor/pkgbuilds/abs/emacs/src=/usr/src/debug/emacs -flto=auto'' --=-=-= Content-Type: text/patch Content-Disposition: attachment; filename=0001-Add-new-header-line-active-and-header-line-inactive-.patch >From 1000a0bac791dbe31da627389db9755fddf51243 Mon Sep 17 00:00:00 2001 From: Trevor Murphy Date: Thu, 17 Oct 2024 15:51:14 -0700 Subject: [PATCH] Add new `header-line-active` and `header-line-inactive` faces. This is all intended to parallel the mode-line-active and mode-line-inactive distinction. * src/dispextern.h (CURRENT_HEADER_LINE_ACTIVE_FACE_ID_3, CURRENT_HEADER_LINE_ACTIVE_FACE_ID): new macros based on mode line equivalents (face_id): new face IDs * src/xdisp.c (window_box_height, pos_visible_p, init_iterator, window_text_pixel_size, display_mode_lines, display_mode_line, format-mode-line): replace all uses of HEADER_LINE_FACE_ID with either a new macro or the new face IDs * src/xfaces.c (syms_of_xfaces): new lisp symbols (lookup_basic_face, realize_basic_faces): map new face IDs to their lisp symbols * lisp/faces.el (header-line-active, header-line-inactive): new deffaces --- lisp/faces.el | 24 ++++++++++++++++++++++++ src/dispextern.h | 33 +++++++++++++++++++++++++++++++-- src/xdisp.c | 45 ++++++++++++++++++++++++++------------------- src/xfaces.c | 8 ++++++-- 4 files changed, 87 insertions(+), 23 deletions(-) diff --git a/lisp/faces.el b/lisp/faces.el index 21c3e663c6e..25a93d0ed7a 100644 --- a/lisp/faces.el +++ b/lisp/faces.el @@ -2821,6 +2821,30 @@ Use the face `mode-line-highlight' for features that can be selected." :version "28.1" :group 'basic-faces) +(defface header-line-active + '((t :inherit header-line)) + "Face for the selected header line. +This inherits from the `header-line' face." + :version "29.5" + :group 'mode-line-faces + :group 'basic-faces) + +(defface header-line-inactive + '((default + :inherit header-line) + (((class color) (min-colors 88) (background light)) + :weight light + :box (:line-width -1 :color "grey75" :style nil) + :foreground "grey20" :background "grey90") + (((class color) (min-colors 88) (background dark) ) + :weight light + :box (:line-width -1 :color "grey40" :style nil) + :foreground "grey80" :background "grey30")) + "Basic header line face for non-selected windows." + :version "29.5" + :group 'mode-line-faces + :group 'basic-faces) + (defface vertical-border '((((type tty)) :inherit mode-line-inactive)) "Face used for vertical window dividers on ttys." diff --git a/src/dispextern.h b/src/dispextern.h index cc248a4472e..0d4c0a6c67e 100644 --- a/src/dispextern.h +++ b/src/dispextern.h @@ -1561,6 +1561,34 @@ struct glyph_string : estimate_mode_line_height \ (XFRAME ((W)->frame), CURRENT_MODE_LINE_ACTIVE_FACE_ID (W))))) +/* Return the desired face id for the header line of a window, depending + on whether the window is selected or not, or if the window is the + scrolling window for the currently active minibuffer window. + + Due to the way display_mode_lines manipulates with the contents of + selected_window, this macro needs three arguments: SELW which is + compared against the current value of selected_window, MBW which is + compared against minibuf_window (if SELW doesn't match), and SCRW + which is compared against minibuf_selected_window (if MBW matches). */ + +#define CURRENT_HEADER_LINE_ACTIVE_FACE_ID_3(SELW, MBW, SCRW) \ + ((!mode_line_in_non_selected_windows \ + || (SELW) == XWINDOW (selected_window) \ + || (minibuf_level > 0 \ + && !NILP (minibuf_selected_window) \ + && (MBW) == XWINDOW (minibuf_window) \ + && (SCRW) == XWINDOW (minibuf_selected_window))) \ + ? HEADER_LINE_ACTIVE_FACE_ID \ + : HEADER_LINE_INACTIVE_FACE_ID) + + +/* Return the desired face id for the header line of window W. */ + +#define CURRENT_HEADER_LINE_ACTIVE_FACE_ID(W) \ + CURRENT_HEADER_LINE_ACTIVE_FACE_ID_3(W, \ + XWINDOW (selected_window), \ + W) + /* Return the current height of the header line of window W. If not known from W->header_line_height, look at W's current glyph matrix, or return an estimation based on the height of the font of the face `header-line'. */ @@ -1572,7 +1600,7 @@ struct glyph_string = (MATRIX_HEADER_LINE_HEIGHT ((W)->current_matrix) \ ? MATRIX_HEADER_LINE_HEIGHT ((W)->current_matrix) \ : estimate_mode_line_height \ - (XFRAME ((W)->frame), HEADER_LINE_FACE_ID)))) + (XFRAME ((W)->frame), CURRENT_HEADER_LINE_ACTIVE_FACE_ID (W))))) /* Return the current height of the tab line of window W. If not known from W->tab_line_height, look at W's current glyph matrix, or return @@ -1893,7 +1921,8 @@ enum face_id MODE_LINE_INACTIVE_FACE_ID, TOOL_BAR_FACE_ID, FRINGE_FACE_ID, - HEADER_LINE_FACE_ID, + HEADER_LINE_ACTIVE_FACE_ID, + HEADER_LINE_INACTIVE_FACE_ID, SCROLL_BAR_FACE_ID, BORDER_FACE_ID, CURSOR_FACE_ID, diff --git a/src/xdisp.c b/src/xdisp.c index c74e81a3933..98bc157c789 100644 --- a/src/xdisp.c +++ b/src/xdisp.c @@ -1358,7 +1358,7 @@ window_box_height (struct window *w) if (hl_row && hl_row->mode_line_p) height -= hl_row->height; else - height -= estimate_mode_line_height (f, HEADER_LINE_FACE_ID); + height -= estimate_mode_line_height (f, CURRENT_HEADER_LINE_ACTIVE_FACE_ID (w)); } } @@ -1753,7 +1753,7 @@ pos_visible_p (struct window *w, ptrdiff_t charpos, int *x, int *y, = window_parameter (w, Qheader_line_format); w->header_line_height - = display_mode_line (w, HEADER_LINE_FACE_ID, + = display_mode_line (w, CURRENT_HEADER_LINE_ACTIVE_FACE_ID (w), NILP (window_header_line_format) ? BVAR (current_buffer, header_line_format) : window_header_line_format); @@ -3197,13 +3197,14 @@ CHECK_WINDOW_END (struct window *w) BASE_FACE_ID is the id of a base face to use. It must be one of DEFAULT_FACE_ID for normal text, MODE_LINE_ACTIVE_FACE_ID, - MODE_LINE_INACTIVE_FACE_ID, or HEADER_LINE_FACE_ID for displaying - mode lines, or TOOL_BAR_FACE_ID for displaying the tool-bar. + MODE_LINE_INACTIVE_FACE_ID, HEADER_LINE_ACTIVE_FACE_ID, or + HEADER_LINE_INACTIVE_FACE_ID for displaying mode lines, or + TOOL_BAR_FACE_ID for displaying the tool-bar. If ROW is null and BASE_FACE_ID is equal to MODE_LINE_ACTIVE_FACE_ID, - MODE_LINE_INACTIVE_FACE_ID, or HEADER_LINE_FACE_ID, the iterator - will be initialized to use the corresponding mode line glyph row of - the desired matrix of W. */ + MODE_LINE_INACTIVE_FACE_ID, HEADER_LINE_ACTIVE_FACE_ID, or + HEADER_LINE_INACTIVE_FACE_ID the iterator will be initialized to use + the corresponding mode line glyph row of the desired matrix of W. */ void init_iterator (struct it *it, struct window *w, @@ -3251,7 +3252,8 @@ init_iterator (struct it *it, struct window *w, row = MATRIX_MODE_LINE_ROW (w->desired_matrix); else if (base_face_id == TAB_LINE_FACE_ID) row = MATRIX_TAB_LINE_ROW (w->desired_matrix); - else if (base_face_id == HEADER_LINE_FACE_ID) + else if (base_face_id == HEADER_LINE_ACTIVE_FACE_ID + || base_face_id == HEADER_LINE_INACTIVE_FACE_ID) { /* Header line row depends on whether tab line is enabled. */ w->desired_matrix->tab_line_p = window_wants_tab_line (w); @@ -11854,7 +11856,7 @@ window_text_pixel_size (Lisp_Object window, Lisp_Object from, Lisp_Object to, Lisp_Object window_header_line_format = window_parameter (w, Qheader_line_format); - y = y + display_mode_line (w, HEADER_LINE_FACE_ID, + y = y + display_mode_line (w, CURRENT_HEADER_LINE_ACTIVE_FACE_ID (w), NILP (window_header_line_format) ? BVAR (current_buffer, header_line_format) : window_header_line_format); @@ -27453,11 +27455,11 @@ display_mode_lines (struct window *w) line_number_displayed = false; w->column_number_displayed = -1; + struct window *sel_w = XWINDOW (old_selected_window); if (window_wants_mode_line (w)) { Lisp_Object window_mode_line_format = window_parameter (w, Qmode_line_format); - struct window *sel_w = XWINDOW (old_selected_window); /* Select mode line face based on the real selected window. */ display_mode_line (w, @@ -27485,7 +27487,7 @@ display_mode_lines (struct window *w) Lisp_Object window_header_line_format = window_parameter (w, Qheader_line_format); - display_mode_line (w, HEADER_LINE_FACE_ID, + display_mode_line (w, CURRENT_HEADER_LINE_ACTIVE_FACE_ID_3 (sel_w, sel_w, w), NILP (window_header_line_format) ? BVAR (current_buffer, header_line_format) : window_header_line_format); @@ -27500,11 +27502,12 @@ display_mode_lines (struct window *w) } -/* Display mode or header/tab line of window W. FACE_ID specifies - which line to display; it is either MODE_LINE_ACTIVE_FACE_ID, - HEADER_LINE_FACE_ID or TAB_LINE_FACE_ID. FORMAT is the - mode/header/tab line format to display. Value is the pixel height - of the mode/header/tab line displayed. */ +/* Display mode or header/tab line of window W. FACE_ID specifies which + line to display; it is either MODE_LINE_ACTIVE_FACE_ID, + HEADER_LINE_ACTIVE_FACE_ID, HEADER_LINE_INACTIVE_FACE_ID, or + TAB_LINE_FACE_ID. FORMAT is the mode/header/tab line format to + display. Value is the pixel height of the mode/header/tab line + displayed. */ static int display_mode_line (struct window *w, enum face_id face_id, Lisp_Object format) @@ -27525,7 +27528,8 @@ display_mode_line (struct window *w, enum face_id face_id, Lisp_Object format) it.glyph_row->tab_line_p = true; w->desired_matrix->tab_line_p = true; } - else if (face_id == HEADER_LINE_FACE_ID) + else if (face_id == HEADER_LINE_ACTIVE_FACE_ID + || face_id == HEADER_LINE_INACTIVE_FACE_ID) w->desired_matrix->header_line_p = true; /* FIXME: This should be controlled by a user option. But @@ -27544,7 +27548,9 @@ display_mode_line (struct window *w, enum face_id face_id, Lisp_Object format) record_unwind_save_match_data (); if (NILP (Vmode_line_compact) - || face_id == HEADER_LINE_FACE_ID || face_id == TAB_LINE_FACE_ID) + || face_id == HEADER_LINE_ACTIVE_FACE_ID + || face_id == HEADER_LINE_INACTIVE_FACE_ID + || face_id == TAB_LINE_FACE_ID) { mode_line_target = MODE_LINE_DISPLAY; display_mode_element (&it, 0, 0, 0, format, Qnil, false); @@ -28313,7 +28319,8 @@ are the selected window and the WINDOW's buffer). */) ? MODE_LINE_ACTIVE_FACE_ID : MODE_LINE_INACTIVE_FACE_ID) : EQ (face, Qmode_line_active) ? MODE_LINE_ACTIVE_FACE_ID : EQ (face, Qmode_line_inactive) ? MODE_LINE_INACTIVE_FACE_ID - : EQ (face, Qheader_line) ? HEADER_LINE_FACE_ID + : EQ (face, Qheader_line_active) ? HEADER_LINE_ACTIVE_FACE_ID + : EQ (face, Qheader_line_inactive) ? HEADER_LINE_INACTIVE_FACE_ID : EQ (face, Qtab_line) ? TAB_LINE_FACE_ID : EQ (face, Qtab_bar) ? TAB_BAR_FACE_ID : EQ (face, Qtool_bar) ? TOOL_BAR_FACE_ID diff --git a/src/xfaces.c b/src/xfaces.c index e248279e9b7..f6264802fa4 100644 --- a/src/xfaces.c +++ b/src/xfaces.c @@ -5117,7 +5117,8 @@ lookup_basic_face (struct window *w, struct frame *f, int face_id) case DEFAULT_FACE_ID: name = Qdefault; break; case MODE_LINE_ACTIVE_FACE_ID: name = Qmode_line_active; break; case MODE_LINE_INACTIVE_FACE_ID: name = Qmode_line_inactive; break; - case HEADER_LINE_FACE_ID: name = Qheader_line; break; + case HEADER_LINE_ACTIVE_FACE_ID: name = Qheader_line_active; break; + case HEADER_LINE_INACTIVE_FACE_ID: name = Qheader_line_inactive; break; case TAB_LINE_FACE_ID: name = Qtab_line; break; case TAB_BAR_FACE_ID: name = Qtab_bar; break; case TOOL_BAR_FACE_ID: name = Qtool_bar; break; @@ -5867,7 +5868,8 @@ realize_basic_faces (struct frame *f) realize_named_face (f, Qmode_line_inactive, MODE_LINE_INACTIVE_FACE_ID); realize_named_face (f, Qtool_bar, TOOL_BAR_FACE_ID); realize_named_face (f, Qfringe, FRINGE_FACE_ID); - realize_named_face (f, Qheader_line, HEADER_LINE_FACE_ID); + realize_named_face (f, Qheader_line_active, HEADER_LINE_ACTIVE_FACE_ID); + realize_named_face (f, Qheader_line_inactive, HEADER_LINE_INACTIVE_FACE_ID); realize_named_face (f, Qscroll_bar, SCROLL_BAR_FACE_ID); realize_named_face (f, Qborder, BORDER_FACE_ID); realize_named_face (f, Qcursor, CURSOR_FACE_ID); @@ -7438,6 +7440,8 @@ syms_of_xfaces (void) DEFSYM (Qfringe, "fringe"); DEFSYM (Qtab_line, "tab-line"); DEFSYM (Qheader_line, "header-line"); + DEFSYM (Qheader_line_inactive, "header-line-inactive"); + DEFSYM (Qheader_line_active, "header-line-active"); DEFSYM (Qscroll_bar, "scroll-bar"); DEFSYM (Qmenu, "menu"); DEFSYM (Qcursor, "cursor"); -- 2.46.2 --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Sun Oct 27 06:47:39 2024 Received: (at 73862) by debbugs.gnu.org; 27 Oct 2024 10:47:39 +0000 Received: from localhost ([127.0.0.1]:44003 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t50o6-00078X-RM for submit@debbugs.gnu.org; Sun, 27 Oct 2024 06:47:39 -0400 Received: from eggs.gnu.org ([209.51.188.92]:47666) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t50o5-00078K-C2 for 73862@debbugs.gnu.org; Sun, 27 Oct 2024 06:47:37 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1t50nR-0006QO-An; Sun, 27 Oct 2024 06:46:57 -0400 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=BB35g0hzpztjHqAwte7y6nEZXyiiBO3OR/36mhwCD30=; b=ZqJGON0NiPPv Zf3rkPzTBOCypq2RiiSYqXiiqEp/Y63+F/uPpDVIbQT2bvZZI/w0R0pKGo5Yz5/sJrzaOdHBZMSZF Ahf2k8+Q9jCdMMhWZQ1wNO8Xnr0ACTNGaTvNH26Rd2MU5fqxIZKSYVsLXyAacxVqd5IXGT4icvXlE SO2yzFo2BPRCXRztInFclO4ycrQW7jJZ8DrhnQUsFjYc6yD+x1SdtajPYVOWRLz/e0p3Y5P/71Ze5 JwWOU+QXn5SxpZaZMDUOZY40o+v2RW53Jbqxh3xhGDsAiU3LiFCCcwq+OUiliTTiOtkKq8lUWI3Qn UzvDLRm0OTuLOSucflit1g==; Date: Sun, 27 Oct 2024 12:46:53 +0200 Message-Id: <86a5epakma.fsf@gnu.org> From: Eli Zaretskii To: trevor.m.murphy@gmail.com In-Reply-To: <87y12lo9hb.fsf@gmail.com> (trevor.m.murphy@gmail.com) Subject: Re: bug#73862: [PATCH] Add `header-line-active` and `header-line-inactive` faces. References: <87y12lo9hb.fsf@gmail.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 73862 Cc: 73862@debbugs.gnu.org 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: trevor.m.murphy@gmail.com > Date: Fri, 18 Oct 2024 05:56:32 -0700 > > Over the years I've put more and more information into the header line, and at some point I wanted to get that quick visual indicator of selected vs non-selected windows when I glanced at the header as I already got from the mode line. > > This was surprisingly hard to achieve! For a few years I used an ugly `buffer-list-update-hook` hack. Then a few months ago I got adventurous and found that it actually wasn't as hard as I'd feared to hack these into the C source. > > The new faces both inherit from the current `header-line` face, so there shouldn't be any visible impact if users don't customize the new faces. For cases like mine it's easy to customize header-line-inactive to inherit from mode-line-inactive. > > Thanks in advance for your attention and feedback, Thanks. This changeset needs the appropriate changes in the Emacs user manual (which lists the standard faces in "Standard Faces"), and also a NEWS entry that announces the change. Also, did you verify that modes which use header-line and customize the header-line face still work as before after this change, both when the window is selected and non-selected? From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 03 01:53:49 2024 Received: (at control) by debbugs.gnu.org; 3 Nov 2024 05:53:49 +0000 Received: from localhost ([127.0.0.1]:58084 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t7TYb-0000qP-Fq for submit@debbugs.gnu.org; Sun, 03 Nov 2024 01:53:49 -0400 Received: from mail-ed1-f43.google.com ([209.85.208.43]:51558) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t7TYZ-0000qH-Dw for control@debbugs.gnu.org; Sun, 03 Nov 2024 01:53:48 -0400 Received: by mail-ed1-f43.google.com with SMTP id 4fb4d7f45d1cf-5ced6a3f246so10390a12.3 for ; Sat, 02 Nov 2024 22:53:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1730613167; x=1731217967; darn=debbugs.gnu.org; h=to:subject:message-id:date:mime-version:from:from:to:cc:subject :date:message-id:reply-to; bh=QmCa+hiPrtDKBsz49cyC25NF7u/NEnGB6r1Uu4xP9xA=; b=FQFBcZ85549VKMdHsHQWyZ4naG7+wZAsps/IkRaF4NvlvkNdmd8PMd3Gnf3PNyfXow zqTdNabBL+d9B8jtKbvdQ73weURg7sjsMJYJAbJ2COZs/FxOBKSvAkIfntNcH0KZwb3a USOpIQ4Y+UdADpy2XIQlGVvyuV5DnAc/VjvMk6safVBXTqMbtIW68NOHAlW2BiAA5oNW vYtIqfW1En4l40yYEhXdyVidP2dsvAE8GEIt6V6gDF3WFYzs3inQh21icONt1G0kXa9D hTpU7xaXHreTOeLxynLDf059JF5Nn2wIoMkpb0aekHUnNfQD3qbuNmuk4WUvxq6ZUS2b dv+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730613167; x=1731217967; h=to:subject:message-id:date:mime-version:from:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=QmCa+hiPrtDKBsz49cyC25NF7u/NEnGB6r1Uu4xP9xA=; b=OWi0yvt1kYZ/LiM8QjIzuEbaB/6KqJFWzXgkgkRe1zvn5C0TWiHcfmAOB7A7XAAXSU /1IbMoaSB5Oxb8+q9dsXKCw9lPGdpFc1W8zq8Vb+mS8hlzn/VLVMWnHcr2Y3Y4IaYjvT HwoaAyJzBn6Zo471muRosRAgVNkIv8KkH0ryV4v5+Aja29tAXzBHBE5EZWekmKjI5J3n UQ86iVEVPE6h8uLIiqeLj0f2Qhr5Q8tLckongZv17sq0PETdcaMN+XiEPJvvDQRXKtmq h+tKyIRb27HjS0x/YYrvcVc6ZSqVirGuvjpfZw+73C8K9dJ29wM64cIkIqmAaqCl1QUh CCKg== X-Gm-Message-State: AOJu0Yyh6rjxu7PtsDlEPNCcK181XMfTndyIiUNJR59Vv37CNXtSlzxS rwZy0d5RjDXBI/tewXF9IawVaTmJuKhpsOZqMV1vg/pVBpUaa1Bi3JBVTnIWedONFdNOByBfiTN mitfFuQkBfZJBj3WoEj9IDv4wVqbnMQ== X-Google-Smtp-Source: AGHT+IFKvz/f5o4R69/EzMtEbHR2AhDOG9Kc8ti4W/iq4apeXLHWwKAZWEi2+Wkt3WwQSJix/lk6BgrHIgxlwDiVSpw= X-Received: by 2002:a05:6402:2788:b0:5ca:c616:347d with SMTP id 4fb4d7f45d1cf-5ceb93a1802mr6074313a12.36.1730613166715; Sat, 02 Nov 2024 22:52:46 -0700 (PDT) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Sat, 2 Nov 2024 22:52:46 -0700 From: Stefan Kangas MIME-Version: 1.0 Date: Sat, 2 Nov 2024 22:52:46 -0700 Message-ID: Subject: control message for bug #73862 To: control@debbugs.gnu.org Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) 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: -1.0 (-) severity 73862 wishlist quit From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 09 04:38:03 2024 Received: (at 73862) by debbugs.gnu.org; 9 Nov 2024 09:38:03 +0000 Received: from localhost ([127.0.0.1]:53448 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t9hut-0002Td-GI for submit@debbugs.gnu.org; Sat, 09 Nov 2024 04:38:03 -0500 Received: from eggs.gnu.org ([209.51.188.92]:41328) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t9huq-0002T2-F3 for 73862@debbugs.gnu.org; Sat, 09 Nov 2024 04:38:01 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1t9hul-0003rU-4l; Sat, 09 Nov 2024 04:37: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=UndJLmBgROauaPd4gSNEtXaImcRcHwGSxBkpRj8no7E=; b=Ra1Z41pDjdO9 xzFl4e3arDGsLF6GgMiHt3Ci/1nH0iMBIsXegqw7T1AFr3bzlIN9SJo9SFNFHFZgienxx6QHYejcY KtVrv6gAbr5CAs0HgcBeA+Ex+g9betP1Qeh5l0ay1qlFQKia4KSOOIok+teBmYK1LASjYjWHyyIjN L3CjcvDmfjrzmaO2+esjS0zKRVZgM1BeugH2QgiGll2jPJP7K7NT6+JuBIPVBynQK9NImBBTw9HZA 1Cq71E3egsTYVar8OuVz+VzwK3EGkuvzZmT4z8K6EvktJGzPP3RbGcoj76xm9AcrXQSPKXQUrsfH+ G3LAbJe767HKbDpGtf46hg==; Date: Sat, 09 Nov 2024 11:37:51 +0200 Message-Id: <86ttcgn3ww.fsf@gnu.org> From: Eli Zaretskii To: trevor.m.murphy@gmail.com In-Reply-To: <86a5epakma.fsf@gnu.org> (message from Eli Zaretskii on Sun, 27 Oct 2024 12:46:53 +0200) Subject: Re: bug#73862: [PATCH] Add `header-line-active` and `header-line-inactive` faces. References: <87y12lo9hb.fsf@gmail.com> <86a5epakma.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 73862 Cc: 73862@debbugs.gnu.org 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 (---) > Cc: 73862@debbugs.gnu.org > Date: Sun, 27 Oct 2024 12:46:53 +0200 > From: Eli Zaretskii > > > From: trevor.m.murphy@gmail.com > > Date: Fri, 18 Oct 2024 05:56:32 -0700 > > > > Over the years I've put more and more information into the header line, and at some point I wanted to get that quick visual indicator of selected vs non-selected windows when I glanced at the header as I already got from the mode line. > > > > This was surprisingly hard to achieve! For a few years I used an ugly `buffer-list-update-hook` hack. Then a few months ago I got adventurous and found that it actually wasn't as hard as I'd feared to hack these into the C source. > > > > The new faces both inherit from the current `header-line` face, so there shouldn't be any visible impact if users don't customize the new faces. For cases like mine it's easy to customize header-line-inactive to inherit from mode-line-inactive. > > > > Thanks in advance for your attention and feedback, > > Thanks. This changeset needs the appropriate changes in the Emacs > user manual (which lists the standard faces in "Standard Faces"), and > also a NEWS entry that announces the change. > > Also, did you verify that modes which use header-line and customize > the header-line face still work as before after this change, both when > the window is selected and non-selected? Ping! Trevor, could you please answer the above question, and provide an updated patch with documentation changes? I'd like to install this as soon as these issues are resolved. From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 11 01:13:24 2024 Received: (at 73862) by debbugs.gnu.org; 11 Nov 2024 06:13:24 +0000 Received: from localhost ([127.0.0.1]:57564 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tANfv-0005K3-Gz for submit@debbugs.gnu.org; Mon, 11 Nov 2024 01:13:24 -0500 Received: from mail-ed1-f50.google.com ([209.85.208.50]:59821) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tANfs-0005Ju-93 for 73862@debbugs.gnu.org; Mon, 11 Nov 2024 01:13:21 -0500 Received: by mail-ed1-f50.google.com with SMTP id 4fb4d7f45d1cf-5c9388a00cfso5340455a12.3 for <73862@debbugs.gnu.org>; Sun, 10 Nov 2024 22:13:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1731305539; x=1731910339; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=7BEm9KNQLPWXydwA58fDUwony8D5/3BerctP2Ltd+Fo=; b=BTSyKjWyndy4r1wKd7bcnVZYrlpO4kwe1ZK3c2cgi45Hgkb19chb4Pank6CCilsFDX QZACam0IFvDgSxfgnchgw3P3Z+z5wC+h+I5obr27OJuAYh53d7+fXG8kQqeznrEz5v5L I3SDQ60UQu5d9qpdJt0DTa8JlOUj+cO4ujf72KWWaPdSEm7ccW0UtipOUHI4yCT+zgpg efVDiw3n4kL/QVBl52iXpD6iWRDt4DQJ4gfCGKcqMfO05gOyrCxZGKXaKE2LAqkbxlk/ qth0AaiNEP/MldXqRnvq3TtgXv7ucoXpRq9LILYteTk7+JiECYeU9Ms1wgsQN9nHlTy1 A8Gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731305539; x=1731910339; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=7BEm9KNQLPWXydwA58fDUwony8D5/3BerctP2Ltd+Fo=; b=jy934AnWIfVVfiepXRAoke26YzQqougOWm7lpBuO4E3KdySnikGvO17qzh5zWyZBxA zgbTMfjhVk03NItStSyBwOaIg5HYQF96GPjkqXu5jrcN21+E1U17gQLY3tZc9Ja9/WlZ vd/x5SJoFWWKIYiMZqnYjA8AzcreQO4ASEX6ca6hko/g8kjP8V7nP+GDZH7NMXMMB9BL WOD+jGFk6uQpIt7kix2u2LsxCAf6PA9S+Uhr638U4Kr1bMpQ+VkEX/nZCuGxsNiTORKg 8mACFp+rWemtI3fA1CfWnsz7RzKZQKqz62La6Replh1JN/E5Oqiv1tQW3Hx1T4ctxNyM VS7A== X-Gm-Message-State: AOJu0Yw20IzODqXu+rXgcPkX2wn4GPXPIGfQbXGoSogpLCxHHyf1kq8S s9P6ikY40iV/+YrqC6mm4t8kS2CYmRF8retdGQWkNlvVvHguOkWtpLMUcTsraD9IFpFjbWV3V6L K7eRbiVirjnO6eyhUPootSs+uzF1k8zPA X-Google-Smtp-Source: AGHT+IE8D9ypNWU5NH4ZlwqvYASCfEmH5xsCgallvcqUyhlVpCDh2B1+82qwObtzDIBl4D4eOpn7oe4nq+ohfzqSECw= X-Received: by 2002:a05:6402:40d2:b0:5cf:9e5:7d1a with SMTP id 4fb4d7f45d1cf-5cf0a2fad8emr8509224a12.1.1731305539249; Sun, 10 Nov 2024 22:12:19 -0800 (PST) MIME-Version: 1.0 References: <87y12lo9hb.fsf@gmail.com> <86a5epakma.fsf@gnu.org> <86ttcgn3ww.fsf@gnu.org> In-Reply-To: <86ttcgn3ww.fsf@gnu.org> From: Trevor Murphy Date: Sun, 10 Nov 2024 22:11:30 -0800 Message-ID: Subject: Re: bug#73862: [PATCH] Add `header-line-active` and `header-line-inactive` faces. To: Eli Zaretskii Content-Type: multipart/mixed; boundary="000000000000aaccda06269cfbec" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 73862 Cc: 73862@debbugs.gnu.org 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.0 (-) --000000000000aaccda06269cfbec Content-Type: multipart/alternative; boundary="000000000000aaccd006269cfbea" --000000000000aaccd006269cfbea Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi! Thanks for your patience, attached please find the updated patch. I've added documentation and a NEWS entry modeled off of similar commits. When I put together the original patch I included a non-trivial value for the default header-line-inactive (copied from mode-line-inactive) as a visual indicator for the new face. Happy to take it out. In this updated patch, header-line-inactive just inherits from header-line. I tested by looking at selected and not-selected Info buffers with emacs -Q both patched and unpatched, in both graphical and terminal. On Sat, Nov 9, 2024 at 1:37=E2=80=AFAM Eli Zaretskii wrote: > > Cc: 73862@debbugs.gnu.org > > Date: Sun, 27 Oct 2024 12:46:53 +0200 > > From: Eli Zaretskii > > > > > From: trevor.m.murphy@gmail.com > > > Date: Fri, 18 Oct 2024 05:56:32 -0700 > > > > > > Over the years I've put more and more information into the header > line, and at some point I wanted to get that quick visual indicator of > selected vs non-selected windows when I glanced at the header as I alread= y > got from the mode line. > > > > > > This was surprisingly hard to achieve! For a few years I used an ugl= y > `buffer-list-update-hook` hack. Then a few months ago I got adventurous > and found that it actually wasn't as hard as I'd feared to hack these int= o > the C source. > > > > > > The new faces both inherit from the current `header-line` face, so > there shouldn't be any visible impact if users don't customize the new > faces. For cases like mine it's easy to customize header-line-inactive t= o > inherit from mode-line-inactive. > > > > > > Thanks in advance for your attention and feedback, > > > > Thanks. This changeset needs the appropriate changes in the Emacs > > user manual (which lists the standard faces in "Standard Faces"), and > > also a NEWS entry that announces the change. > > > > Also, did you verify that modes which use header-line and customize > > the header-line face still work as before after this change, both when > > the window is selected and non-selected? > > Ping! Trevor, could you please answer the above question, and provide > an updated patch with documentation changes? I'd like to install this > as soon as these issues are resolved. > --=20 Trevor Murphy --000000000000aaccd006269cfbea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi!=C2=A0 Thanks for your patience, attached please f= ind the updated patch.=C2=A0 I've added documentation and a NEWS entry = modeled off of similar commits.=C2=A0=C2=A0

When I= put together the original patch I included a non-trivial value for the def= ault header-line-inactive (copied from mode-line-inactive) as a visual indi= cator for the new face.=C2=A0 Happy to take it out.=C2=A0 In this updated p= atch, header-line-inactive just inherits from header-line.=C2=A0 I tested b= y looking at selected and not-selected Info buffers with emacs -Q both patc= hed and unpatched, in both graphical and terminal.

On Sat, Nov 9, = 2024 at 1:37=E2=80=AFAM Eli Zaretskii <e= liz@gnu.org> wrote:
> Cc: 73862@debbugs.gnu.org
> Date: Sun, 27 Oct 2024 12:46:53 +0200
> From: Eli Zaretskii <eliz@gnu.org>
>
> > From: trevor.m.murphy@gmail.com
> > Date: Fri, 18 Oct 2024 05:56:32 -0700
> >
> > Over the years I've put more and more information into the he= ader line, and at some point I wanted to get that quick visual indicator of= selected vs non-selected windows when I glanced at the header as I already= got from the mode line.
> >
> > This was surprisingly hard to achieve!=C2=A0 For a few years I us= ed an ugly `buffer-list-update-hook` hack.=C2=A0 Then a few months ago I go= t adventurous and found that it actually wasn't as hard as I'd fear= ed to hack these into the C source.
> >
> > The new faces both inherit from the current `header-line` face, s= o there shouldn't be any visible impact if users don't customize th= e new faces.=C2=A0 For cases like mine it's easy to customize header-li= ne-inactive to inherit from mode-line-inactive.
> >
> > Thanks in advance for your attention and feedback,
>
> Thanks.=C2=A0 This changeset needs the appropriate changes in the Emac= s
> user manual (which lists the standard faces in "Standard Faces&qu= ot;), and
> also a NEWS entry that announces the change.
>
> Also, did you verify that modes which use header-line and customize > the header-line face still work as before after this change, both when=
> the window is selected and non-selected?

Ping! Trevor, could you please answer the above question, and provide
an updated patch with documentation changes?=C2=A0 I'd like to install = this
as soon as these issues are resolved.


--
Trevor Murphy
--000000000000aaccd006269cfbea-- --000000000000aaccda06269cfbec Content-Type: text/x-patch; charset="US-ASCII"; name="0001-Add-new-header-line-active-and-header-line-inactive-.patch" Content-Disposition: attachment; filename="0001-Add-new-header-line-active-and-header-line-inactive-.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_m3cmjhuz0 RnJvbSBmZWQxNzllNjZiNTIxZDMwZTlhN2YzOTMyMzBjZTEwNTczMzAyOTczIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBUcmV2b3IgTXVycGh5IDx0cmV2b3IubS5tdXJwaHlAZ21haWwu Y29tPgpEYXRlOiBUaHUsIDE3IE9jdCAyMDI0IDE1OjUxOjE0IC0wNzAwClN1YmplY3Q6IFtQQVRD SF0gQWRkIG5ldyBgaGVhZGVyLWxpbmUtYWN0aXZlYCBhbmQgYGhlYWRlci1saW5lLWluYWN0aXZl YAogZmFjZXMuCgpUaGlzIGlzIGFsbCBpbnRlbmRlZCB0byBwYXJhbGxlbCB0aGUgbW9kZS1saW5l LWFjdGl2ZSBhbmQKbW9kZS1saW5lLWluYWN0aXZlIGRpc3RpbmN0aW9uLgoKKiBkb2MvZW1hY3Mv ZGlzcGxheS50ZXhpIChTdGFuZGFyZCBGYWNlcyk6IERvY3VtZW50IHRoZSBuZXcgZmFjZXMuCgoq IGxpc3AvZmFjZXMuZWwgKGhlYWRlci1saW5lLWFjdGl2ZSwgaGVhZGVyLWxpbmUtaW5hY3RpdmUp OiBOZXcgZmFjZXMuCgoqIHNyYy9kaXNwZXh0ZXJuLmggKENVUlJFTlRfSEVBREVSX0xJTkVfQUNU SVZFX0ZBQ0VfSURfMywKQ1VSUkVOVF9IRUFERVJfTElORV9BQ1RJVkVfRkFDRV9JRCk6IG5ldyBt YWNyb3MgYmFzZWQgb24gbW9kZSBsaW5lCmVxdWl2YWxlbnRzCihmYWNlX2lkKTogbmV3IGZhY2Ug SURzCiogc3JjL3hkaXNwLmMgKHdpbmRvd19ib3hfaGVpZ2h0LCBwb3NfdmlzaWJsZV9wLCBpbml0 X2l0ZXJhdG9yLAp3aW5kb3dfdGV4dF9waXhlbF9zaXplLCBkaXNwbGF5X21vZGVfbGluZXMsIGRp c3BsYXlfbW9kZV9saW5lLApmb3JtYXQtbW9kZS1saW5lKTogcmVwbGFjZSBhbGwgdXNlcyBvZiBI RUFERVJfTElORV9GQUNFX0lEIHdpdGggZWl0aGVyCmEgbmV3IG1hY3JvIG9yIHRoZSBuZXcgZmFj ZSBJRHMKKiBzcmMveGZhY2VzLmMgKHN5bXNfb2ZfeGZhY2VzKTogbmV3IGxpc3Agc3ltYm9scwoo bG9va3VwX2Jhc2ljX2ZhY2UsIHJlYWxpemVfYmFzaWNfZmFjZXMpOiBtYXAgbmV3IGZhY2UgSURz IHRvIHRoZWlyIGxpc3AKc3ltYm9scwotLS0KIGRvYy9lbWFjcy9kaXNwbGF5LnRleGkgfCAxNiAr KysrKysrKysrKysrKysKIGV0Yy9ORVdTICAgICAgICAgICAgICAgfCAgNSArKysrKwogbGlzcC9m YWNlcy5lbCAgICAgICAgICB8IDE1ICsrKysrKysrKysrKysrCiBzcmMvZGlzcGV4dGVybi5oICAg ICAgIHwgMzMgKysrKysrKysrKysrKysrKysrKysrKysrKysrKystLQogc3JjL3hkaXNwLmMgICAg ICAgICAgICB8IDQ1ICsrKysrKysrKysrKysrKysrKysrKysrKy0tLS0tLS0tLS0tLS0tLS0tLQog c3JjL3hmYWNlcy5jICAgICAgICAgICB8ICA4ICsrKysrKy0tCiA2IGZpbGVzIGNoYW5nZWQsIDk5 IGluc2VydGlvbnMoKyksIDIzIGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL2RvYy9lbWFjcy9k aXNwbGF5LnRleGkgYi9kb2MvZW1hY3MvZGlzcGxheS50ZXhpCmluZGV4IDg4NTIwODc0YzhlLi4y MmNkMzE2ZjgzNiAxMDA2NDQKLS0tIGEvZG9jL2VtYWNzL2Rpc3BsYXkudGV4aQorKysgYi9kb2Mv ZW1hY3MvZGlzcGxheS50ZXhpCkBAIC03ODIsNiArNzgyLDIyIEBAIGF0IHRoZSB0b3Agb2YgYSB3 aW5kb3cganVzdCBhcyB0aGUgbW9kZSBsaW5lIGFwcGVhcnMgYXQgdGhlIGJvdHRvbS4KIE1vc3Qg d2luZG93cyBkbyBub3QgaGF2ZSBhIGhlYWRlciBsaW5lLS0tb25seSBzb21lIHNwZWNpYWwgbW9k ZXMsIHN1Y2gKIEluZm8gbW9kZSwgY3JlYXRlIG9uZS4KIAorVGhlIEBjb2Rle2hlYWRlci1saW5l LWFjdGl2ZX0gYW5kIEBjb2Rle2hlYWRlci1saW5lLWluYWN0aXZlfSBmYWNlcyAod2hpY2gKK2Fy ZSB0aGUgb25lcyB1c2VkIG9uIHRoZSBoZWFkZXIgbGluZXMpIGluaGVyaXQgZnJvbSB0aGlzIGZh Y2UuCisKK0BpdGVtIGhlYWRlci1saW5lLWFjdGl2ZQorQGNpbmRleCBmYWNlcyBmb3IgaGVhZGVy IGxpbmVzCitMaWtlIEBjb2Rle2hlYWRlci1saW5lfSwgYnV0IHVzZWQgZm9yIHRoZSBoZWFkZXIg bGluZSBvZiB0aGUgY3VycmVudGx5CitzZWxlY3RlZCB3aW5kb3cuICBUaGlzIGZhY2UgaW5oZXJp dHMgZnJvbSBAY29kZXtoZWFkZXItbGluZX0sIHNvIGNoYW5nZXMKK2luIHRoYXQgZmFjZSBhZmZl Y3QgaGVhZGVyIGxpbmVzIGluIGFsbCB3aW5kb3dzLgorCitAaXRlbSBoZWFkZXItbGluZS1pbmFj dGl2ZQorQGNpbmRleCBAY29kZXtoZWFkZXItbGluZS1pbmFjdGl2ZX0gZmFjZQorTGlrZSBAY29k ZXtoZWFkZXItbGluZX0sIGJ1dCB1c2VkIGZvciBoZWFkZXIgbGluZXMgb2YgdGhlIHdpbmRvd3Mg b3RoZXIKK3RoYW4gdGhlIHNlbGVjdGVkIG9uZSAoaWYgdGhvc2Ugd2luZG93cyBoYXZlIGEgaGVh ZGVyIGxpbmUpLiAgVGhpcyBmYWNlCitpbmhlcml0cyBmcm9tIEBjb2Rle2hlYWRlci1saW5lfSwg c28gY2hhbmdlcyBpbiB0aGF0IGZhY2UgYWZmZWN0IGhlYWRlcgorbGluZXMgaW4gYWxsIHdpbmRv d3MuCisKIEBpdGVtIGhlYWRlci1saW5lLWhpZ2hsaWdodAogQGNpbmRleCBAY29kZXtoZWFkZXIt bGluZS1oaWdobGlnaHR9IGZhY2UKIFNpbWlsYXIgdG8gQGNvZGV7aGlnaGxpZ2h0fSBhbmQgQGNv ZGV7bW9kZS1saW5lLWhpZ2hsaWdodH0sIGJ1dCB1c2VkCmRpZmYgLS1naXQgYS9ldGMvTkVXUyBi L2V0Yy9ORVdTCmluZGV4IGE4ZWNlNWMzZGM5Li5iMDM5MGU1OTdkMCAxMDA2NDQKLS0tIGEvZXRj L05FV1MKKysrIGIvZXRjL05FV1MKQEAgLTE1MCw2ICsxNTAsMTEgQEAgS2lsbGVkIGJ1ZmZlcnMg c3RvcmVkIGluIGEgcmVnaXN0ZXIgdXNpbmcgJ2J1ZmZlci10by1yZWdpc3RlcicgYXJlCiBhdXRv bWF0aWNhbGx5IGNvbnZlcnRlZCB0byBhIGZpbGUtcXVlcnkgdmFsdWUgaWYgdGhlIGJ1ZmZlciB3 YXMgdmlzaXRpbmcKIGEgZmlsZS4KIAorKiogTmV3IGZhY2UgJ2hlYWRlci1saW5lLWFjdGl2ZScu CitUaGlzIGluaGVyaXRzIGZyb20gdGhlICdoZWFkZXItbGluZScgZmFjZSwgYnV0IGlzIHRoZSBm YWNlIGFjdHVhbGx5IHVzZWQKK29uIHRoZSBoZWFkZXIgbGluZXMgKGFsb25nIHdpdGggJ2hlYWRl ci1saW5lLWluYWN0aXZlJykuCisKKysrKwogDAogKiBFZGl0aW5nIENoYW5nZXMgaW4gRW1hY3Mg MzEuMQogCmRpZmYgLS1naXQgYS9saXNwL2ZhY2VzLmVsIGIvbGlzcC9mYWNlcy5lbAppbmRleCAy MWMzZTY2M2M2ZS4uZGQ4NTM3NmRlMjQgMTAwNjQ0Ci0tLSBhL2xpc3AvZmFjZXMuZWwKKysrIGIv bGlzcC9mYWNlcy5lbApAQCAtMjgyMSw2ICsyODIxLDIxIEBAIFVzZSB0aGUgZmFjZSBgbW9kZS1s aW5lLWhpZ2hsaWdodCcgZm9yIGZlYXR1cmVzIHRoYXQgY2FuIGJlIHNlbGVjdGVkLiIKICAgOnZl cnNpb24gIjI4LjEiCiAgIDpncm91cCAnYmFzaWMtZmFjZXMpCiAKKyhkZWZmYWNlIGhlYWRlci1s aW5lLWFjdGl2ZQorICAnKCh0IDppbmhlcml0IGhlYWRlci1saW5lKSkKKyAgIkZhY2UgZm9yIHRo ZSBzZWxlY3RlZCBoZWFkZXIgbGluZS4KK1RoaXMgaW5oZXJpdHMgZnJvbSB0aGUgYGhlYWRlci1s aW5lJyBmYWNlLiIKKyAgOnZlcnNpb24gIjI5LjUiCisgIDpncm91cCAnbW9kZS1saW5lLWZhY2Vz CisgIDpncm91cCAnYmFzaWMtZmFjZXMpCisKKyhkZWZmYWNlIGhlYWRlci1saW5lLWluYWN0aXZl CisgICcoKHQgOmluaGVyaXQgaGVhZGVyLWxpbmUpKQorICAiQmFzaWMgaGVhZGVyIGxpbmUgZmFj ZSBmb3Igbm9uLXNlbGVjdGVkIHdpbmRvd3MuIgorICA6dmVyc2lvbiAiMjkuNSIKKyAgOmdyb3Vw ICdtb2RlLWxpbmUtZmFjZXMKKyAgOmdyb3VwICdiYXNpYy1mYWNlcykKKwogKGRlZmZhY2UgdmVy dGljYWwtYm9yZGVyCiAgICcoKCgodHlwZSB0dHkpKSA6aW5oZXJpdCBtb2RlLWxpbmUtaW5hY3Rp dmUpKQogICAiRmFjZSB1c2VkIGZvciB2ZXJ0aWNhbCB3aW5kb3cgZGl2aWRlcnMgb24gdHR5cy4i CmRpZmYgLS1naXQgYS9zcmMvZGlzcGV4dGVybi5oIGIvc3JjL2Rpc3BleHRlcm4uaAppbmRleCBj YzI0OGE0NDcyZS4uMGQ0YzBhNmM2N2UgMTAwNjQ0Ci0tLSBhL3NyYy9kaXNwZXh0ZXJuLmgKKysr IGIvc3JjL2Rpc3BleHRlcm4uaApAQCAtMTU2MSw2ICsxNTYxLDM0IEBAIHN0cnVjdCBnbHlwaF9z dHJpbmcKIAkgOiBlc3RpbWF0ZV9tb2RlX2xpbmVfaGVpZ2h0CQkJCQlcCiAJIChYRlJBTUUgKChX KS0+ZnJhbWUpLCBDVVJSRU5UX01PREVfTElORV9BQ1RJVkVfRkFDRV9JRCAoVykpKSkpCiAKKy8q IFJldHVybiB0aGUgZGVzaXJlZCBmYWNlIGlkIGZvciB0aGUgaGVhZGVyIGxpbmUgb2YgYSB3aW5k b3csIGRlcGVuZGluZworICAgb24gd2hldGhlciB0aGUgd2luZG93IGlzIHNlbGVjdGVkIG9yIG5v dCwgb3IgaWYgdGhlIHdpbmRvdyBpcyB0aGUKKyAgIHNjcm9sbGluZyB3aW5kb3cgZm9yIHRoZSBj dXJyZW50bHkgYWN0aXZlIG1pbmlidWZmZXIgd2luZG93LgorCisgICBEdWUgdG8gdGhlIHdheSBk aXNwbGF5X21vZGVfbGluZXMgbWFuaXB1bGF0ZXMgd2l0aCB0aGUgY29udGVudHMgb2YKKyAgIHNl bGVjdGVkX3dpbmRvdywgdGhpcyBtYWNybyBuZWVkcyB0aHJlZSBhcmd1bWVudHM6IFNFTFcgd2hp Y2ggaXMKKyAgIGNvbXBhcmVkIGFnYWluc3QgdGhlIGN1cnJlbnQgdmFsdWUgb2Ygc2VsZWN0ZWRf d2luZG93LCBNQlcgd2hpY2ggaXMKKyAgIGNvbXBhcmVkIGFnYWluc3QgbWluaWJ1Zl93aW5kb3cg KGlmIFNFTFcgZG9lc24ndCBtYXRjaCksIGFuZCBTQ1JXCisgICB3aGljaCBpcyBjb21wYXJlZCBh Z2FpbnN0IG1pbmlidWZfc2VsZWN0ZWRfd2luZG93IChpZiBNQlcgbWF0Y2hlcykuICAqLworCisj ZGVmaW5lIENVUlJFTlRfSEVBREVSX0xJTkVfQUNUSVZFX0ZBQ0VfSURfMyhTRUxXLCBNQlcsIFND UlcpICAgIAlcCisgICAgICgoIW1vZGVfbGluZV9pbl9ub25fc2VsZWN0ZWRfd2luZG93cwkJCVwK KyAgICAgICB8fCAoU0VMVykgPT0gWFdJTkRPVyAoc2VsZWN0ZWRfd2luZG93KQkJCVwKKyAgICAg ICB8fCAobWluaWJ1Zl9sZXZlbCA+IDAJCQkJCVwKKyAgICAgICAgICAgJiYgIU5JTFAgKG1pbmli dWZfc2VsZWN0ZWRfd2luZG93KQkJCVwKKyAgICAgICAgICAgJiYgKE1CVykgPT0gWFdJTkRPVyAo bWluaWJ1Zl93aW5kb3cpCQkJXAorICAgICAgICAgICAmJiAoU0NSVykgPT0gWFdJTkRPVyAobWlu aWJ1Zl9zZWxlY3RlZF93aW5kb3cpKSkJXAorICAgICAgPyBIRUFERVJfTElORV9BQ1RJVkVfRkFD RV9JRAkJCQlcCisgICAgICA6IEhFQURFUl9MSU5FX0lOQUNUSVZFX0ZBQ0VfSUQpCisKKworLyog UmV0dXJuIHRoZSBkZXNpcmVkIGZhY2UgaWQgZm9yIHRoZSBoZWFkZXIgbGluZSBvZiB3aW5kb3cg Vy4gICovCisKKyNkZWZpbmUgQ1VSUkVOVF9IRUFERVJfTElORV9BQ1RJVkVfRkFDRV9JRChXKQkJ XAorCSBDVVJSRU5UX0hFQURFUl9MSU5FX0FDVElWRV9GQUNFX0lEXzMoVywgXAorCQkJCQkgICAg WFdJTkRPVyAoc2VsZWN0ZWRfd2luZG93KSwgXAorCQkJCQkgICAgVykKKwogLyogUmV0dXJuIHRo ZSBjdXJyZW50IGhlaWdodCBvZiB0aGUgaGVhZGVyIGxpbmUgb2Ygd2luZG93IFcuICBJZiBub3Qg a25vd24KICAgIGZyb20gVy0+aGVhZGVyX2xpbmVfaGVpZ2h0LCBsb29rIGF0IFcncyBjdXJyZW50 IGdseXBoIG1hdHJpeCwgb3IgcmV0dXJuCiAgICBhbiBlc3RpbWF0aW9uIGJhc2VkIG9uIHRoZSBo ZWlnaHQgb2YgdGhlIGZvbnQgb2YgdGhlIGZhY2UgYGhlYWRlci1saW5lJy4gICovCkBAIC0xNTcy LDcgKzE2MDAsNyBAQCBzdHJ1Y3QgZ2x5cGhfc3RyaW5nCiAgICAgICA9IChNQVRSSVhfSEVBREVS X0xJTkVfSEVJR0hUICgoVyktPmN1cnJlbnRfbWF0cml4KQlcCiAJID8gTUFUUklYX0hFQURFUl9M SU5FX0hFSUdIVCAoKFcpLT5jdXJyZW50X21hdHJpeCkJXAogCSA6IGVzdGltYXRlX21vZGVfbGlu ZV9oZWlnaHQJCQkJXAotCSAgICAgKFhGUkFNRSAoKFcpLT5mcmFtZSksIEhFQURFUl9MSU5FX0ZB Q0VfSUQpKSkpCisJIChYRlJBTUUgKChXKS0+ZnJhbWUpLCBDVVJSRU5UX0hFQURFUl9MSU5FX0FD VElWRV9GQUNFX0lEIChXKSkpKSkKIAogLyogUmV0dXJuIHRoZSBjdXJyZW50IGhlaWdodCBvZiB0 aGUgdGFiIGxpbmUgb2Ygd2luZG93IFcuICBJZiBub3Qga25vd24KICAgIGZyb20gVy0+dGFiX2xp bmVfaGVpZ2h0LCBsb29rIGF0IFcncyBjdXJyZW50IGdseXBoIG1hdHJpeCwgb3IgcmV0dXJuCkBA IC0xODkzLDcgKzE5MjEsOCBAQCBlbnVtIGZhY2VfaWQKICAgTU9ERV9MSU5FX0lOQUNUSVZFX0ZB Q0VfSUQsCiAgIFRPT0xfQkFSX0ZBQ0VfSUQsCiAgIEZSSU5HRV9GQUNFX0lELAotICBIRUFERVJf TElORV9GQUNFX0lELAorICBIRUFERVJfTElORV9BQ1RJVkVfRkFDRV9JRCwKKyAgSEVBREVSX0xJ TkVfSU5BQ1RJVkVfRkFDRV9JRCwKICAgU0NST0xMX0JBUl9GQUNFX0lELAogICBCT1JERVJfRkFD RV9JRCwKICAgQ1VSU09SX0ZBQ0VfSUQsCmRpZmYgLS1naXQgYS9zcmMveGRpc3AuYyBiL3NyYy94 ZGlzcC5jCmluZGV4IGM3NGU4MWEzOTMzLi45OGJjMTU3Yzc4OSAxMDA2NDQKLS0tIGEvc3JjL3hk aXNwLmMKKysrIGIvc3JjL3hkaXNwLmMKQEAgLTEzNTgsNyArMTM1OCw3IEBAIHdpbmRvd19ib3hf aGVpZ2h0IChzdHJ1Y3Qgd2luZG93ICp3KQogCSAgaWYgKGhsX3JvdyAmJiBobF9yb3ctPm1vZGVf bGluZV9wKQogCSAgICBoZWlnaHQgLT0gaGxfcm93LT5oZWlnaHQ7CiAJICBlbHNlCi0JICAgIGhl aWdodCAtPSBlc3RpbWF0ZV9tb2RlX2xpbmVfaGVpZ2h0IChmLCBIRUFERVJfTElORV9GQUNFX0lE KTsKKwkgICAgaGVpZ2h0IC09IGVzdGltYXRlX21vZGVfbGluZV9oZWlnaHQgKGYsIENVUlJFTlRf SEVBREVSX0xJTkVfQUNUSVZFX0ZBQ0VfSUQgKHcpKTsKIAl9CiAgICAgfQogCkBAIC0xNzUzLDcg KzE3NTMsNyBAQCBwb3NfdmlzaWJsZV9wIChzdHJ1Y3Qgd2luZG93ICp3LCBwdHJkaWZmX3QgY2hh cnBvcywgaW50ICp4LCBpbnQgKnksCiAJPSB3aW5kb3dfcGFyYW1ldGVyICh3LCBRaGVhZGVyX2xp bmVfZm9ybWF0KTsKIAogICAgICAgdy0+aGVhZGVyX2xpbmVfaGVpZ2h0Ci0JPSBkaXNwbGF5X21v ZGVfbGluZSAodywgSEVBREVSX0xJTkVfRkFDRV9JRCwKKwk9IGRpc3BsYXlfbW9kZV9saW5lICh3 LCBDVVJSRU5UX0hFQURFUl9MSU5FX0FDVElWRV9GQUNFX0lEICh3KSwKIAkJCSAgICAgTklMUCAo d2luZG93X2hlYWRlcl9saW5lX2Zvcm1hdCkKIAkJCSAgICAgPyBCVkFSIChjdXJyZW50X2J1ZmZl ciwgaGVhZGVyX2xpbmVfZm9ybWF0KQogCQkJICAgICA6IHdpbmRvd19oZWFkZXJfbGluZV9mb3Jt YXQpOwpAQCAtMzE5NywxMyArMzE5NywxNCBAQCBDSEVDS19XSU5ET1dfRU5EIChzdHJ1Y3Qgd2lu ZG93ICp3KQogCiAgICBCQVNFX0ZBQ0VfSUQgaXMgdGhlIGlkIG9mIGEgYmFzZSBmYWNlIHRvIHVz ZS4gIEl0IG11c3QgYmUgb25lIG9mCiAgICBERUZBVUxUX0ZBQ0VfSUQgZm9yIG5vcm1hbCB0ZXh0 LCBNT0RFX0xJTkVfQUNUSVZFX0ZBQ0VfSUQsCi0gICBNT0RFX0xJTkVfSU5BQ1RJVkVfRkFDRV9J RCwgb3IgSEVBREVSX0xJTkVfRkFDRV9JRCBmb3IgZGlzcGxheWluZwotICAgbW9kZSBsaW5lcywg b3IgVE9PTF9CQVJfRkFDRV9JRCBmb3IgZGlzcGxheWluZyB0aGUgdG9vbC1iYXIuCisgICBNT0RF X0xJTkVfSU5BQ1RJVkVfRkFDRV9JRCwgSEVBREVSX0xJTkVfQUNUSVZFX0ZBQ0VfSUQsIG9yCisg ICBIRUFERVJfTElORV9JTkFDVElWRV9GQUNFX0lEIGZvciBkaXNwbGF5aW5nIG1vZGUgbGluZXMs IG9yCisgICBUT09MX0JBUl9GQUNFX0lEIGZvciBkaXNwbGF5aW5nIHRoZSB0b29sLWJhci4KIAog ICAgSWYgUk9XIGlzIG51bGwgYW5kIEJBU0VfRkFDRV9JRCBpcyBlcXVhbCB0byBNT0RFX0xJTkVf QUNUSVZFX0ZBQ0VfSUQsCi0gICBNT0RFX0xJTkVfSU5BQ1RJVkVfRkFDRV9JRCwgb3IgSEVBREVS X0xJTkVfRkFDRV9JRCwgdGhlIGl0ZXJhdG9yCi0gICB3aWxsIGJlIGluaXRpYWxpemVkIHRvIHVz ZSB0aGUgY29ycmVzcG9uZGluZyBtb2RlIGxpbmUgZ2x5cGggcm93IG9mCi0gICB0aGUgZGVzaXJl ZCBtYXRyaXggb2YgVy4gICovCisgICBNT0RFX0xJTkVfSU5BQ1RJVkVfRkFDRV9JRCwgSEVBREVS X0xJTkVfQUNUSVZFX0ZBQ0VfSUQsIG9yCisgICBIRUFERVJfTElORV9JTkFDVElWRV9GQUNFX0lE IHRoZSBpdGVyYXRvciB3aWxsIGJlIGluaXRpYWxpemVkIHRvIHVzZQorICAgdGhlIGNvcnJlc3Bv bmRpbmcgbW9kZSBsaW5lIGdseXBoIHJvdyBvZiB0aGUgZGVzaXJlZCBtYXRyaXggb2YgVy4gICov CiAKIHZvaWQKIGluaXRfaXRlcmF0b3IgKHN0cnVjdCBpdCAqaXQsIHN0cnVjdCB3aW5kb3cgKncs CkBAIC0zMjUxLDcgKzMyNTIsOCBAQCBpbml0X2l0ZXJhdG9yIChzdHJ1Y3QgaXQgKml0LCBzdHJ1 Y3Qgd2luZG93ICp3LAogCXJvdyA9IE1BVFJJWF9NT0RFX0xJTkVfUk9XICh3LT5kZXNpcmVkX21h dHJpeCk7CiAgICAgICBlbHNlIGlmIChiYXNlX2ZhY2VfaWQgPT0gVEFCX0xJTkVfRkFDRV9JRCkK IAlyb3cgPSBNQVRSSVhfVEFCX0xJTkVfUk9XICh3LT5kZXNpcmVkX21hdHJpeCk7Ci0gICAgICBl bHNlIGlmIChiYXNlX2ZhY2VfaWQgPT0gSEVBREVSX0xJTkVfRkFDRV9JRCkKKyAgICAgIGVsc2Ug aWYgKGJhc2VfZmFjZV9pZCA9PSBIRUFERVJfTElORV9BQ1RJVkVfRkFDRV9JRAorCSAgICAgICB8 fCBiYXNlX2ZhY2VfaWQgPT0gSEVBREVSX0xJTkVfSU5BQ1RJVkVfRkFDRV9JRCkKIAl7CiAJICAv KiBIZWFkZXIgbGluZSByb3cgZGVwZW5kcyBvbiB3aGV0aGVyIHRhYiBsaW5lIGlzIGVuYWJsZWQu ICAqLwogCSAgdy0+ZGVzaXJlZF9tYXRyaXgtPnRhYl9saW5lX3AgPSB3aW5kb3dfd2FudHNfdGFi X2xpbmUgKHcpOwpAQCAtMTE4NTQsNyArMTE4NTYsNyBAQCB3aW5kb3dfdGV4dF9waXhlbF9zaXpl IChMaXNwX09iamVjdCB3aW5kb3csIExpc3BfT2JqZWN0IGZyb20sIExpc3BfT2JqZWN0IHRvLAog ICAgICAgTGlzcF9PYmplY3Qgd2luZG93X2hlYWRlcl9saW5lX2Zvcm1hdAogCT0gd2luZG93X3Bh cmFtZXRlciAodywgUWhlYWRlcl9saW5lX2Zvcm1hdCk7CiAKLSAgICAgIHkgPSB5ICsgZGlzcGxh eV9tb2RlX2xpbmUgKHcsIEhFQURFUl9MSU5FX0ZBQ0VfSUQsCisgICAgICB5ID0geSArIGRpc3Bs YXlfbW9kZV9saW5lICh3LCBDVVJSRU5UX0hFQURFUl9MSU5FX0FDVElWRV9GQUNFX0lEICh3KSwK IAkJCQkgTklMUCAod2luZG93X2hlYWRlcl9saW5lX2Zvcm1hdCkKIAkJCQkgPyBCVkFSIChjdXJy ZW50X2J1ZmZlciwgaGVhZGVyX2xpbmVfZm9ybWF0KQogCQkJCSA6IHdpbmRvd19oZWFkZXJfbGlu ZV9mb3JtYXQpOwpAQCAtMjc0NTMsMTEgKzI3NDU1LDExIEBAIGRpc3BsYXlfbW9kZV9saW5lcyAo c3RydWN0IHdpbmRvdyAqdykKICAgbGluZV9udW1iZXJfZGlzcGxheWVkID0gZmFsc2U7CiAgIHct PmNvbHVtbl9udW1iZXJfZGlzcGxheWVkID0gLTE7CiAKKyAgc3RydWN0IHdpbmRvdyAqc2VsX3cg PSBYV0lORE9XIChvbGRfc2VsZWN0ZWRfd2luZG93KTsKICAgaWYgKHdpbmRvd193YW50c19tb2Rl X2xpbmUgKHcpKQogICAgIHsKICAgICAgIExpc3BfT2JqZWN0IHdpbmRvd19tb2RlX2xpbmVfZm9y bWF0CiAJPSB3aW5kb3dfcGFyYW1ldGVyICh3LCBRbW9kZV9saW5lX2Zvcm1hdCk7Ci0gICAgICBz dHJ1Y3Qgd2luZG93ICpzZWxfdyA9IFhXSU5ET1cgKG9sZF9zZWxlY3RlZF93aW5kb3cpOwogCiAg ICAgICAvKiBTZWxlY3QgbW9kZSBsaW5lIGZhY2UgYmFzZWQgb24gdGhlIHJlYWwgc2VsZWN0ZWQg d2luZG93LiAgKi8KICAgICAgIGRpc3BsYXlfbW9kZV9saW5lICh3LApAQCAtMjc0ODUsNyArMjc0 ODcsNyBAQCBkaXNwbGF5X21vZGVfbGluZXMgKHN0cnVjdCB3aW5kb3cgKncpCiAgICAgICBMaXNw X09iamVjdCB3aW5kb3dfaGVhZGVyX2xpbmVfZm9ybWF0CiAJPSB3aW5kb3dfcGFyYW1ldGVyICh3 LCBRaGVhZGVyX2xpbmVfZm9ybWF0KTsKIAotICAgICAgZGlzcGxheV9tb2RlX2xpbmUgKHcsIEhF QURFUl9MSU5FX0ZBQ0VfSUQsCisgICAgICBkaXNwbGF5X21vZGVfbGluZSAodywgQ1VSUkVOVF9I RUFERVJfTElORV9BQ1RJVkVfRkFDRV9JRF8zIChzZWxfdywgc2VsX3csIHcpLAogCQkJIE5JTFAg KHdpbmRvd19oZWFkZXJfbGluZV9mb3JtYXQpCiAJCQkgPyBCVkFSIChjdXJyZW50X2J1ZmZlciwg aGVhZGVyX2xpbmVfZm9ybWF0KQogCQkJIDogd2luZG93X2hlYWRlcl9saW5lX2Zvcm1hdCk7CkBA IC0yNzUwMCwxMSArMjc1MDIsMTIgQEAgZGlzcGxheV9tb2RlX2xpbmVzIChzdHJ1Y3Qgd2luZG93 ICp3KQogfQogCiAKLS8qIERpc3BsYXkgbW9kZSBvciBoZWFkZXIvdGFiIGxpbmUgb2Ygd2luZG93 IFcuICBGQUNFX0lEIHNwZWNpZmllcwotICAgd2hpY2ggbGluZSB0byBkaXNwbGF5OyBpdCBpcyBl aXRoZXIgTU9ERV9MSU5FX0FDVElWRV9GQUNFX0lELAotICAgSEVBREVSX0xJTkVfRkFDRV9JRCBv ciBUQUJfTElORV9GQUNFX0lELiAgRk9STUFUIGlzIHRoZQotICAgbW9kZS9oZWFkZXIvdGFiIGxp bmUgZm9ybWF0IHRvIGRpc3BsYXkuICBWYWx1ZSBpcyB0aGUgcGl4ZWwgaGVpZ2h0Ci0gICBvZiB0 aGUgbW9kZS9oZWFkZXIvdGFiIGxpbmUgZGlzcGxheWVkLiAgKi8KKy8qIERpc3BsYXkgbW9kZSBv ciBoZWFkZXIvdGFiIGxpbmUgb2Ygd2luZG93IFcuICBGQUNFX0lEIHNwZWNpZmllcyB3aGljaAor ICAgbGluZSB0byBkaXNwbGF5OyBpdCBpcyBlaXRoZXIgTU9ERV9MSU5FX0FDVElWRV9GQUNFX0lE LAorICAgSEVBREVSX0xJTkVfQUNUSVZFX0ZBQ0VfSUQsIEhFQURFUl9MSU5FX0lOQUNUSVZFX0ZB Q0VfSUQsIG9yCisgICBUQUJfTElORV9GQUNFX0lELiAgRk9STUFUIGlzIHRoZSBtb2RlL2hlYWRl ci90YWIgbGluZSBmb3JtYXQgdG8KKyAgIGRpc3BsYXkuICBWYWx1ZSBpcyB0aGUgcGl4ZWwgaGVp Z2h0IG9mIHRoZSBtb2RlL2hlYWRlci90YWIgbGluZQorICAgZGlzcGxheWVkLiAgKi8KIAogc3Rh dGljIGludAogZGlzcGxheV9tb2RlX2xpbmUgKHN0cnVjdCB3aW5kb3cgKncsIGVudW0gZmFjZV9p ZCBmYWNlX2lkLCBMaXNwX09iamVjdCBmb3JtYXQpCkBAIC0yNzUyNSw3ICsyNzUyOCw4IEBAIGRp c3BsYXlfbW9kZV9saW5lIChzdHJ1Y3Qgd2luZG93ICp3LCBlbnVtIGZhY2VfaWQgZmFjZV9pZCwg TGlzcF9PYmplY3QgZm9ybWF0KQogICAgICAgaXQuZ2x5cGhfcm93LT50YWJfbGluZV9wID0gdHJ1 ZTsKICAgICAgIHctPmRlc2lyZWRfbWF0cml4LT50YWJfbGluZV9wID0gdHJ1ZTsKICAgICB9Ci0g IGVsc2UgaWYgKGZhY2VfaWQgPT0gSEVBREVSX0xJTkVfRkFDRV9JRCkKKyAgZWxzZSBpZiAoZmFj ZV9pZCA9PSBIRUFERVJfTElORV9BQ1RJVkVfRkFDRV9JRAorCSAgIHx8IGZhY2VfaWQgPT0gSEVB REVSX0xJTkVfSU5BQ1RJVkVfRkFDRV9JRCkKICAgICB3LT5kZXNpcmVkX21hdHJpeC0+aGVhZGVy X2xpbmVfcCA9IHRydWU7CiAKICAgLyogRklYTUU6IFRoaXMgc2hvdWxkIGJlIGNvbnRyb2xsZWQg YnkgYSB1c2VyIG9wdGlvbi4gIEJ1dApAQCAtMjc1NDQsNyArMjc1NDgsOSBAQCBkaXNwbGF5X21v ZGVfbGluZSAoc3RydWN0IHdpbmRvdyAqdywgZW51bSBmYWNlX2lkIGZhY2VfaWQsIExpc3BfT2Jq ZWN0IGZvcm1hdCkKICAgcmVjb3JkX3Vud2luZF9zYXZlX21hdGNoX2RhdGEgKCk7CiAKICAgaWYg KE5JTFAgKFZtb2RlX2xpbmVfY29tcGFjdCkKLSAgICAgIHx8IGZhY2VfaWQgPT0gSEVBREVSX0xJ TkVfRkFDRV9JRCB8fCBmYWNlX2lkID09IFRBQl9MSU5FX0ZBQ0VfSUQpCisgICAgICB8fCBmYWNl X2lkID09IEhFQURFUl9MSU5FX0FDVElWRV9GQUNFX0lECisgICAgICB8fCBmYWNlX2lkID09IEhF QURFUl9MSU5FX0lOQUNUSVZFX0ZBQ0VfSUQKKyAgICAgIHx8IGZhY2VfaWQgPT0gVEFCX0xJTkVf RkFDRV9JRCkKICAgICB7CiAgICAgICBtb2RlX2xpbmVfdGFyZ2V0ID0gTU9ERV9MSU5FX0RJU1BM QVk7CiAgICAgICBkaXNwbGF5X21vZGVfZWxlbWVudCAoJml0LCAwLCAwLCAwLCBmb3JtYXQsIFFu aWwsIGZhbHNlKTsKQEAgLTI4MzEzLDcgKzI4MzE5LDggQEAgYXJlIHRoZSBzZWxlY3RlZCB3aW5k b3cgYW5kIHRoZSBXSU5ET1cncyBidWZmZXIpLiAgKi8pCiAJCSAgICAgICA/IE1PREVfTElORV9B Q1RJVkVfRkFDRV9JRCA6IE1PREVfTElORV9JTkFDVElWRV9GQUNFX0lEKQogICAgIDogRVEgKGZh Y2UsIFFtb2RlX2xpbmVfYWN0aXZlKSA/IE1PREVfTElORV9BQ1RJVkVfRkFDRV9JRAogICAgIDog RVEgKGZhY2UsIFFtb2RlX2xpbmVfaW5hY3RpdmUpID8gTU9ERV9MSU5FX0lOQUNUSVZFX0ZBQ0Vf SUQKLSAgICA6IEVRIChmYWNlLCBRaGVhZGVyX2xpbmUpID8gSEVBREVSX0xJTkVfRkFDRV9JRAor ICAgIDogRVEgKGZhY2UsIFFoZWFkZXJfbGluZV9hY3RpdmUpID8gSEVBREVSX0xJTkVfQUNUSVZF X0ZBQ0VfSUQKKyAgICA6IEVRIChmYWNlLCBRaGVhZGVyX2xpbmVfaW5hY3RpdmUpID8gSEVBREVS X0xJTkVfSU5BQ1RJVkVfRkFDRV9JRAogICAgIDogRVEgKGZhY2UsIFF0YWJfbGluZSkgPyBUQUJf TElORV9GQUNFX0lECiAgICAgOiBFUSAoZmFjZSwgUXRhYl9iYXIpID8gVEFCX0JBUl9GQUNFX0lE CiAgICAgOiBFUSAoZmFjZSwgUXRvb2xfYmFyKSA/IFRPT0xfQkFSX0ZBQ0VfSUQKZGlmZiAtLWdp dCBhL3NyYy94ZmFjZXMuYyBiL3NyYy94ZmFjZXMuYwppbmRleCBlMjQ4Mjc5ZTliNy4uZjYyNjQ4 MDJmYTQgMTAwNjQ0Ci0tLSBhL3NyYy94ZmFjZXMuYworKysgYi9zcmMveGZhY2VzLmMKQEAgLTUx MTcsNyArNTExNyw4IEBAIGxvb2t1cF9iYXNpY19mYWNlIChzdHJ1Y3Qgd2luZG93ICp3LCBzdHJ1 Y3QgZnJhbWUgKmYsIGludCBmYWNlX2lkKQogICAgIGNhc2UgREVGQVVMVF9GQUNFX0lEOgkJbmFt ZSA9IFFkZWZhdWx0OwkJYnJlYWs7CiAgICAgY2FzZSBNT0RFX0xJTkVfQUNUSVZFX0ZBQ0VfSUQ6 CW5hbWUgPSBRbW9kZV9saW5lX2FjdGl2ZTsgICAgICAJYnJlYWs7CiAgICAgY2FzZSBNT0RFX0xJ TkVfSU5BQ1RJVkVfRkFDRV9JRDoJbmFtZSA9IFFtb2RlX2xpbmVfaW5hY3RpdmU7CWJyZWFrOwot ICAgIGNhc2UgSEVBREVSX0xJTkVfRkFDRV9JRDoJCW5hbWUgPSBRaGVhZGVyX2xpbmU7CQlicmVh azsKKyAgICBjYXNlIEhFQURFUl9MSU5FX0FDVElWRV9GQUNFX0lEOgluYW1lID0gUWhlYWRlcl9s aW5lX2FjdGl2ZTsJYnJlYWs7CisgICAgY2FzZSBIRUFERVJfTElORV9JTkFDVElWRV9GQUNFX0lE OgluYW1lID0gUWhlYWRlcl9saW5lX2luYWN0aXZlOwlicmVhazsKICAgICBjYXNlIFRBQl9MSU5F X0ZBQ0VfSUQ6CQluYW1lID0gUXRhYl9saW5lOwkJYnJlYWs7CiAgICAgY2FzZSBUQUJfQkFSX0ZB Q0VfSUQ6CQluYW1lID0gUXRhYl9iYXI7CQlicmVhazsKICAgICBjYXNlIFRPT0xfQkFSX0ZBQ0Vf SUQ6CQluYW1lID0gUXRvb2xfYmFyOwkJYnJlYWs7CkBAIC01ODY3LDcgKzU4NjgsOCBAQCByZWFs aXplX2Jhc2ljX2ZhY2VzIChzdHJ1Y3QgZnJhbWUgKmYpCiAgICAgICByZWFsaXplX25hbWVkX2Zh Y2UgKGYsIFFtb2RlX2xpbmVfaW5hY3RpdmUsIE1PREVfTElORV9JTkFDVElWRV9GQUNFX0lEKTsK ICAgICAgIHJlYWxpemVfbmFtZWRfZmFjZSAoZiwgUXRvb2xfYmFyLCBUT09MX0JBUl9GQUNFX0lE KTsKICAgICAgIHJlYWxpemVfbmFtZWRfZmFjZSAoZiwgUWZyaW5nZSwgRlJJTkdFX0ZBQ0VfSUQp OwotICAgICAgcmVhbGl6ZV9uYW1lZF9mYWNlIChmLCBRaGVhZGVyX2xpbmUsIEhFQURFUl9MSU5F X0ZBQ0VfSUQpOworICAgICAgcmVhbGl6ZV9uYW1lZF9mYWNlIChmLCBRaGVhZGVyX2xpbmVfYWN0 aXZlLCBIRUFERVJfTElORV9BQ1RJVkVfRkFDRV9JRCk7CisgICAgICByZWFsaXplX25hbWVkX2Zh Y2UgKGYsIFFoZWFkZXJfbGluZV9pbmFjdGl2ZSwgSEVBREVSX0xJTkVfSU5BQ1RJVkVfRkFDRV9J RCk7CiAgICAgICByZWFsaXplX25hbWVkX2ZhY2UgKGYsIFFzY3JvbGxfYmFyLCBTQ1JPTExfQkFS X0ZBQ0VfSUQpOwogICAgICAgcmVhbGl6ZV9uYW1lZF9mYWNlIChmLCBRYm9yZGVyLCBCT1JERVJf RkFDRV9JRCk7CiAgICAgICByZWFsaXplX25hbWVkX2ZhY2UgKGYsIFFjdXJzb3IsIENVUlNPUl9G QUNFX0lEKTsKQEAgLTc0MzgsNiArNzQ0MCw4IEBAIHN5bXNfb2ZfeGZhY2VzICh2b2lkKQogICBE RUZTWU0gKFFmcmluZ2UsICJmcmluZ2UiKTsKICAgREVGU1lNIChRdGFiX2xpbmUsICJ0YWItbGlu ZSIpOwogICBERUZTWU0gKFFoZWFkZXJfbGluZSwgImhlYWRlci1saW5lIik7CisgIERFRlNZTSAo UWhlYWRlcl9saW5lX2luYWN0aXZlLCAiaGVhZGVyLWxpbmUtaW5hY3RpdmUiKTsKKyAgREVGU1lN IChRaGVhZGVyX2xpbmVfYWN0aXZlLCAiaGVhZGVyLWxpbmUtYWN0aXZlIik7CiAgIERFRlNZTSAo UXNjcm9sbF9iYXIsICJzY3JvbGwtYmFyIik7CiAgIERFRlNZTSAoUW1lbnUsICJtZW51Iik7CiAg IERFRlNZTSAoUWN1cnNvciwgImN1cnNvciIpOwotLSAKMi40Ny4wCgo= --000000000000aaccda06269cfbec-- From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 16 09:11:17 2024 Received: (at 73862-done) by debbugs.gnu.org; 16 Nov 2024 14:11:17 +0000 Received: from localhost ([127.0.0.1]:52604 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tCJW8-0004ck-NH for submit@debbugs.gnu.org; Sat, 16 Nov 2024 09:11:16 -0500 Received: from eggs.gnu.org ([209.51.188.92]:44170) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tCJW6-0004cU-3P for 73862-done@debbugs.gnu.org; Sat, 16 Nov 2024 09:11:14 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tCJW0-0002Hy-NX; Sat, 16 Nov 2024 09:11:08 -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=CYvAzEFcr1sBjPBQ0mlAeIl+JArjvkAsYHGEsk5eLv0=; b=hAJh+aVqZgae lKXP9Jng11RtwNgi7ar8be+r6i+6AX46bzmHtWOKT3T1ZrDsOJPMy2rsNTZ0dL6sNl04ivWVW07fk u7Nhfp5xCNpQ3oR2xkf7dPYemljgcOr1ftxG0dtwakFq+FBkuXYOdLKl4ipY6ioIl1Q1C55AzCRM/ PscmiOwZF0M94XgHMzbDi9z4cSSWBV6vZOBf2GXnLT4yA5LP/MBtzzI1cgYD9mqtRXPED3GMDxl1t R05a9N36MKfaWXkqNinwS7Oe35FtIgf2RUzRMJvU/alVtytvKKQTlZObHToH/3nqB7V+dxD8rvxQH W8l9Fw6FQA2z/yvMvOR3tw==; Date: Sat, 16 Nov 2024 16:11:05 +0200 Message-Id: <867c93gtfq.fsf@gnu.org> From: Eli Zaretskii To: Trevor Murphy In-Reply-To: (message from Trevor Murphy on Sun, 10 Nov 2024 22:11:30 -0800) Subject: Re: bug#73862: [PATCH] Add `header-line-active` and `header-line-inactive` faces. References: <87y12lo9hb.fsf@gmail.com> <86a5epakma.fsf@gnu.org> <86ttcgn3ww.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 73862-done Cc: 73862-done@debbugs.gnu.org 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: Trevor Murphy > Date: Sun, 10 Nov 2024 22:11:30 -0800 > Cc: 73862@debbugs.gnu.org > > Hi! Thanks for your patience, attached please find the updated patch. I've added documentation and a > NEWS entry modeled off of similar commits. > > When I put together the original patch I included a non-trivial value for the default header-line-inactive > (copied from mode-line-inactive) as a visual indicator for the new face. Happy to take it out. In this updated > patch, header-line-inactive just inherits from header-line. I tested by looking at selected and not-selected > Info buffers with emacs -Q both patched and unpatched, in both graphical and terminal. Thanks, installed on the master branch, and closing the bug. From debbugs-submit-bounces@debbugs.gnu.org Wed Dec 04 00:07:58 2024 Received: (at 73862) by debbugs.gnu.org; 4 Dec 2024 05:07:58 +0000 Received: from localhost ([127.0.0.1]:33724 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tIhcE-0001jv-4e for submit@debbugs.gnu.org; Wed, 04 Dec 2024 00:07:58 -0500 Received: from mail-lj1-f171.google.com ([209.85.208.171]:53637) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tIhc9-0001jj-Mj for 73862@debbugs.gnu.org; Wed, 04 Dec 2024 00:07:57 -0500 Received: by mail-lj1-f171.google.com with SMTP id 38308e7fff4ca-2ffdbc0c103so90152891fa.3 for <73862@debbugs.gnu.org>; Tue, 03 Dec 2024 21:07:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1733288812; x=1733893612; darn=debbugs.gnu.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=eviPXI93ILVls7p5u00SonJU7LV7qFhms9yXXVSJkTk=; b=S7o1qgleCoYJK7l6kEdyk9jUr0QrUeHhKUsv51ggGmys2xdw1zs9fuUsiDo+2p1o3w xnayibP6DRh6Hhk0k3sgMXmXWQw6WUJM235o8hLnZnBHuJs0ev15dTO/MmeGANxK1km5 O+AgY7o2iWlsYpduz7bbUXNQZNuz+vTGiNyOVWLc61p/snoaRAp0QsVr4EvXnyHgmWw6 tuV2bP6Y5sT6Grg2hTsPQfV7xN66GIQopBbz123I7XZAeg1RcKxP/h2I4cE2alppCYOx gnbcVJuyNUPNRG/2TCB/K66Gyn6ap6nVELu8IXAQFl0ZLk/ZPhSjjxSL2JE6CokG8Fv6 q2CQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733288812; x=1733893612; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=eviPXI93ILVls7p5u00SonJU7LV7qFhms9yXXVSJkTk=; b=pxC0J2OmWGWFxLfH9CSLL5WzlvPYd3XeTMis/P5LSkm8gCOJukhnahODUH6sNHlMRx rHPElbs8XXyW1Jp2waKiF3ofa1179wm07naf4RjgY0sMAb+6gtBJTiBWKTj4SFc9LWDB 1lwtemTHPtLSlb887Rt6TDa7hnRgXWHIbI2WaPAi/904wKayumjiM5vA54Th7pGNc/7d 9PuOY/y0l/INKS39hXTokB5v+6gvFANmLMM3+W4E7Su0+ttEfQlQ7grMG/coG2Oauela +4QZUagX733fMDs4Cgbqp/bgL6/uerNOb+RJML+OyluKUpUR80m781WGoCZ9QfMA3edP fmvQ== X-Forwarded-Encrypted: i=1; AJvYcCXeu+z9ZUeGkhbSMXRgNPjB6NvcUJgCLORpJFQNiKO7N36YA6W0sauCs82yS1a+otBg9VQxHQ==@debbugs.gnu.org X-Gm-Message-State: AOJu0Yy4niJlzo2Xv3kc6OZtToexA+5TJ1ls3Fg8VMIyw+iAcFAarD+j 49JWlUphrEbr1nxlyzToybzeSXZghO8L1WAnJPUoJT9tN4OsApqHJ7n3Q6d/QkRyIwnZ91knJAh BEIejeuBAS/RfSn2cWSRdGssxisc= X-Gm-Gg: ASbGncuQ/HBQZtFvNgr1/sJwJnQaZP11ctcRIzpCGdTeMnQUGDQt1QKjY132Fi53oos EgcKLM8sM9NjEWvtD7ARilJsoGl9uFDB3aNZO2Eh7vy3tWp6qtxFfbkg= X-Google-Smtp-Source: AGHT+IHSVDxOz8jsHIJCN9bMgy4Y90xQvxTkC8iIK3oeJXyE91rs99nS371dtyxalK0/kb2K1tIMnVmD2pkXDe2MmTM= X-Received: by 2002:a2e:a9a6:0:b0:2f7:5a41:b0b with SMTP id 38308e7fff4ca-30009ced6cdmr45213131fa.26.1733288812035; Tue, 03 Dec 2024 21:06:52 -0800 (PST) Received: from 649336022844 named unknown by gmailapi.google.com with HTTPREST; Tue, 3 Dec 2024 21:06:50 -0800 Mime-Version: 1.0 X-Mailer: Superhuman Desktop (2024-12-02T20:06:08Z) X-Superhuman-ID: m49fe5m9.8737f723-baf0-4f46-9cdc-545f54d9a7af X-Superhuman-Draft-ID: draft00eed603e6fd921c X-Entity-Ref-ID: m49fe5m9.8737f723-baf0-4f46-9cdc-545f54d9a7af X-Superhuman-Thread-ID: draft002bce3a0e3fe324 From: Aaron Jensen Date: Tue, 3 Dec 2024 21:06:50 -0800 Message-ID: Subject: bug#73862: [PATCH] Add `header-line-active` and `header-line-inactive` faces. To: eliz@gnu.org, 73862@debbugs.gnu.org Content-Type: multipart/alternative; boundary="000000000000ef498d06286abfcd" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 73862 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.0 (-) --000000000000ef498d06286abfcd Content-Type: text/plain; charset="UTF-8" I bisected and found that this patch caused a regression in header-line formatting. I don't have the exact reproduction steps yet, but the gist is that I use a header-line with multiple faces in one window, then open a new popup window that has no header-line. The original window's header-line will get its faces changed slightly, but it's hard to tell how. Here's a video demonstrating it: https://share.cleanshot.com/CD9PtVv3 You can see that the padding on the left of the header line goes away and the line numbers change to a variable pitch font. If I adjust my font size, the header line redraws with the proper faces. This will happen randomly, but I can force it with the font size change reliably. I'll see if I can narrow reproduction steps, but it may be worth considering a revert for now. Thanks, Aaron --000000000000ef498d06286abfcd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I bisected and found tha= t this patch caused a regression in header-line formatting. I don't hav= e the exact reproduction steps yet, but the gist is that I use a header-lin= e with multiple=C2=A0faces in one window, then open a new popup window that= has no header-line. The original window's header-line will get its fac= es changed slightly, but it's hard to tell how.

Here's a video demonstrating it:=C2=A0https://share.cleanshot.com/CD9= PtVv3

You can see th= at the padding on the left of the header line goes away and the line number= s change to a variable pitch font. If I adjust my font size, the header lin= e redraws with the proper faces. This will happen randomly, but I can force= it with the font size change reliably.

=
I'll see if I can narrow reproduction steps, but it may= be worth considering a revert for now.

=
Thanks,


Aaron

--000000000000ef498d06286abfcd-- From debbugs-submit-bounces@debbugs.gnu.org Wed Dec 04 01:32:07 2024 Received: (at 73862) by debbugs.gnu.org; 4 Dec 2024 06:32:07 +0000 Received: from localhost ([127.0.0.1]:33834 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tIivf-0006Cp-57 for submit@debbugs.gnu.org; Wed, 04 Dec 2024 01:32:07 -0500 Received: from mail-lj1-f182.google.com ([209.85.208.182]:55666) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tIivd-0006CJ-91 for 73862@debbugs.gnu.org; Wed, 04 Dec 2024 01:32:06 -0500 Received: by mail-lj1-f182.google.com with SMTP id 38308e7fff4ca-2ffdd9fc913so67353831fa.3 for <73862@debbugs.gnu.org>; Tue, 03 Dec 2024 22:32:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1733293859; x=1733898659; darn=debbugs.gnu.org; h=to:subject:message-id:date:from:references:in-reply-to:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=zS/VcYqSdMW/hXy/ry7scfDmQK34E7Dqqi2cvBT6fpE=; b=h5LWbfb2Uzue98GmiG1v3SntO2Mn1KRZqJsHeNFSV4CYNKcm6aTbbmUa9HpnJGBXij 8JQyDCSiZq0n964znI1Xmw7whj54YZSNTNuaGRekYp6LuwCtoLhO5O0ZzFs5I8j6Dp1A Mwi2WFkyykUm7ZgIaPCeB+PwOh+tnIa3KN/JGAWsxbzItcbeVC8QXJqZZbVYnvJtbvg+ rKDqM8UoTQUxRVlngfbxofrXRqBNPmBtxHOJ+UfGmDDw6MtVkMZVjkmqUQfA5tAiRMbs GYAevYYG6UBfYOxgGQSIFlcgjqXM99b1kZJXWpDnnAcEwjRJi60mWrCPSlqsBbgRt90F 64JQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733293859; x=1733898659; h=to:subject:message-id:date:from:references:in-reply-to:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=zS/VcYqSdMW/hXy/ry7scfDmQK34E7Dqqi2cvBT6fpE=; b=jMJrMe7czsNkANPDb6jc9W29G+rAMAfWoaedRTDmQAQRlpd2ofQ434lq2si8MCqkLP euxX98O0UsvijdIKib4AmmwbDczm/cSD3Y2MaMyjGAHPRKvOmi5+CCLIWa3raRDQyU69 z/xY/ez+xcRb5jzu/YViV3i1dArGYHL3icMyQCEqZQjpQkGM5vBTEttIT/G2h1GwtWpC HVgVJqp1pH2K2GJpQEDS9lfP3FQ63wy5VL3WQ7XTrKlRX/+j4yxvdk2oRbfZLt7AtNht 9ynWLP2JD8+AHoLIHYkLfcfCEnIzNuRPcvHnBEon43bvA9fbrbWIfdKbBlQcwcJVQzSk 0odQ== X-Forwarded-Encrypted: i=1; AJvYcCX3Efoxt+usmMDFYPKXSqDu+x4U7F3nemvnlu/ISmkc/u26q6u4OcBm7Oba2zoj8rAzKBDDfw==@debbugs.gnu.org X-Gm-Message-State: AOJu0Yws1jXO11y2YujpeyVDR1yeeoIREjbd7VxB6CSwa+UrEfoJQ2eT mpNqBbypg6mbYw3K28LEy4DGdmnr797zVe2JauIcc6/CjQ79Z9Gwr/8kFjabR0AW4J6XntJddVj iJo34B7XI8E0IZ6Gch7F5Ony0zxA= X-Gm-Gg: ASbGncszOkdfIOix1mo01AuSkF9sKO5azXId+SxGEIgl+jPgxlhbmYoK3KRdR9YONVS t1+PuGC/pvvVWv50/etHeRTBkCa2Iorj0sSYcJxr6OUnrSRC1bY1PwDo= X-Google-Smtp-Source: AGHT+IGokMa1EgTm9TNij3iec1v5S3xLYYyGR6KhE3OmmmFFj7J5BpAx6r5wDnw2Wz2BJki5FrQWKBibXzP0+JKfD/s= X-Received: by 2002:a2e:bc22:0:b0:2ff:c2e2:cca7 with SMTP id 38308e7fff4ca-30009c3555fmr31192401fa.16.1733293858785; Tue, 03 Dec 2024 22:30:58 -0800 (PST) Received: from 649336022844 named unknown by gmailapi.google.com with HTTPREST; Tue, 3 Dec 2024 22:30:58 -0800 Mime-Version: 1.0 In-Reply-To: References: X-Mailer: Superhuman Desktop (2024-12-02T20:06:08Z) X-Superhuman-ID: m49iec7v.3ce32e5b-8c62-465d-b7a0-3bdaf5fe756c X-Superhuman-Draft-ID: draft0094775185bc5b0d From: Aaron Jensen Date: Tue, 3 Dec 2024 22:30:58 -0800 Message-ID: Subject: Re: bug#73862: [PATCH] Add `header-line-active` and `header-line-inactive` faces. To: eliz@gnu.org, 73862@debbugs.gnu.org Content-Type: multipart/alternative; boundary="000000000000be91d306286bec4a" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 73862 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.0 (-) --000000000000be91d306286bec4a Content-Type: text/plain; charset="UTF-8" I'm able to reproduce this with the mode-line as well, so it appears that there may be a bug there too in the code that was copied to implement the active/inactive faces in the header line. It's entirely possible that there's a bug in nano-modeline, but it seems suspect that code was added to consider windows and now this issue triggers when new windows are created (and possibly when selection changes, I haven't eliminated whether or not that's a factor yet). Aaron On Tue, Dec 03, 2024 at 9:06 PM, Aaron Jensen wrote: > I bisected and found that this patch caused a regression in header-line > formatting. I don't have the exact reproduction steps yet, but the gist is > that I use a header-line with multiple faces in one window, then open a new > popup window that has no header-line. The original window's header-line > will get its faces changed slightly, but it's hard to tell how. > > Here's a video demonstrating it: https://share.cleanshot.com/CD9PtVv3 > > You can see that the padding on the left of the header line goes away and > the line numbers change to a variable pitch font. If I adjust my font size, > the header line redraws with the proper faces. This will happen randomly, > but I can force it with the font size change reliably. > > I'll see if I can narrow reproduction steps, but it may be worth > considering a revert for now. > > Thanks, > > > Aaron > --000000000000be91d306286bec4a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm able to rep= roduce this with the mode-line as well, so it appears that there may be a b= ug there too in the code that was copied to implement the active/inactive f= aces in the header line. It's entirely possible that there's a bug = in nano-modeline, but it seems suspect that code was added to consider wind= ows and now this issue triggers when new windows are created (and possibly = when selection changes, I haven't eliminated whether or not that's = a factor yet).


Aaron


On= Tue, Dec 03, 2024 at 9:06 PM, Aaron Jensen <aaronjensen@gmail.com> wrote:
I bisected and found that this patch caused a regr= ession in header-line formatting. I don't have the exact reproduction s= teps yet, but the gist is that I use a header-line with multiple=C2=A0faces= in one window, then open a new popup window that has no header-line. The o= riginal window's header-line will get its faces changed slightly, but i= t's hard to tell how.
<= br>
Here's a video demonstr= ating it:=C2=A0https:/= /share.cleanshot.com/CD9PtVv3

You can see that the padding on the left of the header line goes away= and the line numbers change to a variable pitch font. If I adjust my font = size, the header line redraws with the proper faces. This will happen rando= mly, but I can force it with the font size change reliably.

I'll see if I can narrow reproduction steps, but it may be worth= considering a revert for now.

Thanks,


Aaron<= /div>

--000000000000be91d306286bec4a-- From debbugs-submit-bounces@debbugs.gnu.org Wed Dec 04 08:49:46 2024 Received: (at 73862) by debbugs.gnu.org; 4 Dec 2024 13:49:47 +0000 Received: from localhost ([127.0.0.1]:34718 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tIpl9-0002KP-0V for submit@debbugs.gnu.org; Wed, 04 Dec 2024 08:49:46 -0500 Received: from eggs.gnu.org ([209.51.188.92]:57282) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tIpkz-0002K1-HK for 73862@debbugs.gnu.org; Wed, 04 Dec 2024 08:49:39 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tIpkt-0001I3-3U; Wed, 04 Dec 2024 08:49:27 -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=tcwqxifgoVelkLwpneyrv1zS1DVxT8nfhpPPosw5hdA=; b=f7bM2usiWffx w2gVL4S8ER2H0EwnQ2IwweK5YUyXfsmS2pLShS/eyCCmxgqA7xGJSyBow0Wz4VPamL51s4W67QBVN b+F5vbX3TOwqGb5T552SAKnHbqqNNi16WM6ywLT/tJ50DJTBDgSBwJqv0qRIESWQt4zAS+jgwuJ3x KZ/eNqc9+IrjU2Ahxt67CjolFidij7zEy4x14LuPmt2c/YBsBXBDTYBG3asJbcXhmlhlI9ilNILpG nPQGyLddRvsid3pgCBdmVswnIxLjU1Eqoj8KZCBXjwh8uYBaQWUtpodI6UDfj9wst5ck3NaT+0GaM bSBocLmFmRxCo8JxilcZ4g==; Date: Wed, 04 Dec 2024 15:49:23 +0200 Message-Id: <86wmgfzhgc.fsf@gnu.org> From: Eli Zaretskii To: Aaron Jensen , Trevor Murphy , Eshel Yaron In-Reply-To: (message from Aaron Jensen on Tue, 3 Dec 2024 22:30:58 -0800) Subject: Re: bug#73862: [PATCH] Add `header-line-active` and `header-line-inactive` faces. References: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 73862 Cc: 73862@debbugs.gnu.org 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: Aaron Jensen > Date: Tue, 3 Dec 2024 22:30:58 -0800 Aaron, it would have been more useful to CC Trevor, who is the author of that changeset. I've added him now. > I'm able to reproduce this with the mode-line as well, so it appears that there may be a bug there too in the > code that was copied to implement the active/inactive faces in the header line. It's entirely possible that > there's a bug in nano-modeline, but it seems suspect that code was added to consider windows and now this > issue triggers when new windows are created (and possibly when selection changes, I haven't eliminated > whether or not that's a factor yet). You were able to reproduce what? I don't think you posted a recipe to reproduce the problem. Please do, if at all possible, preferably starting from "emacs -Q". > From: Eshel Yaron > Cc: Trevor Murphy > Date: Wed, 04 Dec 2024 10:47:18 +0100 > > > Add new `header-line-active' and `header-line-inactive' faces > > > > This is all intended to parallel the 'mode-line-active' and > > 'mode-line-inactive' distinction. > [...] > > This seems to introduce a regression, consider the following recipe: > > 1. emacs -Q > 2. In the scratch buffer, evaluate: > (setq header-line-format "foobar") > (face-remap-add-relative 'header-line 'highlight) Aren't you supposed to remap the two new faces instead of 'header-line'? > 3. Type C-x C-M-= or something similar to force updating the header > line. The header line in the scratch buffer now shows "foobar" and > uses the highlight face, as expected > 4. Type C-x 4 b new RET to switch to another buffer in another window > 5. In the new buffer evaluate (setq header-line-format "foobar") > 6. Observe that the header line in the new buffer is also using the > highlight face. That's unexpected! > 7. Type C-x C-M-= while the new buffer is current > 8. Observe that the header lines in both windows no longer have the > highlight face. That's unexpected! > > Before, remapping the header-line face with face-remap-add-relative > would only affect the current buffer, as expected. Now it seems like > the face remapping "leaks" between buffers/windows somehow... Trevor, could you please look into this? From debbugs-submit-bounces@debbugs.gnu.org Wed Dec 04 22:07:35 2024 Received: (at 73862) by debbugs.gnu.org; 5 Dec 2024 03:07:35 +0000 Received: from localhost ([127.0.0.1]:37607 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tJ2DH-0000Oo-9e for submit@debbugs.gnu.org; Wed, 04 Dec 2024 22:07:35 -0500 Received: from mail-lj1-f180.google.com ([209.85.208.180]:61941) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tJ2DF-0000OY-JD for 73862@debbugs.gnu.org; Wed, 04 Dec 2024 22:07:34 -0500 Received: by mail-lj1-f180.google.com with SMTP id 38308e7fff4ca-2ffd796ba0aso3583831fa.3 for <73862@debbugs.gnu.org>; Wed, 04 Dec 2024 19:07:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1733367987; x=1733972787; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:references:from:in-reply-to :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=fO76f3TsnQ5Nh3R6g49Nm8e0kT0GPCXqsFxc1YTfz04=; b=gL8HbyYCp2+FpphfDEgO00q1tOwHza+f9mboVq7C4SWBS1QeNOO+MIGWvStCLf6r71 JCXbSQVvVfbNojhZRhD7NMRMaueu/3+5Dw7VjjrpKD9wHJKXFWs1STUN+Nz/usN7w3PJ fD0WAfCeC2/mgdM8qxYkuk1sO51S+M/0ExQ4NbVtocJcfsknnSVY2gNMsQ8xrh50Nffo BHRua1Do/bw/cj+wefqIS+u37vTeDBNl3+N8zhvAfCcL9uYirZ5y/7MtEQKK1auvtlGM mfGt5hfmsLn0EZztzjlgOHJ+A/vl6637g2s3Gvk163Lr9ByAkJTVmy35VnPWSnVsbsNa BeKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733367988; x=1733972788; h=cc:to:subject:message-id:date:references:from:in-reply-to :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=fO76f3TsnQ5Nh3R6g49Nm8e0kT0GPCXqsFxc1YTfz04=; b=do4E4ewj3PcLC38gLKDI4uiwDChLPYSt3qL7gHjF/QzQSJ9rTKDSukRp3k1WmCr8Z6 PSara+SVLKtHtMGle1ZjGacqVxBFZQl0f4IdnZOrBDfwiRzXXMYrUMGdb/fz7MJmfQw5 mP2RdOFQU3zvvzrNNJZTxxuUVhCPWD5RI/18LuVS6rTL4EkjlicsQSlaoL+se2VhCqMQ 5ovEy9dw5fHVR+O8NZM2PK5BxjI4aQOYhlIYsgpGVTDBJB5VtLnenG5SQI78bdzZ8IT4 tfYqAZk7cnGeBcNzKBUqFe4qh/16RuTN7o2IuXLxOn/Kul2RUS+DfxVV/SPIFCvpYfYg t7jQ== X-Forwarded-Encrypted: i=1; AJvYcCVVwYo50/nThYfBm9oElMYOQ+4HTHZ5UjIHuhcyqYL4dwQLrDBJVOvnUQY7R6ohyCqE2CjxJQ==@debbugs.gnu.org X-Gm-Message-State: AOJu0Ywc9XL6chkaAvN1Of2uB2gZb4dM4Qhdm8PyWyoDppeb5aQgE4tE ToiQk1AjhR3DgdEMt0qcyvE5etnqo3qEpshUibTFZ3lvh+fztqG5cKlkVNvVDAEC+ZbCuTJN6UL Sae5LOp1iuaZKnx7EMYD1JxFu7TI= X-Gm-Gg: ASbGncu9Auh9CcPWZgtBqycugnMk1thSPNU8d0CuWXigi98cfR7CbavbFD8vEbp7D3k GVzEIwNLsuFQHOiTmg+kPUVlpnnkD3a+kkJ67FyKQGH5bSPCYKV+/rzs= X-Google-Smtp-Source: AGHT+IHxs/L8AGkHUtp9kfH5+YPHTJhbaKKKxNnYniG58aqArP2fkZrIJRfVgZiWGfHe74UuE0OHlvbPyq1i9pg4peY= X-Received: by 2002:a2e:a5c1:0:b0:2ff:e5af:e67b with SMTP id 38308e7fff4ca-30009cb1899mr58014211fa.35.1733367987239; Wed, 04 Dec 2024 19:06:27 -0800 (PST) Received: from 649336022844 named unknown by gmailapi.google.com with HTTPREST; Wed, 4 Dec 2024 19:06:26 -0800 Mime-Version: 1.0 X-Mailer: Superhuman Desktop (2024-12-02T20:06:08Z) X-Superhuman-Draft-ID: draft0050474ea6c472d9 In-Reply-To: <86wmgfzhgc.fsf@gnu.org> From: Aaron Jensen X-Superhuman-ID: m4aqj618.b97eb954-04e7-46a9-bf78-8bf8e57f21c3 References: <86wmgfzhgc.fsf@gnu.org> Date: Wed, 4 Dec 2024 19:06:26 -0800 Message-ID: Subject: Re: bug#73862: [PATCH] Add `header-line-active` and `header-line-inactive` faces. To: Eli Zaretskii Content-Type: multipart/alternative; boundary="0000000000002508bc06287d2fb1" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 73862 Cc: Trevor Murphy , Eshel Yaron , 73862@debbugs.gnu.org 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.0 (-) --0000000000002508bc06287d2fb1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Dec 04, 2024 at 5:49 AM, Eli Zaretskii wrote: > Aaron, it would have been more useful to CC Trevor, who is the author of > that changeset. I've added him now. > > You're right, I realized that too late. Thank you for the reminder. I'm able to reproduce this with the mode-line as well, so it appears that > there may be a bug there too in the code that was copied to implement the > active/inactive faces in the header line. It's entirely possible that > there's a bug in nano-modeline, but it seems suspect that code was added = to > consider windows and now this issue triggers when new windows are created > (and possibly when selection changes, I haven't eliminated whether or not > that's a factor yet). > > You were able to reproduce what? I don't think you posted a recipe to > reproduce the problem. Please do, if at all possible, preferably starting > from "emacs -Q". > I didn't =E2=80=94 I thought I mentioned that. I had intended to provide on= e as soon as I had a chance to, but it turns out that Eshel encountered the same issue and provided a recipe (thank you, Eshel). The only difference in my case is that face-remap-set-base is used, rather than face-remap-add-relative. As far as I can tell, this same bug occurs in the mode-line as well as the header-line. I.e., there was an existing bug in the mode-line and it was replicated to the header-line after the two new faces were added. Thanks, Aaron --0000000000002508bc06287d2fb1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Dec 04, 2024 at 5:49 AM, Eli Zaretskii <eliz@gnu.org> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

Aaron, it would have been more useful to CC Trevor, who is the author of that changeset. I've added him now.


You're r= ight, I realized that too late. Thank you for the reminder.

I'm able to reproduce this with the mode-line as well, so it appears th= at there may be a bug there too in the code that was copied to implement the active/inactive faces in the header l= ine. It's entirely possible that there's a bug in nano-modeline, but it seems suspect that code was adde= d to consider windows and now this issue triggers when new windows are created (and possibly when selection ch= anges, I haven't eliminated whether or not that's a factor yet).

You were able to reproduce what? I don't think you posted a recipe to reproduce the problem. Please do, if at all possible, preferably starting from "emacs -Q".

<= /div>

I didn't =E2=80=94 I thought = I mentioned that. I had intended to provide one as soon as I had a chance t= o, but it turns out that Eshel encountered the same issue and provided a re= cipe (thank you, Eshel). The only difference in my case is that face-remap-= set-base is used, rather than face-remap-add-relative.

As far as I can tell, this same bug occurs in the mode-line as wel= l as the header-line. I.e., there was an existing bug in the mode-line and = it was replicated to the header-line after the two new faces were added.

Thanks,

Aaron
=
--0000000000002508bc06287d2fb1-- From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 05 01:22:29 2024 Received: (at 73862) by debbugs.gnu.org; 5 Dec 2024 06:22:29 +0000 Received: from localhost ([127.0.0.1]:37833 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tJ5Ft-0001W3-DE for submit@debbugs.gnu.org; Thu, 05 Dec 2024 01:22:29 -0500 Received: from eggs.gnu.org ([209.51.188.92]:39114) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tJ5Fr-0001Vn-DD for 73862@debbugs.gnu.org; Thu, 05 Dec 2024 01:22:28 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tJ5Fl-00029X-Pz; Thu, 05 Dec 2024 01:22:21 -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=SsPjS6Kwsu+np490hYlLvxh646Uhvu2PocazNzpzZ9Y=; b=YzT65drH99AgVmBoMJKZ VZIbWR2zNbKqRl0z9NMF4xWp+8H1HUgQoeTkpp6Z9puE+3ubJTzxm8mpfPK+hZPnh52LrGOaGttB4 a6upU6Ec3F9WzowX85gIJWPAoDFvYC+8oUDcITcu8DwLqlhDO/BlcjBKNf1Qq5nPgOwK8pz7JOeRP jzRSSyvvA9KMYxN0HEVyR8DJD5n6DcpeZzOcU1IaGzxrvX22C4Py4vfi/p5XmwvVWlKGuZJtgRxle qTUGeNFzckqBga/4YgYN8iaUmt9YKZS6GcvXXTO6gTbTUQzot8oCgjgqpzBEIYzYbRqXlzLc87x8I crWPbZzIPGybZw==; Date: Thu, 05 Dec 2024 08:22:18 +0200 Message-Id: <86zflay7hh.fsf@gnu.org> From: Eli Zaretskii To: Aaron Jensen In-Reply-To: (message from Aaron Jensen on Wed, 4 Dec 2024 19:06:26 -0800) Subject: Re: bug#73862: [PATCH] Add `header-line-active` and `header-line-inactive` faces. References: <86wmgfzhgc.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 73862 Cc: trevor.m.murphy@gmail.com, me@eshelyaron.com, 73862@debbugs.gnu.org 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: Aaron Jensen > Date: Wed, 4 Dec 2024 19:06:26 -0800 > Cc: Trevor Murphy , Eshel Yaron , 73862@debbugs.gnu.org > > You were able to reproduce what? I don't think you posted a recipe to reproduce the problem. Please > do, if at all possible, preferably starting from "emacs -Q". > > I didn't — I thought I mentioned that. I had intended to provide one as soon as I had a chance to, but it turns > out that Eshel encountered the same issue and provided a recipe (thank you, Eshel). The only difference in > my case is that face-remap-set-base is used, rather than face-remap-add-relative. > > As far as I can tell, this same bug occurs in the mode-line as well as the header-line. I.e., there was an > existing bug in the mode-line and it was replicated to the header-line after the two new faces were added. If what you see is the same as Eshel, I will ask you the same question: shouldn't you apply face-remapping to the 2 new faces instead of the 'header-line' face from which they both inherit? What happens if you do define remapping for those two new faces? From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 05 01:50:45 2024 Received: (at 73862) by debbugs.gnu.org; 5 Dec 2024 06:50:45 +0000 Received: from localhost ([127.0.0.1]:37887 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tJ5hE-0002zg-TJ for submit@debbugs.gnu.org; Thu, 05 Dec 2024 01:50:45 -0500 Received: from mail.eshelyaron.com ([107.175.124.16]:41502 helo=eshelyaron.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tJ5hC-0002zV-DP for 73862@debbugs.gnu.org; Thu, 05 Dec 2024 01:50:43 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eshelyaron.com; s=mail; t=1733381441; bh=/67HOAtN/MDMkh7QgYKomRRv7cNieVN8m/HmAmUbu7o=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=BKfn052mZLLePU0Lyp0dYKQ3mLQaAEp7zmgGVvh60HezSf73Zezi1HbdC3uqcuhQ7 /uc5krz4b/K/1Gs/+uTUinaKRXQf3c5SZR3JBnfJnNwuvzj4fK08onWP90HA6pSDEX fhRkjzaDeGC8iFWO2OeDbO1zAUKz0hdrbwy9Y34RS4kWeYi3fm0GiGL4LQcypcDeag OaBpsyBl6t+oHB+2aYsGdpjsr7oyf6tEmHaxru0qjLMCq775jqtS40ya5y3OEKDzCu susGXUklL/kNhlTWrfOVL6aoMNOTHmxg8y0pmKKkI0nfGqvcJaJALHZO8o9BzVhe6a VF84iOyVGM/TA== From: Eshel Yaron To: Eli Zaretskii Subject: Re: bug#73862: [PATCH] Add `header-line-active` and `header-line-inactive` faces. In-Reply-To: <86zflay7hh.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 05 Dec 2024 08:22:18 +0200") References: <86wmgfzhgc.fsf@gnu.org> <86zflay7hh.fsf@gnu.org> Date: Thu, 05 Dec 2024 07:50:38 +0100 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 73862 Cc: trevor.m.murphy@gmail.com, 73862@debbugs.gnu.org, Aaron Jensen 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.0 (-) Hi Eli, Eli Zaretskii writes: >> From: Aaron Jensen >> Date: Wed, 4 Dec 2024 19:06:26 -0800 >> Cc: Trevor Murphy , Eshel Yaron , 73862@debbugs.gnu.org >>=20 >> You were able to reproduce what? I don't think you posted a recipe to r= eproduce the problem. Please >> do, if at all possible, preferably starting from "emacs -Q". >>=20 >> I didn't =E2=80=94 I thought I mentioned that. I had intended to provide= one as soon as I had a chance to, but it turns >> out that Eshel encountered the same issue and provided a recipe (thank y= ou, Eshel). The only difference in >> my case is that face-remap-set-base is used, rather than face-remap-add-= relative. >>=20 >> As far as I can tell, this same bug occurs in the mode-line as well as t= he header-line. I.e., there was an >> existing bug in the mode-line and it was replicated to the header-line a= fter the two new faces were added. > > If what you see is the same as Eshel, I will ask you the same > question: shouldn't you apply face-remapping to the 2 new faces > instead of the 'header-line' face from which they both inherit? > What happens if you do define remapping for those two new faces? At least to me, it's not clear what you mean by "should". Existing code remaps the header-line face with good results (prior to this change), so if we now "should" remap something else instead to get the same results, that means this is a breaking change. Is that intended? If so, OK, if not, shouldn't it be fixed? :) Thanks, Eshel From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 05 01:54:35 2024 Received: (at 73862) by debbugs.gnu.org; 5 Dec 2024 06:54:35 +0000 Received: from localhost ([127.0.0.1]:37892 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tJ5kw-00036O-LU for submit@debbugs.gnu.org; Thu, 05 Dec 2024 01:54:34 -0500 Received: from mail-lj1-f174.google.com ([209.85.208.174]:57689) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tJ5ku-00036C-CH for 73862@debbugs.gnu.org; Thu, 05 Dec 2024 01:54:32 -0500 Received: by mail-lj1-f174.google.com with SMTP id 38308e7fff4ca-2ffa8df8850so4989541fa.3 for <73862@debbugs.gnu.org>; Wed, 04 Dec 2024 22:54:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1733381611; x=1733986411; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:references:from:in-reply-to :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=vzahV4wV3IZkuiEs7nmiYIenQPcDvnWol4snWQMBtkY=; b=A9muZwTwthFmf+V20ebwL57bolqe0NBSGW3xJHAUQjJ7exqWnTKo63SRcIV0WlGOPH TOpsVOj8ezjz448tt6aZV642BZE6WicRjXbJZBkvpgVZc57GM6lRW1jwG7pQslJqoR5Y oC3Fg0L+Za0p/yIAKkic8NgUGFaNo9SvtojbHhsDKSxMeK60lGsJqhrfLVxP2jYyCQxe erSdxZD+nJ3cv9W24fKcdlank6VDYvkaNTp0HA+0qlrIHqWvcOc3FOwZGtwNnOO3zjhu 2qI+7ipGEW9xD6yAfoomjHkphmS3x/FuSWz3XuDjkL/cH2Baz9r4Ovqbfp8nbwHPqswn Ljww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733381611; x=1733986411; h=cc:to:subject:message-id:date:references:from:in-reply-to :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=vzahV4wV3IZkuiEs7nmiYIenQPcDvnWol4snWQMBtkY=; b=F4sSaVQ94JyRrZh+8GwWWM2QZ+iBpt9YncdYOA2JEbB1+lc7OTcCMgUrcnlONHnSEw 6zZ8ELLrmGE9F/yt1enb3XeThE16+oXdFdDEhuQ9vZ6sigsyrnrwQ594mfxrjFFoyr9U m4ng1foZy0cPAsLrVoYkRcOAM7qQ9mAJRRuVhkfbPP0KYaLmDcth6S0Fuacxu3qCTGnX 8CQk7Qf/wqx/y2kn/1mgJUcIjlbBfvxWDufF0IhU1o8KTLTOmFz90xKIreOpErZhd6aJ //EqS3W0wjgpMfZXmg/ZAVNsSSXTsThkHz39eo+r5TnHZsSd236YXZSeYQ3qAgZsI65n M1Qw== X-Forwarded-Encrypted: i=1; AJvYcCUz0mfvRxJMchjQlYBYqBhTB/SAQzyYEUSuwCVgYkrIGze50zuSOA5bWUh6ltYooF4aP2XejQ==@debbugs.gnu.org X-Gm-Message-State: AOJu0YwCkqzV9otlSiBbqTX59yuGbTV7WvmWHA0XsE2CC8OmDPWTnwX5 lxd1HTlFcdFVhQAztH2IYrhVLuJdDQKEyUNCcv343zyQYsPF7GqaEegD8a0huxD1K7e1rDuCN0p N/xfWTEHXEtSoLyZ34eNjVO8KLng= X-Gm-Gg: ASbGncvSOtWOBp6vAfcMRXGyKSaViKuCdIq7ttyL24wcxgfErc8l02Fu+f+0RIYiMNo Q7eYsvj8yMG0BPyQZUljCgWJVrEJ6c79XOZwjqU3EAodhH9rw8lV1Dow= X-Google-Smtp-Source: AGHT+IEeF4YxSUqVUmgS77zvSqya5TiR1I7DgpPsHROfQ0Q9tCCUY+YCrIsnHxe4iXnK5UjMf6fyo7jaNuUBRf7/U3A= X-Received: by 2002:a05:651c:b14:b0:2ff:dee8:1d18 with SMTP id 38308e7fff4ca-30009d29ad7mr58569001fa.34.1733381611062; Wed, 04 Dec 2024 22:53:31 -0800 (PST) Received: from 649336022844 named unknown by gmailapi.google.com with HTTPREST; Thu, 5 Dec 2024 01:53:30 -0500 Mime-Version: 1.0 X-Mailer: Superhuman Desktop (2024-12-02T20:06:08Z) X-Superhuman-Draft-ID: draft00ab9083cd1ca4b7 In-Reply-To: <86zflay7hh.fsf@gnu.org> From: Aaron Jensen X-Superhuman-ID: m4ayneps.70c40138-b82b-48cb-9e87-9b641d47fbae References: <86wmgfzhgc.fsf@gnu.org> <86zflay7hh.fsf@gnu.org> Date: Thu, 5 Dec 2024 01:53:30 -0500 Message-ID: Subject: Re: bug#73862: [PATCH] Add `header-line-active` and `header-line-inactive` faces. To: Eli Zaretskii Content-Type: multipart/alternative; boundary="0000000000003011290628805be4" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 73862 Cc: trevor.m.murphy@gmail.com, me@eshelyaron.com, 73862@debbugs.gnu.org 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.0 (-) --0000000000003011290628805be4 Content-Type: text/plain; charset="UTF-8" > > If what you see is the same as Eshel, I will ask you the same question: > shouldn't you apply face-remapping to the 2 new faces instead of the > 'header-line' face from which they both inherit? What happens if you do > define remapping for those two new faces? > My specific problem does not occur if I remap the two new faces. Why would I need to do that though? Both inherit from header-line, so if I wanted to change both, I would naturally change the base face. Furthermore, this problem only happens *once* per Emacs session. After that, I cannot seem to reproduce it again until I restart Emacs. All of this points to a bug, in my opinion unless header-line is considered deprecated or somehow falls into a realm of not being able to remap for some reason. Thanks, --0000000000003011290628805be4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

If what you see is the same as Eshel, I will ask you the same question: shouldn't you apply face-remapping to the 2 new faces instead of the 'header-line' face from which they both inherit? What happens if you do define remapping for those two new faces?


My s= pecific problem does not occur if I remap the two new faces. Why would=C2= =A0I need to do that though? Both inherit from header-line, so if I wanted = to change both, I would naturally change the base face.

<= /div>
Furthermore, this problem only happens *once* per Emacs session. = After that, I cannot seem to reproduce it again until I restart Emacs. All = of this points to a bug, in my opinion unless header-line is considered dep= recated or somehow falls into a realm of not being able to remap for some r= eason.=C2=A0

Thanks,
--0000000000003011290628805be4-- From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 05 02:30:41 2024 Received: (at 73862) by debbugs.gnu.org; 5 Dec 2024 07:30:42 +0000 Received: from localhost ([127.0.0.1]:37974 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tJ6Jt-0004wG-Ew for submit@debbugs.gnu.org; Thu, 05 Dec 2024 02:30:41 -0500 Received: from mail-lj1-f182.google.com ([209.85.208.182]:52333) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tJ6Jr-0004vz-8A for 73862@debbugs.gnu.org; Thu, 05 Dec 2024 02:30:40 -0500 Received: by mail-lj1-f182.google.com with SMTP id 38308e7fff4ca-2ffc76368c6so4986621fa.0 for <73862@debbugs.gnu.org>; Wed, 04 Dec 2024 23:30:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1733383773; x=1733988573; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=zhQ0FjnA7N3RVfsMvGq5ayMjnkeshTLzyYMsHI1oMl0=; b=TY371sKhPeWPxesOS+LP6P35KAvRCDqG6NeevaFAyOPYbzyo0PFlXyLIhpSkkHg1lg ATrHC8BMdD6W4HG/mvrveTZQDnPVXDFDNRPXJp5f6ZIy+SWlIKS1GR5CRMMnRDoe8eNY SEjZ5I9FrgxP4X/OwjoNOF0uwrQt+qP9fA41UcPDKimvcZKyAxxW6NnNhMeOGLVEIRrI YNvpTASOUCkGEq1sBCe6Y+4zJAb9baJF0tembODmfFCYKkJv8+5acdHVG3IPL+L5TDKn yVEybUADy6KHu2ROXfnJU8hrhhp6pzzP4azeoXsOCRxDtSMhg5ZFz1J6f3+s9zCjp4BD 2NdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733383773; x=1733988573; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=zhQ0FjnA7N3RVfsMvGq5ayMjnkeshTLzyYMsHI1oMl0=; b=vcRwl3iJj7SMpWKLwsE9hbE1BhyAepXblZVHn0kwevRNbZf0IuKYOFYeR0rp8ngvY+ GrnpsKs+EACr+deLEbJlZ2KZ9Ij8leQMX2e2wNAc9KRGHipaTcwqeyhCYmKIPOb+0sV2 Siq3qBXlrSgO8jsIQlEqbbP7PIhiOu2Aw3DNIldyis8AREuDPy7hOk0cRz+2MzZs1I/R rYjzpAeFijczvc9gSGrkfOYZQujvTwNYcaOQEkYRPhQrQVm1JhTSNMBVh8uNOjMXDR5h i++VwOwCTXcT05H3qtjzxyowUIMJT1R6QyW1cYG2P8j6KdQsp6S9rbdKYFPFJ6AN6kRA Qv6A== X-Forwarded-Encrypted: i=1; AJvYcCWYVXyQWp9o78TOTvaISg33qJBxKmnqPOvN0FikLvYaVNbZ/TLVKdYu4soU+/WKRA0WPkgtaQ==@debbugs.gnu.org X-Gm-Message-State: AOJu0Yw9YzMMuoFxe9AhLa9k53MftwVU/afM3ivaIbbAu5fvUbP+WY2k brd8465XylR3ZbIDIcnelajojNbM1O+lYjsmXiyr/fIwABQaNcyhxjn/FfIIQVpuQ7j+YCPqF5D zKQCeAZsg6FFENIUV15esBXiHXJM= X-Gm-Gg: ASbGncv8LI+91pR9LgP3IqjN/ddT5aBKonZPWMHui0MrHd3IAqGvcJNQXVF/wdmHPzQ WG9P3pMxzvM3lacHryMpqPIPQgBmTQqu4g70tEGjbWLanRkfzhxpuMLA= X-Google-Smtp-Source: AGHT+IHoYDKmfbRMaXPDm9SmtdCANaEumgWDRRtQTMbHXPyLrQZvDHR/jNnbTc7NZzDYwPah+c/L0v0hp0BOeoeG8HE= X-Received: by 2002:a05:651c:892:b0:2ff:c77c:c71e with SMTP id 38308e7fff4ca-30009c9e079mr78020531fa.20.1733383773058; Wed, 04 Dec 2024 23:29:33 -0800 (PST) Received: from 649336022844 named unknown by gmailapi.google.com with HTTPREST; Wed, 4 Dec 2024 23:29:32 -0800 Mime-Version: 1.0 In-Reply-To: References: <86wmgfzhgc.fsf@gnu.org> <86zflay7hh.fsf@gnu.org> X-Mailer: Superhuman Desktop (2024-12-02T20:06:08Z) X-Superhuman-ID: m4azxvub.08a8249e-f8ea-4a5f-bca0-3bf62d9f613f X-Superhuman-Draft-ID: draft00dd2835baf7a020 From: Aaron Jensen Date: Wed, 4 Dec 2024 23:29:32 -0800 Message-ID: Subject: Re: bug#73862: [PATCH] Add `header-line-active` and `header-line-inactive` faces. To: Eli Zaretskii Content-Type: multipart/alternative; boundary="0000000000000d7f69062880dcab" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 73862 Cc: trevor.m.murphy@gmail.com, me@eshelyaron.com, 73862@debbugs.gnu.org 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.0 (-) --0000000000000d7f69062880dcab Content-Type: text/plain; charset="UTF-8" On Wed, Dec 04, 2024 at 10:53 PM, Aaron Jensen wrote: > Furthermore, this problem only happens *once* per Emacs session. After > that, I cannot seem to reproduce it again until I restart Emacs. All of > this points to a bug, in my opinion unless header-line is considered > deprecated or somehow falls into a realm of not being able to remap for > some reason. > This may be obvious to you all, and me going much further probably isn't realistic, but I am curious if there's a problem in the resolving of inherited remapped faces while changing windows. Specifically that it appears to use the lack of remap in the newly created window to resolve the remap in the original window. The remapping of the active/inactive faces happens explicitly inside display_mode_line / init_iterator with an explicit window reference. I don't know enough to know where the inherited faces get remapped, but if the window used to remap them is incorrect (because it's the current window, rather than the window the mode/header line is being drawn in), I could see there being the issue we're observing. Not sure if that helps, but that's as far as I was able to get in my investigation so far. Thanks, --0000000000000d7f69062880dcab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Dec 04, 2024 at 10:53 PM, Aaron Jensen= <aaronjensen@gmail.com> wrote:
Furthermore, this problem only happen= s *once* per Emacs session. After that, I cannot seem to reproduce it again= until I restart Emacs. All of this points to a bug, in my opinion unless h= eader-line is considered deprecated or somehow falls into a realm of not be= ing able to remap for some reason.=C2=A0
<= /div>
<= br>
This may be obvious to you all, and me going much = further probably isn't realistic, but I am curious if there's a pro= blem in the resolving of inherited remapped faces while changing windows. S= pecifically that it appears to use the lack of remap in the newly created w= indow to resolve the remap in the original window. The remapping of the act= ive/inactive faces happens explicitly inside display_mode_line / init_itera= tor with an explicit window reference. I don't know enough to know wher= e the inherited faces get remapped, but if the window used to remap them is= incorrect (because it's the current window, rather than the window the= mode/header line is being drawn in), I could see there being the issue we&= #39;re observing.

Not su= re if that helps, but that's as far as I was able=C2=A0to get in my inv= estigation so far.

Thank= s,
--0000000000000d7f69062880dcab-- From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 05 02:31:52 2024 Received: (at 73862) by debbugs.gnu.org; 5 Dec 2024 07:31:52 +0000 Received: from localhost ([127.0.0.1]:37979 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tJ6L2-0004yK-0v for submit@debbugs.gnu.org; Thu, 05 Dec 2024 02:31:52 -0500 Received: from eggs.gnu.org ([209.51.188.92]:54238) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tJ6L0-0004y2-3D for 73862@debbugs.gnu.org; Thu, 05 Dec 2024 02:31:50 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tJ6Kt-00027v-EI; Thu, 05 Dec 2024 02:31:43 -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=ehQVoonyEk6tsDwUyjfi+ktb5PHpunSY/qOxUFvzMLc=; b=mew02rWFUsPT 7JfcjVpS8OzaYO5aIy35LbNaFSel9iAV4RsSUhRVH0lK1eg5IClZvtINaxwZafd5SMPDF3e+lCzXe AgXI/06eTPtlBeJFxAZhJoUyelwsWpbLq5yOQqP2TvCj0iNcAyRUoGUg/sF9o79ZNrh36PVey5CTn TG+ivxv/nAMN/xupR5EVzixuhjpNQ29/rmSGPECKGgUTZCmtMILVfNTx9kpt8xdOQhkFHNycPi/g9 7wldyLA9wHOg7BT4qmDLWfniF+RYvEPd/rwOhksgi2Cw7RAoTf3lRepKYhiWhUs0ttzl7QqA+yTJm NyRStuxNWi4Ipoy3RCeN6A==; Date: Thu, 05 Dec 2024 09:31:39 +0200 Message-Id: <86r06my49w.fsf@gnu.org> From: Eli Zaretskii To: Eshel Yaron In-Reply-To: (message from Eshel Yaron on Thu, 05 Dec 2024 07:50:38 +0100) Subject: Re: bug#73862: [PATCH] Add `header-line-active` and `header-line-inactive` faces. References: <86wmgfzhgc.fsf@gnu.org> <86zflay7hh.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 73862 Cc: trevor.m.murphy@gmail.com, 73862@debbugs.gnu.org, aaronjensen@gmail.com 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: Eshel Yaron > Cc: Aaron Jensen , trevor.m.murphy@gmail.com, > 73862@debbugs.gnu.org > Date: Thu, 05 Dec 2024 07:50:38 +0100 > > > If what you see is the same as Eshel, I will ask you the same > > question: shouldn't you apply face-remapping to the 2 new faces > > instead of the 'header-line' face from which they both inherit? > > What happens if you do define remapping for those two new faces? > > At least to me, it's not clear what you mean by "should". Existing code > remaps the header-line face with good results (prior to this change), so > if we now "should" remap something else instead to get the same results, > that means this is a breaking change. Is that intended? If so, OK, if > not, shouldn't it be fixed? :) Let's first understand the scope of the problem, shall we? If remapping the two new faces does what you want, then the only problem is in backward-incompatible nature of this change, when face remapping is considered. If remapping the two new faces does NOT do what you want, the problem is elsewhere. More to the point you raise: when we introduced mode-line-active face, the same happened with the 2 mode-line faces. We should indeed decide whether we need to support remapping the parent mode-line and header-line faces, but at least for mode line we don't, since Emacs 29. From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 05 02:35:42 2024 Received: (at 73862) by debbugs.gnu.org; 5 Dec 2024 07:35:42 +0000 Received: from localhost ([127.0.0.1]:37991 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tJ6Ok-0005BE-8b for submit@debbugs.gnu.org; Thu, 05 Dec 2024 02:35:42 -0500 Received: from eggs.gnu.org ([209.51.188.92]:34166) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tJ6Oi-0005Az-Nh for 73862@debbugs.gnu.org; Thu, 05 Dec 2024 02:35:41 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tJ6Od-0003HG-HD; Thu, 05 Dec 2024 02:35:35 -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=i+G+DVnloH1YognLiD9aixpD7Eead+GHcY5+a3Z9g5o=; b=krhzBgzsBlgc YWEGI1mUZfrHjafw9FxtlOY5sPiqP+5eBaqMaFg6UQFAsnAFH97oxGvOON/lWdg5DPsGrlQGDMgZ/ B25FW22V1aB1vvKOfn41Sb3YuYPP5LHcOj2xaqtDrcUVdkWc47ohpjTsaxUkBzevFuOIOBNHPEI9v QlMGczWr8OWj6Z8sdpu25+PxR9tV/10uJ6s3QvGHJVfbkTMAOsLzNygCuO8cp57PdzzVpW6n3lx7a zL04QKBIp9n1RkxikF5d5P0A/VXbGm0GF9EsQ7erlG2kc0rUTAQFpJMWM1ROHtCpfroxULo6QDAOV 1VYb3ta/aCCTBzewd/eESw==; Date: Thu, 05 Dec 2024 09:35:31 +0200 Message-Id: <86plm6y43g.fsf@gnu.org> From: Eli Zaretskii To: Aaron Jensen In-Reply-To: (message from Aaron Jensen on Thu, 5 Dec 2024 01:53:30 -0500) Subject: Re: bug#73862: [PATCH] Add `header-line-active` and `header-line-inactive` faces. References: <86wmgfzhgc.fsf@gnu.org> <86zflay7hh.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 73862 Cc: trevor.m.murphy@gmail.com, me@eshelyaron.com, 73862@debbugs.gnu.org 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: Aaron Jensen > Date: Thu, 5 Dec 2024 01:53:30 -0500 > Cc: trevor.m.murphy@gmail.com, me@eshelyaron.com, 73862@debbugs.gnu.org > > If what you see is the same as Eshel, I will ask you the same question: shouldn't you apply > face-remapping to the 2 new faces instead of the 'header-line' face from which they both inherit? What > happens if you do define remapping for those two new faces? > > My specific problem does not occur if I remap the two new faces. Why would I need to do that though? Both > inherit from header-line, so if I wanted to change both, I would naturally change the base face. Technically, because mode-line and header-line are no longer considered "basic faces", and because the display code uses these faces directly in C. > Furthermore, this problem only happens *once* per Emacs session. After that, I cannot seem to reproduce it > again until I restart Emacs. All of this points to a bug, in my opinion unless header-line is considered > deprecated or somehow falls into a realm of not being able to remap for some reason. What exactly happens "once per session"? Can you show some Lisp to reproduce this "once" occurrence? From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 05 02:51:42 2024 Received: (at 73862) by debbugs.gnu.org; 5 Dec 2024 07:51:42 +0000 Received: from localhost ([127.0.0.1]:38020 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tJ6eD-0005uk-JV for submit@debbugs.gnu.org; Thu, 05 Dec 2024 02:51:42 -0500 Received: from eggs.gnu.org ([209.51.188.92]:35914) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tJ6eA-0005uN-Tl for 73862@debbugs.gnu.org; Thu, 05 Dec 2024 02:51:39 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tJ6e5-0001ri-8q; Thu, 05 Dec 2024 02:51:33 -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=HP8XsURPtYWz4mZD/AjtQA+aKNcxtn6qQKp77dSoq6c=; b=GLuxKkn2kRyn MI9BHwL4TH+inEdU+SHPnO178TRwQ90Ya28Zihkw+dELXGzi2Gw/KQT+nW1rwmHgwCWGrAHFc0V1b S8ZYBJgtxqBTzlmel3oMAzsAVU2T77ZMX8OuMqZkwye2o4ln8lv5UeJPfjRkouCF3xrPsRq3hyeSW FgHMc/UKznZxdLs+F5owCOw7gWq7b3BvgpOSOEjJTe10j75r243jCyuqrN+MG3jcfBLTbZGNEtC3S ABx47Pw2gcO50j+Mq7d5PfoYiJ6UGdCvTBrTvaDnVu2RTafeD1zWSe+LnKgCKniWFB4PUTSjGFq0j SF1sMVgua806fewyamzhtw==; Date: Thu, 05 Dec 2024 09:51:29 +0200 Message-Id: <86jzcey3cu.fsf@gnu.org> From: Eli Zaretskii To: Aaron Jensen In-Reply-To: (message from Aaron Jensen on Wed, 4 Dec 2024 23:29:32 -0800) Subject: Re: bug#73862: [PATCH] Add `header-line-active` and `header-line-inactive` faces. References: <86wmgfzhgc.fsf@gnu.org> <86zflay7hh.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 73862 Cc: trevor.m.murphy@gmail.com, me@eshelyaron.com, 73862@debbugs.gnu.org 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: Aaron Jensen > Date: Wed, 4 Dec 2024 23:29:32 -0800 > Cc: trevor.m.murphy@gmail.com, me@eshelyaron.com, 73862@debbugs.gnu.org > > Furthermore, this problem only happens *once* per Emacs session. After that, I cannot seem to > reproduce it again until I restart Emacs. All of this points to a bug, in my opinion unless header-line is > considered deprecated or somehow falls into a realm of not being able to remap for some reason. > > This may be obvious to you all, and me going much further probably isn't realistic, but I am curious if there's > a problem in the resolving of inherited remapped faces while changing windows. Specifically that it appears > to use the lack of remap in the newly created window to resolve the remap in the original window. The > remapping of the active/inactive faces happens explicitly inside display_mode_line / init_iterator with an > explicit window reference. I don't know enough to know where the inherited faces get remapped, but if the > window used to remap them is incorrect (because it's the current window, rather than the window the > mode/header line is being drawn in), I could see there being the issue we're observing. > > Not sure if that helps, but that's as far as I was able to get in my investigation so far. Once again, please show some simple Lisp to reproduce the phenomena you are observing. It is hard to discuss these highly technical issues on this abstract level. On the very basic level of the display code, when a display iterator is initialized, the window for whose display the iterator is used must be given to init_iterator as its argument, and the buffer of that window must be temporarily made to be the current buffer. So this cannot be the problem in this case. If init_iterator would be passed an incorrect window, we'd have much more grave display problems than this minor issue. From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 05 11:03:16 2024 Received: (at 73862) by debbugs.gnu.org; 5 Dec 2024 16:03:16 +0000 Received: from localhost ([127.0.0.1]:40402 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tJEJw-0004j0-31 for submit@debbugs.gnu.org; Thu, 05 Dec 2024 11:03:16 -0500 Received: from mail-lj1-f173.google.com ([209.85.208.173]:56590) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tJEJu-0004ie-JX for 73862@debbugs.gnu.org; Thu, 05 Dec 2024 11:03:15 -0500 Received: by mail-lj1-f173.google.com with SMTP id 38308e7fff4ca-2ffbea0acc2so11765241fa.1 for <73862@debbugs.gnu.org>; Thu, 05 Dec 2024 08:03:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1733414528; x=1734019328; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=tH1yxgJuf/PHU5dfe/nQ82W+3kBy/ISaoD7qiMnmpRk=; b=PkK9c+HLHRMGFSQe4nlVFJLbULETJH2ig22tzfC1nAD+riNKWuu598hfDhVRVGTd5t ZMgQqWTyIDbDnurcijISDfweandwvmcVXlx0vtNAPxhQP60C3QI1kb+A1t8GNjUSKBQH 8KGoQqNble9rhvDN9BMrhsY61QQI5psSbtWvqX/aBMwTvioODlcbXIPqxvRJ6cBxt/Iz vJ3lsAM+FWz26NgCD9msKQGC3pRLHTwLOEFDo7qNEf0aGGq+n66pCo1RkybBpj3HySR0 x6zLXH8uqK1b8f/1zHFVpnfyACI7yCcuYWWwVEzz2NIU2mZEjLcjZonOBmx0A7j9UQOn CnTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733414528; x=1734019328; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=tH1yxgJuf/PHU5dfe/nQ82W+3kBy/ISaoD7qiMnmpRk=; b=erckO54MqmQ99Fc9vIkpuSHSU6c+3qGLtf9jX3SHNyvgmn/ONia0dNNFQjvZTC+5Jf lKjZX5wTx/aArrHGtFZjuG+lHN7ZMvUrfAK1+T6kl9Kl/BKrb5afjBp+5dJPwF+eUMPe wctrRpfRW1YFpUDPhwKo23FKzQ3FTOKpQQ0IBzgT01oNKLmyJrFkunanELj01mJ+xwxQ sZPoA7KEu6rZKe9EESiInuXsrN6czp06+Cs/Rk4bqSZLV8PKgc2wYv/gqwwyeEPcUSHX uqR4USuZ43lLg3bo/TCCpNIelHCMlraP4/3lecmB9jf08CNbrvzmLXLbGTE7dLfMIBBb ANYQ== X-Forwarded-Encrypted: i=1; AJvYcCUgMGLwT3mN5LeDio9MRF+1n96apLVr4aYP7WV93jFL12pLk7EhgVjxTsc7FN6FZKLdc20wbA==@debbugs.gnu.org X-Gm-Message-State: AOJu0YwXCqpoZfaJ2L4Q36vjYAwUND2T3+PBbyc0ttfpKYAdZsuZLIUc 24b8zg8Oe9/H61TxMZOdxtG+DjVeGsgQezBwdZFk2pgCCYHwHBI/7QSPJD3XcGdAlLXKHIX7chr 97CzmCI94UdxW+9E8sWtycntw63w= X-Gm-Gg: ASbGncsy7CVonoj4amqc82RXkaIhB8OA0CiNPepZzNbSZTUxnadh+BwqSAcyaW3AvvS cO+cuUo/h0B/FiJRtGQz5+DUC3P+PwV/ARqsoM9MWxQ7Io5OGbegZ2Fw= X-Google-Smtp-Source: AGHT+IFamNytGYeJZ+Is/r+mcaqcBHVtOWGEMUp4zv+DXt8yZMpVdw5ldtB9PGzh8wxyC0hFLQc2k86gK9Im0qap/W8= X-Received: by 2002:a05:651c:19aa:b0:2ff:8d3b:46d3 with SMTP id 38308e7fff4ca-30009ca95f6mr65995811fa.16.1733414527567; Thu, 05 Dec 2024 08:02:07 -0800 (PST) Received: from 649336022844 named unknown by gmailapi.google.com with HTTPREST; Thu, 5 Dec 2024 08:02:06 -0800 Mime-Version: 1.0 In-Reply-To: <86jzcey3cu.fsf@gnu.org> X-Superhuman-Draft-ID: draft0043c536078e30ca References: <86wmgfzhgc.fsf@gnu.org> <86zflay7hh.fsf@gnu.org> <86jzcey3cu.fsf@gnu.org> From: Aaron Jensen X-Mailer: Superhuman Desktop (2024-12-02T20:06:08Z) X-Superhuman-ID: m4bi8ojp.932d78cf-1c5c-4747-b628-06ece6ff32d9 Date: Thu, 5 Dec 2024 08:02:06 -0800 Message-ID: Subject: Re: bug#73862: [PATCH] Add `header-line-active` and `header-line-inactive` faces. To: Eli Zaretskii Content-Type: multipart/alternative; boundary="0000000000002a1c030628880541" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 73862 Cc: trevor.m.murphy@gmail.com, me@eshelyaron.com, 73862@debbugs.gnu.org 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.0 (-) --0000000000002a1c030628880541 Content-Type: text/plain; charset="UTF-8" On Wed, Dec 04, 2024 at 11:51 PM, Eli Zaretskii wrote: > Once again, please show some simple Lisp to reproduce the phenomena you > are observing. It is hard to discuss these highly technical issues on this > abstract level. > Happy to. Sorry, I didn't think it was necessary given Eshel's providing of the recipe. It wasn't lisp though, so here's the lisp version from emacs -Q: 1. (setq header-line-format "Some Header") 2. (face-remap-set-base 'header-line 'highlight) 3. (set-face-attribute 'default nil :height (+ (face-attribute 'default :height) 10)) 4. (switch-to-buffer-other-window "new") 5. From within new buffer/window: (set-face-attribute 'default nil :height (+ (face-attribute 'default :height) 10)) You'll see after step 3 the header line switches to the highlight face. After step 5, the header line in the original buffer switches away from the highlight face, which is unexpected. If you then switch back to the original buffer and change the font size again, the highlight will display again. Switching back to the new buffer and changing the font size causes it to disappear again, so I was mistaken about it only happening once. It just so happens that a full redisplay only triggers once for me in my normal usage when I have a window without the header line override specified. On the very basic level of the display code, when a display iterator is > initialized, the window for whose display the iterator is used must be > given to init_iterator as its argument, and the buffer of that window must > be temporarily made to be the current buffer. So this cannot be the problem > in this case. If init_iterator would be passed an incorrect window, we'd > have much more grave display problems than this minor issue. > Understood, but that's not what I was attempting to describe. I was trying to say that the window passed to init_interator IS the correct window. And that that is used to resolve the remap for the inactive/active faces. However, it does not appear that that same window is used to resolve remapping of faces that are inherited by the inactive/active faces. >From what I can tell, this only applies to header-line-active and header-line-inactive (and their mode line equivalents) and it does not apply to other faces in the header line that may inherit from remapped faces, so that's good. Also, I understand what you're saying that remapping mode-line was decided in Emacs 29 to not be supported and the conclusion may be the same for header-line. If that's what it needs to be, that's fine. As Eshel said, it will be a breaking change because people have relied on this behavior. Thanks, --0000000000002a1c030628880541 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Dec 04, 2024 at 11:51 PM, Eli Zaretski= i <eliz@gnu.org> wrote:<= br>

Once again, please show some simple Lisp to reproduce the phenomena you are observing. It is hard to discuss these highly technical issues on this abstract level.

=

Happy= to. Sorry, I didn't think it was necessary given Eshel's=C2=A0prov= iding of the recipe. It wasn't lisp though, so here's the lisp vers= ion from emacs -Q:

  1. (setq header-line-format "Some Header")
    <= /li>
  2. (face-remap-set-base 'header-line 'highlight)
    3. =
  3. (set-face-attribute 'default nil :height (+ (face-attribute 'defa= ult :height) 10))
  4. (switch-to-buffer-other-window "new= ")
  5. From within new buffer/window: (set-face-attribute 'default nil :height (+ (face-attribute '= default :height) 10))
You'll see after step 3 = the header line switches to the highlight face.
After step 5,= the header line in the original buffer switches away from the highlight fa= ce, which is unexpected.

If you then switch ba= ck to the original buffer and change the font size again, the highlight wil= l display again. Switching back to the new buffer and changing the font siz= e causes it to disappear again, so I was mistaken about it only happening o= nce. It just so happens that a full redisplay only triggers once for me in = my normal=C2=A0usage when I have a window without the header line override = specified.

<= div class=3D"">
=

On the very basic level of the display code, when a display it= erator is initialized, the window for whose display the iterator is used must be given to init_iterator as its argument, and the buffer of that window must be temporarily made to be the current buffer. So this cannot be the problem in this case. If init_iterator would be passed an incorrect window, we'd have much more grave display problems than this minor issue.

=

Understood, but that's not what I was at= tempting to describe. I was trying to say that the window passed to init_in= terator IS the correct window. And that that is used to resolve the remap f= or the inactive/active faces. However, it does not appear that that same wi= ndow is used to resolve remapping=C2=A0of faces that are inherited by the i= nactive/active faces.

From what I can tell, th= is only applies to header-line-active and header-line-inactive (and their m= ode line equivalents) and it does not apply to other faces in the header li= ne that may inherit from remapped faces, so that's good.
=
Also, I understand what you're saying that remapping mod= e-line was decided in Emacs 29 to not be supported and the conclusion may b= e the same for header-line. If that's what it needs to be, that's f= ine. As Eshel said, it will be a breaking change because people have relied= on this behavior.

Thanks,

--0000000000002a1c030628880541-- From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 05 15:45:24 2024 Received: (at 73862) by debbugs.gnu.org; 5 Dec 2024 20:45:24 +0000 Received: from localhost ([127.0.0.1]:41129 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tJIix-0002QO-Lw for submit@debbugs.gnu.org; Thu, 05 Dec 2024 15:45:24 -0500 Received: from eggs.gnu.org ([209.51.188.92]:50058) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tJIiu-0002Q6-CT for 73862@debbugs.gnu.org; Thu, 05 Dec 2024 15:45:22 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tJIgh-0006eU-SP; Thu, 05 Dec 2024 15:43:03 -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=ZYarllNL1BB6vvongb960gRMktkH2nJbkjDW9SlfoIs=; b=o/vWn4lcgXbV wZ0FaaUIBPBCYu498+HqRVCJrN02forIWC0G1R4a1uVOYnyAUVPeyYeEjUCkMoMbVdaFS0uDy6qCu BybKi+lB90EdqnzldK0+yP8AcAolUmzGTUdDfyqfjz2AGla49PUk1ygihNdk1n4rG1zfhpcwqa+/E EuIqJ9B3xZVcq9DOGCoXnDZec4/itdyhEr3A+yGlaC1NAAzuCpSpOStx8OBupSF7vNIxHurMi1aVi ptWAkWlItyj3YVtcOdS3j+tsZQASKp2f3yNNy22BZ+8yMTGrOKdEh+CCRwEM7vywsfWMEP0SePHsC 1MlOqKK6Nir75G2L0R3kUw==; Date: Thu, 05 Dec 2024 22:42:58 +0200 Message-Id: <8634j1n9nx.fsf@gnu.org> From: Eli Zaretskii To: Aaron Jensen In-Reply-To: (message from Aaron Jensen on Thu, 5 Dec 2024 08:02:06 -0800) Subject: Re: bug#73862: [PATCH] Add `header-line-active` and `header-line-inactive` faces. References: <86wmgfzhgc.fsf@gnu.org> <86zflay7hh.fsf@gnu.org> <86jzcey3cu.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 73862 Cc: trevor.m.murphy@gmail.com, me@eshelyaron.com, 73862@debbugs.gnu.org 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: Aaron Jensen > Date: Thu, 5 Dec 2024 08:02:06 -0800 > Cc: trevor.m.murphy@gmail.com, me@eshelyaron.com, 73862@debbugs.gnu.org > > On Wed, Dec 04, 2024 at 11:51 PM, Eli Zaretskii wrote: > > > Once again, please show some simple Lisp to reproduce the phenomena you > > are observing. It is hard to discuss these highly technical issues on this > > abstract level. > > > > Happy to. Sorry, I didn't think it was necessary given Eshel's providing of > the recipe. I asked a recipe from you because you seemed to be reporting something different: the happening once" part. > 1. (setq header-line-format "Some Header") > 2. (face-remap-set-base 'header-line 'highlight) > 3. (set-face-attribute 'default nil :height (+ (face-attribute 'default > :height) 10)) > 4. (switch-to-buffer-other-window "new") > 5. From within new buffer/window: (set-face-attribute 'default nil > :height (+ (face-attribute 'default :height) 10)) > > You'll see after step 3 the header line switches to the highlight face. > After step 5, the header line in the original buffer switches away from the > highlight face, which is unexpected. Why are you changing the attributes of the default face in step 3 and step 5 when what you want is to change the header-line face? And do you understand why step 2 didn't change the way header line is displayed, but step 3 did? > If you then switch back to the original buffer and change the font size > again, the highlight will display again. How come the font of the default face affects the colors of the header-line faces? Doesn't that already look strange? > Switching back to the new buffer and changing the font size causes > it to disappear again, so I was mistaken about it only happening > once. OK, so that mystery doesn't exist. Good. > > On the very basic level of the display code, when a display iterator is > > initialized, the window for whose display the iterator is used must be > > given to init_iterator as its argument, and the buffer of that window must > > be temporarily made to be the current buffer. So this cannot be the problem > > in this case. If init_iterator would be passed an incorrect window, we'd > > have much more grave display problems than this minor issue. > > > > Understood, but that's not what I was attempting to describe. I was trying > to say that the window passed to init_interator IS the correct window. And > that that is used to resolve the remap for the inactive/active faces. > However, it does not appear that that same window is used to resolve > remapping of faces that are inherited by the inactive/active faces. Face remapping is local to buffers, not to windows. So which window is passed to init_interator is not relevant to face remapping; the buffer of that window is. > From what I can tell, this only applies to header-line-active and > header-line-inactive (and their mode line equivalents) and it does not > apply to other faces in the header line that may inherit from remapped > faces, so that's good. > > Also, I understand what you're saying that remapping mode-line was decided > in Emacs 29 to not be supported and the conclusion may be the same for > header-line. If that's what it needs to be, that's fine. As Eshel said, it > will be a breaking change because people have relied on this behavior. I think there's no way to support what you expect cleanly. The reason is simple: inheritance in so-called "basic faces" is not taken into account when face-remapping is considered for them. Face inheritance is considered when faces are merged, but basic faces are not merged when they are used by the display engine for the respective parts of the Emacs display (i.e., the header-line faces for the header line, as opposed to just using the header-line faces for buffer text). That changing the attributes of the default faces has the effect of propagating the inheritance through face-remapping is an accident, the side effect of the particular implementation of when we recompute all the basic faces anew. It could be considered a bug on its own. We could perhaps add special-purpose code that would consider face inheritance for mode-line and header-line faces when remapping them, but that would get is in a different mess: . mode-line-inactive inherits from mode-line only by default, on color displays it doesn't; so if you remap mode-line, mode-line-inactive will only be affected on monochrome displays . header-line also inherits from mode-line, albeit only by default, so remapping mode-line would _sometimes_ affect header-line (and also header-line-active and header-line-inactive) and sometimes not . if the user customizes some of the mode-line or header-line faces to not inherit or to always inherit, remapping mode-line or header-line will produce different results for different faces So basically it's a royal mess, all of it caused by the fact that people somehow expect that remapping the header-line face will affect header-line-active and header-line-inactive, and similarly for mode-line. That was never supported for basic faces, and I think it makes little sense to support it in the future, because the results will certainly surprise someone. So I tend to close this bug as wontfix, and just mention in the documentation (NEWS at least) that people who remap header-line or mode-line need now to remap the new -active and -inactive faces. From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 05 16:15:43 2024 Received: (at 73862) by debbugs.gnu.org; 5 Dec 2024 21:15:43 +0000 Received: from localhost ([127.0.0.1]:41191 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tJJCI-0003t5-C2 for submit@debbugs.gnu.org; Thu, 05 Dec 2024 16:15:43 -0500 Received: from mail-lf1-f44.google.com ([209.85.167.44]:45343) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tJJCE-0003sl-S8 for 73862@debbugs.gnu.org; Thu, 05 Dec 2024 16:15:40 -0500 Received: by mail-lf1-f44.google.com with SMTP id 2adb3069b0e04-53e1f673ca8so1559747e87.3 for <73862@debbugs.gnu.org>; Thu, 05 Dec 2024 13:15:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1733433273; x=1734038073; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=5PIMDJPHOLUmQ0zWMxLghhMUoxO4V26RRbjDe94+vLc=; b=O5yBvjn0noitLz1Gc6cDEH37+a61snx/zwYWswR16BSkxKjyBX3dM09pIx2lcbUvM4 ulIE00LU01dcsMsRZG8jO6dQKtZnHNkl3tQxEaLxbUNQmKhV/D79pOde832YDxHZze2K 5Q2ktBuAfN2NY02P2/nWmfV5wcYMUO15u0gKg0P28GO16rXbFZWcES9djewi/MlF2QtY 7UVUYlMqvcrk3UH1ZigjTZK/bFZcjHH2pmMucb7lELuRLB25s1E49gQoW7qQJayIiNqt 3H/sTQrsG28jxNI7XzWo1ipfr6ZlhxTtVOmbz6QMazE6cL9q2CKa1Fa0aS6sgrScrq41 HtWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733433273; x=1734038073; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=5PIMDJPHOLUmQ0zWMxLghhMUoxO4V26RRbjDe94+vLc=; b=dvUkff7DIc9KHI1NlIXlkTzgY8d3wZ4hGp6tWZG9iIhThbgXlexUUen/RWZ2R+/xPU 9oUO2c7ptzuvEuJwto0UfiuBVuxrchv8XE0WBseu04zDipCFotr6Erwa2FXc9JAPUp4n f7jfP6om2Z8ZgN8fay5QwVaJCZ21mNyy1gJzw8XD969oXrHc6WgZfzYCVlY0eN6ShLJI ZL3+wZve1eOxnxuX3nFguB4IYOXhNuf7U4wDDtKyGBH1tnShjgb43725jOf6ZCHp4P9e LmtSVi2fK98hfTfbyG6K4ENsRBK4m7NQZSTMSekMBIdTa/aOlRPv15wpaqdenZYEQMtK GrbA== X-Forwarded-Encrypted: i=1; AJvYcCXdNBObBzOhKL7jSFTjyRo5f9MduOG+CCWFhy7OWctaPaqqjrdxzUOsJj5p9aKww59i43vpsA==@debbugs.gnu.org X-Gm-Message-State: AOJu0Ywtl9ZLNnwwTHLUnghZ63PstYwdeCoxty25aDxezUzpFBSSRx+G uOLGN1mBvUvn8TlNxogGO+Wctrxon1oOWzk1GWdweal5pTYbRBBZyv0/Oc8O6pCtHQu4U56JKRe IkPhPBdnL9H3SPLz9m4d8cXzruZM= X-Gm-Gg: ASbGncsFW9wzebx9xN17s7PMGwVSxAey3TLNk4RupiGTugZ4IB9piZr4yrBgOlU3Ivf AjmkHrOdAc1/rVIPEMmvhytSzhuaEq+pyGfmC/QIxPByA8xiDv8lB0j4= X-Google-Smtp-Source: AGHT+IGCO5x0Fi6Zxh4bTYk9xIL2sVpcsMBDMbh6xX3QJ46r3QeL7euVxezqWlRDWc3Cn5BqzxkxtplXZnLlszftLyY= X-Received: by 2002:a05:6512:2316:b0:53d:dd02:7cc5 with SMTP id 2adb3069b0e04-53e2c2b12b9mr117204e87.7.1733433272681; Thu, 05 Dec 2024 13:14:32 -0800 (PST) Received: from 649336022844 named unknown by gmailapi.google.com with HTTPREST; Thu, 5 Dec 2024 13:14:32 -0800 Mime-Version: 1.0 X-Mailer: Superhuman Desktop (2024-12-02T20:06:08Z) X-Superhuman-Draft-ID: draft006cbc1e2fd7c16a In-Reply-To: <8634j1n9nx.fsf@gnu.org> References: <86wmgfzhgc.fsf@gnu.org> <86zflay7hh.fsf@gnu.org> <86jzcey3cu.fsf@gnu.org> <8634j1n9nx.fsf@gnu.org> X-Superhuman-ID: m4bteggn.f03491e8-24c7-47c8-b0e6-70086f97449c From: Aaron Jensen Date: Thu, 5 Dec 2024 13:14:32 -0800 Message-ID: Subject: Re: bug#73862: [PATCH] Add `header-line-active` and `header-line-inactive` faces. To: Eli Zaretskii Content-Type: multipart/alternative; boundary="00000000000075d11a06288c62cb" X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 73862 Cc: trevor.m.murphy@gmail.com, me@eshelyaron.com, 73862@debbugs.gnu.org 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.0 (-) --00000000000075d11a06288c62cb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Dec 05, 2024 at 12:42 PM, Eli Zaretskii wrote: > From: Aaron Jensen > Date: Thu, 5 Dec 2024 08:02:06 -0800 > Cc: trevor.m.murphy@gmail.com, me@eshelyaron.com, 73862@debbugs.gnu.org > > On Wed, Dec 04, 2024 at 11:51 PM, Eli Zaretskii wrote: > > Once again, please show some simple Lisp to reproduce the phenomena you > are observing. It is hard to discuss these highly technical issues on thi= s > abstract level. > > Happy to. Sorry, I didn't think it was necessary given Eshel's providing > of the recipe. > > I asked a recipe from you because you seemed to be reporting something > different: the happening once" part. > > 1. (setq header-line-format "Some Header") > 2. (face-remap-set-base 'header-line 'highlight) > 3. (set-face-attribute 'default nil :height (+ (face-attribute 'default > :height) 10)) > 4. (switch-to-buffer-other-window "new") > 5. From within new buffer/window: (set-face-attribute 'default nil > :height (+ (face-attribute 'default :height) 10)) > > You'll see after step 3 the header line switches to the highlight face. > After step 5, the header line in the original buffer switches away from t= he > highlight face, which is unexpected. > > Why are you changing the attributes of the default face in step 3 and ste= p > 5 when what you want is to change the header-line face? And do you > understand why step 2 didn't change the way header line is displayed, but > step 3 did? > Only to force a redisplay in a way that actually causes the inheritance to be considered. Note that when you reproduce this same thing with the mode-line, force-mode-line-update doesn't work to cause the inheritance to be considered. There's something "special" about changing the font or the geometry of the frame or something that's causing the consideration of inheritance. > If you then switch back to the original buffer and change the font size > again, the highlight will display again. > > How come the font of the default face affects the colors of the > header-line faces? Doesn't that already look strange? > The strange thing is that when and how the inheritance is taken into account is not the same as for other faces. So yes, it already looks strange =E2=80=94 I shouldn't need to force a redisplay. Affecting the font= of the default face is just one means by which I can trigger the redisplay in a way that causes the issue. The specifics of it are a red herring. When I first noticed the issue it was as a result of a vterm popup window being shown. No default font modifications were made. I don't know what the specific trigger was, however. > Switching back to the new buffer and changing the font size causes it to > disappear again, so I was mistaken about it only happening once. > > OK, so that mystery doesn't exist. Good. > > On the very basic level of the display code, when a display iterator is > initialized, the window for whose display the iterator is used must be > given to init_iterator as its argument, and the buffer of that window mus= t > be temporarily made to be the current buffer. So this cannot be the probl= em > in this case. If init_iterator would be passed an incorrect window, we'd > have much more grave display problems than this minor issue. > > Understood, but that's not what I was attempting to describe. I was tryin= g > to say that the window passed to init_interator IS the correct window. An= d > that that is used to resolve the remap for the inactive/active faces. > However, it does not appear that that same window is used to resolve > remapping of faces that are inherited by the inactive/active faces. > > Face remapping is local to buffers, not to windows. So which window is > passed to init_interator is not relevant to face remapping; the buffer of > that window is. > My mistake. Even so, the buffer isn't being taken into account consistently, but you speak to that below. > From what I can tell, this only applies to header-line-active and > header-line-inactive (and their mode line equivalents) and it does not > apply to other faces in the header line that may inherit from remapped > faces, so that's good. > > Also, I understand what you're saying that remapping mode-line was decide= d > in Emacs 29 to not be supported and the conclusion may be the same for > header-line. If that's what it needs to be, that's fine. As Eshel said, i= t > will be a breaking change because people have relied on this behavior. > > I think there's no way to support what you expect cleanly. The reason is > simple: inheritance in so-called "basic faces" is not taken into account > when face-remapping is considered for them. Face inheritance is considere= d > when faces are merged, but basic faces are not merged when they are used = by > the display engine for the respective parts of the Emacs display (i.e., t= he > header-line faces for the header line, as opposed to just using the > header-line faces for buffer text). That changing the attributes of the > default faces has the effect of propagating the inheritance through > face-remapping is an accident, the side effect of the particular > implementation of when we recompute all the basic faces anew. It could be > considered a bug on its own. > > We could perhaps add special-purpose code that would consider face > inheritance for mode-line and header-line faces when remapping them, but > that would get is in a different mess: > > . mode-line-inactive inherits from mode-line only by default, on color > displays it doesn't; so if you remap mode-line, mode-line-inactive will > only be affected on monochrome displays > . header-line also inherits from mode-line, albeit only by default, so > remapping mode-line would _sometimes_ affect header-line (and also > header-line-active and header-line-inactive) and sometimes not > . if the user customizes some of the mode-line or header-line faces to no= t > inherit or to always inherit, remapping mode-line or header-line will > produce different results for different faces > > So basically it's a royal mess, all of it caused by the fact that people > somehow expect that remapping the header-line face will affect > header-line-active and header-line-inactive, and similarly for mode-line. > That was never supported for basic faces, and I think it makes little sen= se > to support it in the future, because the results will certainly surprise > someone. > > So I tend to close this bug as wontfix, and just mention in the > documentation (NEWS at least) that people who remap header-line or > mode-line need now to remap the new -active and -inactive faces. > Ok, I get what you're saying here, but I don't know that I agree with this: "...people somehow expect that remapping the header-line face will affect header-line-active and header-line-inactive." I'm not sure why it wouldn't be expected. It's reasonable to expect that inherit and face remapping would work the same way always. I didn't even know there was a notion of "basic faces" and what that meant. If that's somehow a special designation that confers different behavior, then we shouldn't be surprised if people are confused by its differences. I do not have these differences memorized, and ultimately that's what it sounds like we are being asked to do. Yes, you can remap faces, yes, you can inherit faces, and yes those two work together EXCEPT in this one case. Even with documentation, this will be confusing because we cannot rely on people finding that documentation. If basic faces do not fully support inheritance, we probably shouldn't allow them to have inheritance. That would mean that header-line-inactive would be defined explicitly, without inheritance, and if someone attempted to add an inherit property, it would fail. This would mean that the base faces, header-line and mode-line would be eliminated. Is it too much to ask for someone to explicitly configure the four faces (mode-line-active, mode-line-inactive, header-line-active, and header-line-inactive) any time they want to apply a theme to them? It sounds like that's the expectation for remapping, so why not extend that to customizing them? If there were no header-line or mode-line face then I would not have run into this. I would have been required to update my theme accordingly and the code that I use to remap header line faces, but that would have been apparent and seems like a reasonable change to make in a major version, but I can't recommend any of this because I don't know enough about the version criteria, release process, internals, etc, so please consider this just a perspective. Thanks, --00000000000075d11a06288c62cb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Dec 05, 2024 at 12:42 PM, Eli Zaretski= i <eliz@gnu.org> wrote:<= br>

From: Aaron Jensen <aaronjensen@gmail.c= om>
Date: Thu, 5 Dec 202= 4 08:02:06 -0800
Cc: trevor.m.murphy@gmail.co= m, me@eshelyaron.com, 73862@debbugs.gnu.org

On Wed, Dec 04, 2024 at 11:51 PM, Eli Zaretskii <eliz@gnu.org> wrote:

Once again, please show some simple Lisp to reproduce the phenomena you are observing. It is hard to discuss these highly technical issues on this abstract level.

Happy to. Sorry, I didn't think it was necessary given Eshel's prov= iding of the recipe.

I asked a recipe from you because you seemed to be reporting something different: the happening once" part.

1. (setq header-line-format "Some Header")
2. (face-remap-set-base 'header-line 'highlight)
3. (set-face-attribute 'default nil :height (+ (face-attribute 'def= ault
:height) 10))
4. (switch-to-buffer-other-window "new")
5. From within new buffer/window: (set-face-attribute 'default nil
:height (+ (face-attribute 'default :height) 10))

You'll see after step 3 the header line switches to the highlight face. After step 5, the header line in the original buffer switches away from the highlight face, which is unexpected.

Why are you changing the attributes of the default face in step 3 and step 5 when what you want is to change the header-line face? And do you understand why step 2 didn't change the way header line is displayed, but step 3 did?


Only to f= orce a redisplay in a way that actually causes the inheritance to be consid= ered. Note that when you reproduce this same thing with the mode-line, forc= e-mode-line-update doesn't work to cause=C2=A0the inheritance to be con= sidered. There's something "special" about changing the font = or the geometry of the frame or something that's causing the considerat= ion of inheritance.

<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">


If you then switch back to the original buffer and change the font size again, the highlight will display again.

How come the font of the default face affects the colors of the header-line faces? Doesn't that already look strange?

The strange thing is that when and how the inheritan= ce is taken into account is not the same as for other faces. So yes, it alr= eady looks strange =E2=80=94 I shouldn't need to force a redisplay. Aff= ecting the font of the default face is just one means by which I can trigge= r the redisplay in a way that causes the issue. The specifics of it are a r= ed herring. When I first noticed the issue it was as a result of a vterm po= pup window being shown. No default font modifications were made. I don'= t know what the specific trigger was, however.


Switching back to the new buffer and changing the font size causes it to disappear again, so I was mistaken about it only happening once.

OK, so that mystery doesn't exist. Good.

On the very basic level of the display code, when a display iterator is initialized, the window for whose display the iterator is used must be given to init_iterator as its argument, and the buffer of that window must be temporarily made to be the current buffer. So this cannot be the problem in this case. If init_iterator would be passed an incorrect window, we'= d have much more grave display problems than this minor issue.

Understood, but that's not what I was attempting to describe. I was try= ing to say that the window passed to init_interator IS the correct window. And that that is used to resolve the remap for the inactive/active faces. However, it does not appear that that same window is used to resolve remapping of faces that are inherited by the inactive/active faces.

Face remapping is local to buffers, not to windows. So which window is passed to init_interator is not relevant to face remapping; the buffer of that window is.


My mistake= . Even so, the buffer isn't being taken into account consistently, but = you speak to that below.


>From what I can tell, this only applies to header-line-active and header-line-inactive (and their mode line equivalents) and it does not apply to other faces in the header line that may inherit from remapped faces, so that's good.

Also, I understand what you're saying that remapping mode-line was deci= ded in Emacs 29 to not be supported and the conclusion may be the same for header-line. If that's what it needs to be, that's fine. As Eshel s= aid, it will be a breaking change because people have relied on this behavior.

I think there's no way to support what you expect cleanly. The reason is simple: inheritance in so-called "basic faces" is not taken in= to account when face-remapping is considered for them. Face inheritance is considered when faces are merged, but basic faces are not merged when they are used by the display engine for the respective parts of the Emacs display (i.e., the header-line faces for the header line, as opposed to just using the header-line faces for buffer text). That changing the attributes of the default faces has the effect of propagating the inheritance through face-remapping is an accident, the side effect of the particular implementation of when we recompute all the basic faces anew. It could be considered a bug on its own.

We could perhaps add special-purpose code that would consider face inheritance for mode-line and header-line faces when remapping them, but that would get is in a different mess:

. mode-line-inactive inherits from mode-line only by default, on color displays it doesn't; so if you remap mode-line, mode-line-inactive will only be affected on monochrome displays
. header-line also inherits from mode-line, albeit only by default, so remapping mode-line would _sometimes_ affect header-line (and also header-line-active and header-line-inactive) and sometimes not
. if the user customizes some of the mode-line or header-line faces to not inherit or to always inherit, remapping mode-line or header-line will produce different results for different faces

So basically it's a royal mess, all of it caused by the fact that people somehow expect that remapping the header-line face will affect header-line-active and header-line-inactive, and similarly for mode-line. That was never supported for basic faces, and I think it makes little sense to support it in the future, because the results will certainly surprise someone.

So I tend to close this bug as wontfix, and just mention in the documentation (NEWS at least) that people who remap header-line or mode-line need now to remap the new -active and -inactive faces.


Ok, I get what you're saying here, but I don't know th= at I agree with this: "...people somehow expect that remapping the hea= der-line face will affect header-line-active and header-line-inactive." I'm not sure why it = wouldn't be expected. It's reasonable to expect that inherit and fa= ce remapping would work the same way always. I didn't even know there w= as a notion of "basic faces" and what that meant. If that's s= omehow a special designation that confers different behavior, then we shoul= dn't be surprised if people are confused by its differences. I do not h= ave these differences=C2=A0memorized, and ultimately that's what it sou= nds like we are being asked to do. Yes, you can remap faces, yes, you can i= nherit faces, and yes those two work together EXCEPT in this one case. Even= with documentation, this will be confusing because we cannot rely on peopl= e finding that documentation.

If basic faces do not fully support inheritance, we probably shouldn&= #39;t allow them to have inheritance. That would mean that header-line-inac= tive would be defined explicitly, without inheritance, and if someone attem= pted to add an inherit property, it would fail.
<= br>
This would mean that the base faces, header-line a= nd mode-line would be eliminated. Is it too much to ask for someone to expl= icitly=C2=A0configure the four faces (mode-line-active, mode-line-inactive,= header-line-active, and header-line-inactive) any time they want to apply = a theme to them? It sounds like that's the expectation for remapping, s= o why not extend that to customizing them?

If there were no header-line or mode-line face then I wo= uld not have run into this. I would have been required=C2=A0to update my th= eme accordingly and the code that I use to remap header line faces, but tha= t would have been apparent and seems like a reasonable change to make in a = major version, but I can't recommend any of this because I don't kn= ow enough about the version criteria, release process, internals, etc, so p= lease consider this just a perspective.

=
Thanks,
--00000000000075d11a06288c62cb-- From debbugs-submit-bounces@debbugs.gnu.org Fri Dec 06 03:55:38 2024 Received: (at 73862) by debbugs.gnu.org; 6 Dec 2024 08:55:38 +0000 Received: from localhost ([127.0.0.1]:41999 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tJU7d-0004Tm-Ei for submit@debbugs.gnu.org; Fri, 06 Dec 2024 03:55:38 -0500 Received: from eggs.gnu.org ([209.51.188.92]:52766) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tJU7b-0004TT-7Z for 73862@debbugs.gnu.org; Fri, 06 Dec 2024 03:55:36 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tJU7T-000379-Eo; Fri, 06 Dec 2024 03:55:27 -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=i4L5Treff/yK8L29yjAyw87b9gQwKLcgCndEQ509em8=; b=ErLx6vxqoQ2VObqP1gVP VisGGQXXd1OHG+FpbBtrHanuBsVXcGCRQlPomkRSZ2Aszcl1uizIAKrYxf9bKQXMFmrVe/+sdMbVV J+H3kCGIgnA+CTF920bKVHSkqJsdIOUjlgs6IQeJ2Unz1aOavGTfFtu1vg/8VGUcePX6p1wficNmd qM+vr9qGuE37yfPU2WYCNwtlZgGtefOEUQsvwMpN9xkBw6PzhSx6UkFAPCS4tT6uLRPtephMJ54Gb mpLTNoh40i+bYDVONach5QNBzetwiGL+kjipT6mDTmEb8+af5CufEGYLZtewEKJiJCoC+SsHxibMx oDBwGvJ58ZUwug==; Date: Fri, 06 Dec 2024 10:55:22 +0200 Message-Id: <86jzcdkx6t.fsf@gnu.org> From: Eli Zaretskii To: Aaron Jensen , Stefan Monnier In-Reply-To: (message from Aaron Jensen on Thu, 5 Dec 2024 13:14:32 -0800) Subject: Re: bug#73862: [PATCH] Add `header-line-active` and `header-line-inactive` faces. References: <86wmgfzhgc.fsf@gnu.org> <86zflay7hh.fsf@gnu.org> <86jzcey3cu.fsf@gnu.org> <8634j1n9nx.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 73862 Cc: trevor.m.murphy@gmail.com, me@eshelyaron.com, 73862@debbugs.gnu.org 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: Aaron Jensen > Date: Thu, 5 Dec 2024 13:14:32 -0800 > Cc: trevor.m.murphy@gmail.com, me@eshelyaron.com, 73862@debbugs.gnu.org > > > Why are you changing the attributes of the default face in step 3 and step > > 5 when what you want is to change the header-line face? And do you > > understand why step 2 didn't change the way header line is displayed, but > > step 3 did? > > Only to force a redisplay in a way that actually causes the inheritance to > be considered. Note that when you reproduce this same thing with the > mode-line, force-mode-line-update doesn't work to cause the inheritance to > be considered. There's something "special" about changing the font or the > geometry of the frame or something that's causing the consideration of > inheritance. That's because changing the default face causes recomputation of all the faces, starting from the basic faces. It is not directly related to redisplay (which is why force-mode-line-update doesn't have that effect), although, of course, the recomputation is triggered by the next redisplay cycle. > > If you then switch back to the original buffer and change the font size > > again, the highlight will display again. > > > > How come the font of the default face affects the colors of the > > header-line faces? Doesn't that already look strange? > > The strange thing is that when and how the inheritance is taken into > account is not the same as for other faces. So yes, it already looks > strange — I shouldn't need to force a redisplay. Affecting the font of the > default face is just one means by which I can trigger the redisplay in a > way that causes the issue. The specifics of it are a red herring. When I > first noticed the issue it was as a result of a vterm popup window being > shown. No default font modifications were made. I don't know what the > specific trigger was, however. See above: I hope the situation is more clear now. > > So I tend to close this bug as wontfix, and just mention in the > > documentation (NEWS at least) that people who remap header-line or > > mode-line need now to remap the new -active and -inactive faces. > > Ok, I get what you're saying here, but I don't know that I agree with this: > "...people somehow expect that remapping the header-line face will affect > header-line-active and header-line-inactive." I'm not sure why it wouldn't > be expected. It shouldn't be expected for basic faces. > It's reasonable to expect that inherit and face remapping > would work the same way always. It doesn't, and never was. The current implementation of faces has a built-in assumption that basic faces don't inherit from any other faces, except the (implicit) inheritance from the default face. So face-remapping of basic faces doesn't take inheritance into account, and never did. > I didn't even know there was a notion of "basic faces" and what that > meant. As a Lisp programmer, you aren't supposed to know that, or care. The problem here is that, by making some basic faces inherit from other faces, we caused this abstraction to leak. > If basic faces do not fully support inheritance, we probably shouldn't > allow them to have inheritance. Yes. But that train has left the station, unfortunately, and quite a long time ago. I don't think there's a way back. Note that mode-line-inactive was originally introduced _in_addition_ to mode-line (which was then used only for the "active" mode-line), so people were expected to customize/remap that new face _in_addition_ to mode-line. It's when we introduced mode-line-active, which _always_ inherits from mode-line, that this problem was first introduced. And now the two header-line faces, which basically repeat the same paradigm, added yet another group of problems. > That would mean that header-line-inactive > would be defined explicitly, without inheritance, and if someone attempted > to add an inherit property, it would fail. Or we could do what the mode-line case did originally: leave the active face to be header-line and define header-line-inactive without inheritance. This will at least let existing remapping of header-line work as it did before. For the same reasons, I would prefer to go back on the mode-line-active change, but I'm not sure this is practical at this point. > This would mean that the base faces, header-line and mode-line would be > eliminated. No need to go that far. These faces are still useful, because they allow to define the inheriting faces more compactly, and allow to change the definitions easier. Inheritance still works on the defface level, even for basic faces. > Is it too much to ask for someone to explicitly configure the > four faces (mode-line-active, mode-line-inactive, header-line-active, and > header-line-inactive) any time they want to apply a theme to them? It > sounds like that's the expectation for remapping, so why not extend that to > customizing them? Remapping and customizing are two different customizations, though. They don't have to work the same. > If there were no header-line or mode-line face then I would not have run > into this. Yes, but removing a face from Emacs is a much more significant backward incompatibility than the problems discussed in this bug. I added Stefan to this discussion, in the hope that he could have some suggestions or comments. From debbugs-submit-bounces@debbugs.gnu.org Fri Dec 06 09:54:30 2024 Received: (at 73862) by debbugs.gnu.org; 6 Dec 2024 14:54:30 +0000 Received: from localhost ([127.0.0.1]:42483 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tJZiw-00055s-4a for submit@debbugs.gnu.org; Fri, 06 Dec 2024 09:54:30 -0500 Received: from mail-lj1-f178.google.com ([209.85.208.178]:42407) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tJZis-00055Z-Ju for 73862@debbugs.gnu.org; Fri, 06 Dec 2024 09:54:27 -0500 Received: by mail-lj1-f178.google.com with SMTP id 38308e7fff4ca-30024c73101so17633991fa.1 for <73862@debbugs.gnu.org>; Fri, 06 Dec 2024 06:54:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1733496801; x=1734101601; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:in-reply-to:from:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=AlZ4zEFoD17Mxpu2/xFvTJmnSErR2HI/8+KQhB6cPAc=; b=dDhTFk33BJaMKNebxw2k2L23HUEA3oepdVXwskwc9RDTZ0PdgGofOYRV9CT/GxrjHg vkj7uSOZLOZeCoHf6M70aGdAuzyIiL8B8ChwvqlXxDsYfoFaT9NNvClmZlwmO9FiO2gN x2oA20o1hZGJIxr9KP81a+soaIswoAuCgqVH6BdsawIYQTHa2zOjccJzSdsaAUYr2vrp 55Qk/jvmaBonbT4U9lr6ogp9v9lYZUWydBm13g/LhquSOpESj1MZIEOIh/Lfd57iHGAW zmqT9VQk4Fboff5UgEZKSloFD1WyvL1ch9rbBpbC0disbQMjbuT+Um/BCTKkqBDz1F8c neDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733496801; x=1734101601; h=cc:to:subject:message-id:date:in-reply-to:from:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=AlZ4zEFoD17Mxpu2/xFvTJmnSErR2HI/8+KQhB6cPAc=; b=p6AsrBdzFNilXr4gWKuby2S/OMH3P5rzPfHslpp0fMHP0rdjLHitNguz+v0kPv+fJN Ruz1cCfj0r5CTc8TEXuiJo8LaOzsP+P8FxX7fq1w/pl10mcr7aMf2PS3OMNAjyp8Pt2r cQcBBn7tgScen6cL/173K8hwAuEMOIQiTmjmPlfCHVT0h/IwYrbPmEzqjwgSD6HEX98o EhrbW4rMxzhrYgeAZCnoVVbxsqhkQElKvRvmDRnKJsJJ3aP9ZWOLckOAjr0B41bxIKYx WXTCuU88CqScV5sHb3saOXCmuQ9jEVPuanQHtsnpxhS+bjZDOOK0+lmuSYWejFIUv1go oROg== X-Forwarded-Encrypted: i=1; AJvYcCVRU2TOK9Qj8XPVkXuG14lO1hDgvq5TlVQGw53rZO9YOY3ghJrZXEZz/m6vAAzLWLNkLZtB7A==@debbugs.gnu.org X-Gm-Message-State: AOJu0YwnHZwUCiO5jzriVChNnsYiqwU9/RRfdPH8LI7qvml2cxR4yMlE gWSz4MamEDPrkFOqIKDe+hfop+xhNqSaFtvBy7HTpkKHkya/Bv3i6hpW3qbkp4Mnob6BHDkAfv5 fEUqmNCKy9rZa37iKBzQjbl/iSNg= X-Gm-Gg: ASbGnct1TLZFgrThzK0i8KAHnbLLgsKZaRTu5J+nlkvdOFn7jC8xDvmzm4O2wp49POq 28by2u67lD/FWlC5YjWJEl1M/fn39Hk0LLiNExj3snNqCF/puH0ifcqI= X-Google-Smtp-Source: AGHT+IF6Q31/WaVsjYudnF53/d+JApFgJGZnHoiad5NTPtu206kar3ULC8adrpOuXm1okuaGiedXt3/HRdlW3jCcUpQ= X-Received: by 2002:a2e:be23:0:b0:2ff:b3f0:68d9 with SMTP id 38308e7fff4ca-3001ea9934bmr29057331fa.3.1733496800307; Fri, 06 Dec 2024 06:53:20 -0800 (PST) Received: from 649336022844 named unknown by gmailapi.google.com with HTTPREST; Fri, 6 Dec 2024 06:53:19 -0800 Mime-Version: 1.0 X-Mailer: Superhuman Desktop (2024-12-02T20:06:08Z) References: <86wmgfzhgc.fsf@gnu.org> <86zflay7hh.fsf@gnu.org> <86jzcey3cu.fsf@gnu.org> <8634j1n9nx.fsf@gnu.org> <86jzcdkx6t.fsf@gnu.org> From: Aaron Jensen X-Superhuman-ID: m4cv833p.58fe6f03-dccd-421b-b42d-cfc57b54c332 X-Superhuman-Draft-ID: draft009be574a1d2170b In-Reply-To: <86jzcdkx6t.fsf@gnu.org> Date: Fri, 6 Dec 2024 06:53:19 -0800 Message-ID: Subject: Re: bug#73862: [PATCH] Add `header-line-active` and `header-line-inactive` faces. To: Eli Zaretskii Content-Type: multipart/alternative; boundary="00000000000000726806289b2dbf" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 73862 Cc: trevor.m.murphy@gmail.com, me@eshelyaron.com, Stefan Monnier , 73862@debbugs.gnu.org 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.0 (-) --00000000000000726806289b2dbf Content-Type: text/plain; charset="UTF-8" On Fri, Dec 06, 2024 at 12:55 AM, Eli Zaretskii wrote: > See above: I hope the situation is more clear now. > Yes, thank you. I still don't know all of the different things that trigger computation of faces, but I probably don't need to (and likely shouldn't need to). So I tend to close this bug as wontfix, and just mention in the > documentation (NEWS at least) that people who remap header-line or > mode-line need now to remap the new -active and -inactive faces. > > Ok, I get what you're saying here, but I don't know that I agree with > this: > "...people somehow expect that remapping the header-line face will affect > header-line-active and header-line-inactive." I'm not sure why it wouldn't > be expected. > > It shouldn't be expected for basic faces. > >From a purely human, cognitive load, and/or usability perspective, it should be expected. As designers of software we have to be careful not to let our detailed knowledge of things influence how we think other people who do not have that detailed knowledge will or should think about things. I was speaking purely from a "principle of least surprise" perspective. All I mean is that if there are 10 widgets, and 9 widgets work a certain way when you push a button on them, it is human and natural to expect the 10th to work that same way. It doesn't matter that the builder of the widget refers to it as a "basic widget", because the user of the widget has never come across that terminology, nor do they know what special variation it confers. It does sound like below you agree that the situation caused is undesirable, I'm trying to speak to why I believe it is. But yes, perhaps the train has left the station though. Or we could do what the mode-line case did originally: leave the active > face to be header-line and define header-line-inactive without inheritance. > This will at least let existing remapping of header-line work as it did > before. > > For the same reasons, I would prefer to go back on the mode-line-active > change, but I'm not sure this is practical at this point. > I'd personally be fine with this. It would be obvious when an inactive header line looked different than my header line I configured and I would have to look into it. I'm guessing there's no way to apply header-line-active and header-line-inactive to the actual formatted header line in the same way a user would with propertize so that it would behave like a non-basic face? I have no idea what that would entail, but I'm assuming there's a special reason for treating basic faces specially (perhaps it has to do with how init_iterator is initialized with it) This would mean that the base faces, header-line and mode-line would be > eliminated. > > No need to go that far. These faces are still useful, because they allow > to define the inheriting faces more compactly, and allow to change the > definitions easier. Inheritance still works on the defface level, even for > basic faces. > I think you're saying above you'd prefer nearly the same thing, but header-line would survive, rather than header-line-active, yes? The point is that inheritance only "kind of" works for basic faces (from a user's perspective), so no matter how we get rid of the default use of inheritance, I think it would be better for users. Thanks, --00000000000000726806289b2dbf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Dec 06, 2024 at 12:55 AM, Eli Zaretskii <eliz@gnu.org> wrote:
<= div class=3D"sh-quoted-content">
=

See above: I hope the situation is more clear now.


Yes, thank you. I = still don't know all of the different things that trigger computation= =C2=A0of faces, but I probably don't need to (and likely shouldn't = need to).

So I tend to close this bug as wontfix, and just mention in the documentation (NEWS at least) that people who remap header-line or mode-line need now to remap the new -active and -inactive faces.

Ok, I get what you're saying here, but I don't know that I agree wi= th this:
"...people somehow expect that remapping the header-line face will aff= ect header-line-active and header-line-inactive." I'm not sure why it = wouldn't be expected.

It shouldn't be expected for basic faces.


From a purely human, co= gnitive load, and/or usability perspective, it should be expected. As desig= ners of software we have to be careful not to let our detailed knowledge of= things influence how we think other people who do not have that detailed k= nowledge will or should think about things. I was speaking purely=C2=A0from= a "principle of least surprise" perspective. All I mean is that = if there are 10 widgets, and 9 widgets work a certain way when you push a b= utton on them, it is human and natural to expect the 10th to work that same= way. It doesn't matter that the builder of the widget refers to it as = a "basic widget", because the user of the widget has never come a= cross that terminology, nor do they know what special variation it confers.=

It does sound like below you agree=C2=A0that = the situation caused is undesirable, I'm trying to speak to why I belie= ve=C2=A0it is. But yes, perhaps=C2=A0the train has left the station though.=

Or we could do what the mode-line case did originally: leave the active face to be header-line and define header-line-inactive without inheritance. This will at least let existing remapping of header-line work as it did before.

For the same reasons, I would prefer to go back on the mode-line-active change, but I'm not sure this is practical at this point.

I'd personally be fine with this. It would be obvious when= an inactive header line looked different than my header line I configured = and I would have to look into it. I'm guessing there's no way to ap= ply header-line-active and header-line-inactive to the actual=C2=A0formatte= d header line in the same way a user would with propertize=C2=A0so that it = would behave like a non-basic face? I have no idea what that would=C2=A0ent= ail, but I'm assuming=C2=A0there's a special reason for treating ba= sic faces specially (perhaps it has to do with how init_iterator is initial= ized with=C2=A0it)

This would mean that the base faces, header-line and mode-line would be eliminated.

No need to go that far. These faces are still useful, because they allow to define the inheriting faces more compactly, and allow to change the definitions easier. Inheritance still works on the defface level, even for basic faces.


I think you're saying above you'= d prefer nearly the same thing, but header-line would survive, rather than = header-line-active, yes? The point is that inheritance only "kind of&q= uot; works for basic faces (from a user's perspective), so no matter ho= w we get rid of the default use of inheritance, I think it would be better = for users.

Thanks,

--00000000000000726806289b2dbf-- From debbugs-submit-bounces@debbugs.gnu.org Fri Dec 06 11:29:57 2024 Received: (at 73862) by debbugs.gnu.org; 6 Dec 2024 16:29:57 +0000 Received: from localhost ([127.0.0.1]:44026 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tJbDI-0001eN-Pq for submit@debbugs.gnu.org; Fri, 06 Dec 2024 11:29:57 -0500 Received: from mail-lj1-f172.google.com ([209.85.208.172]:51661) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tJbDH-0001eD-JH for 73862@debbugs.gnu.org; Fri, 06 Dec 2024 11:29:56 -0500 Received: by mail-lj1-f172.google.com with SMTP id 38308e7fff4ca-2ffa974b2b0so20390521fa.3 for <73862@debbugs.gnu.org>; Fri, 06 Dec 2024 08:29:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1733502534; x=1734107334; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=JxIuWCnL/8zHlgl9RdcAUQmKtmaJZG7y9NdUS1m3OB4=; b=ayQlcX/dkgWAREOe6cYko8MCe+pxQ8T7jbGt5Txw7ALh8YKvgZQ5kMn1mrlE6hG3V9 on8/okmvGwF33uWXE4bj+U31E+6uyFj98c+pW9cEWGcmqvrSU+QMZ82JTpEfoXe09XWi dbpNg5TN+7PcD4GEVHszOgQkeH9XkE8TDNEVXYiJAe1qdHwNeOwBpS6SmfG4sJTZkhIX 54NGNMoAbrDetYhlRUDIBW7qnxxiuhBrrP2ycdP8b+NXUuVXQ3Vwpn185EVtmFTVgx+v 1lWE9h1UVhJmvtZfyG4IRzQ4cLFc7/T1dbLfbBki/t7pZ5sTXo3BtfOVPSri8D3yxkKV NMaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733502534; x=1734107334; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=JxIuWCnL/8zHlgl9RdcAUQmKtmaJZG7y9NdUS1m3OB4=; b=Hl+lpVl5LiXin07YU8WatdVKjcgPb1QSyUhprWfYMNzRVtFugnLoPZeY2JMNSovA0s C31QbKNJ7Cf1SENiVGyL5M7AEVQg31+F/ykRjavCkdXzRficC7HYj62jFsdMNoZB16ol syTBGt2FoC/6Qz3k9ODreFFsABIFSF4yJJfO9z20KB0p2sTgQlBb5A0DcmBoUbChv/OB 5FQBjPMBDN9Gke0lqww4GUlDYRhQH/plpmZkAoSZk8pakh/v07iVMA/5AOYOOGXQlOG9 Im/L0V6p535Vm5m0L9FB/50aQKBqdvXF4qWvGbrDfBh0oFxnwKUSnOHUOJQH0ml2oqWl o05A== X-Forwarded-Encrypted: i=1; AJvYcCVQzyJVlOhEvPNHj1pVDsOvF0w7/1XrhetWFYuW2YY+HhgIE1dnkMbVTYTSC+t1yBd8AtBO7w==@debbugs.gnu.org X-Gm-Message-State: AOJu0YwZDnvQWVVJkWfZsaajIvFzTkRmkY4BuTA/2P8HRoOjJcECgF1a 5KTZRP1qJ1rZtcbOTjxi6o/BTuDFUtUialxl/OlEesOFQ0aYAvCD5RCwMhcpxCFk7sAtc4wp2Vx xSkIt416CctxGLo9nnSiMZNRdKbQ= X-Gm-Gg: ASbGnctYBjEGdhAkBkvE+G91pfyXte8pGZ6CuJOrrIhUkTz9O/NB0DAAEHXCqjT5Yce DqicGAziDGBkCC5Pj123aC1un1cksZ1E8mjp5AjhM6apWXoqZSkU1vi0= X-Google-Smtp-Source: AGHT+IHbf0/Sx6xUnEYBpyIZTe2AECdQDSHO3uwDL2m1S5QlvL0bF1kE3FcyJLAwhG9EH8hpxAr+Ztf+OgclLwijLjA= X-Received: by 2002:a05:651c:88b:b0:2fa:cdd1:4f16 with SMTP id 38308e7fff4ca-3002f8dfd90mr10252511fa.14.1733502534277; Fri, 06 Dec 2024 08:28:54 -0800 (PST) Received: from 649336022844 named unknown by gmailapi.google.com with HTTPREST; Fri, 6 Dec 2024 11:28:53 -0500 Mime-Version: 1.0 X-Superhuman-Draft-ID: draft00859545d2f468ec X-Mailer: Superhuman Desktop (2024-12-02T20:06:08Z) In-Reply-To: References: <86wmgfzhgc.fsf@gnu.org> <86zflay7hh.fsf@gnu.org> <86jzcey3cu.fsf@gnu.org> <8634j1n9nx.fsf@gnu.org> <86jzcdkx6t.fsf@gnu.org> From: Aaron Jensen X-Superhuman-ID: m4cymz25.5689b97c-c4d2-4fcf-a2b3-0a0b2a99b4ed Date: Fri, 6 Dec 2024 11:28:53 -0500 Message-ID: Subject: Re: bug#73862: [PATCH] Add `header-line-active` and `header-line-inactive` faces. To: Eli Zaretskii Content-Type: multipart/alternative; boundary="000000000000c5ebd906289c8250" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 73862 Cc: trevor.m.murphy@gmail.com, me@eshelyaron.com, Stefan Monnier , 73862@debbugs.gnu.org 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.0 (-) --000000000000c5ebd906289c8250 Content-Type: text/plain; charset="UTF-8" Would it be possible, aside from the remapping of the particular face being built (like header-line-active) to disable remapping when building the basic faces? It occurred to me that one way to see the problem is that there is inconsistency in how the remapping are applied (because they are per-buffer). If it were consistent that the remap was not applied to any face that the basic face inherited from, then the problem wouldn't appear to be as bad as it is. It would come across as a limitation, rather than something that seems like a defect. --000000000000c5ebd906289c8250 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Would it be possible, aside from the remapping of the= particular face being built (like header-line-active) to disable remapping= when building the basic faces? It occurred to me that one way to see the p= roblem is that there is inconsistency in how the remapping=C2=A0are applied= (because they are per-buffer). If it were consistent that the remap was no= t applied to any face that the basic face inherited from, then the problem = wouldn't appear to be as bad as it is. It would come across as a limita= tion, rather than something that seems like a defect.

--000000000000c5ebd906289c8250-- From debbugs-submit-bounces@debbugs.gnu.org Sat Dec 07 04:50:56 2024 Received: (at 73862) by debbugs.gnu.org; 7 Dec 2024 09:50:57 +0000 Received: from localhost ([127.0.0.1]:45425 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tJrSi-0002Wp-Eh for submit@debbugs.gnu.org; Sat, 07 Dec 2024 04:50:56 -0500 Received: from eggs.gnu.org ([209.51.188.92]:42734) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tJrSg-0002WZ-IO for 73862@debbugs.gnu.org; Sat, 07 Dec 2024 04:50:55 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tJrSa-0000Ig-AI; Sat, 07 Dec 2024 04:50: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=ozGEzLmI+h9NpiTAIhvfP5GucyykVEZkAxUdXEyh/s0=; b=EN6jGy6U9SJp hESMR7i1AAJr8L962Nq6lwzOqzXh7I3rjaEFvo1FcuN+bLVqd9tdA9RiyLpuiPs/Su/Tb5ZyTJPO4 3rBpCOFQ8kM1QyEtyrGDo0SSc7K83jb+jLID1htc1P3odLxM8s0OhgUAPwmCoba4fS5sfYXkJDjV2 XlPZFDb4WQe0GXtiVWHzjpfcEzG6Ea5bSCv7TzXOQ62RCScw5U+6b8BRmCDLVGrNE1sJaZpfg3AOY xV/zmrHlR918fjYqVnTW6ak322w32RbEaeBaTNzrB4hUrBXSejDjTbWdynPRAPT9KDUed5SFfXo9J rihzM/KyjRu737s8oK09/w==; Date: Sat, 07 Dec 2024 11:50:45 +0200 Message-Id: <86ldwrkeiy.fsf@gnu.org> From: Eli Zaretskii To: aaronjensen@gmail.com, Stefan Monnier In-Reply-To: <8634j1n9nx.fsf@gnu.org> (message from Eli Zaretskii on Thu, 05 Dec 2024 22:42:58 +0200) Subject: Re: bug#73862: [PATCH] Add `header-line-active` and `header-line-inactive` faces. References: <86wmgfzhgc.fsf@gnu.org> <86zflay7hh.fsf@gnu.org> <86jzcey3cu.fsf@gnu.org> <8634j1n9nx.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 73862 Cc: trevor.m.murphy@gmail.com, me@eshelyaron.com, 73862@debbugs.gnu.org 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 (---) > Cc: trevor.m.murphy@gmail.com, me@eshelyaron.com, 73862@debbugs.gnu.org > Date: Thu, 05 Dec 2024 22:42:58 +0200 > From: Eli Zaretskii > > We could perhaps add special-purpose code that would consider face > inheritance for mode-line and header-line faces when remapping them, > but that would get is in a different mess: > > . mode-line-inactive inherits from mode-line only by default, on > color displays it doesn't; so if you remap mode-line, > mode-line-inactive will only be affected on monochrome displays > . header-line also inherits from mode-line, albeit only by default, > so remapping mode-line would _sometimes_ affect header-line (and > also header-line-active and header-line-inactive) and sometimes not > . if the user customizes some of the mode-line or header-line faces > to not inherit or to always inherit, remapping mode-line or > header-line will produce different results for different faces > > So basically it's a royal mess, all of it caused by the fact that > people somehow expect that remapping the header-line face will affect > header-line-active and header-line-inactive, and similarly for > mode-line. That was never supported for basic faces, and I think it > makes little sense to support it in the future, because the results > will certainly surprise someone. > > So I tend to close this bug as wontfix, and just mention in the > documentation (NEWS at least) that people who remap header-line or > mode-line need now to remap the new -active and -inactive faces. If we do prefer to support remapping mode-line and header-line faces, then I can suggest the semi-kludgey "fix" below. Is this better than what we have now? Note that it immediately reveals the problems I mentioned above. For example, if you remap header-line, both header-line-active and header-line-inactive immediately follow suit, but if you remap mode-line, only mode-line-active follows, whereas mode-line-inactive only follows on TTY frames (because all other frames support :box). So if we install this, we should probably change the definition of mode-line-inactive in some way? Stefan, any suggestions or comments? diff --git a/src/xfaces.c b/src/xfaces.c index f626480..9704c05 100644 --- a/src/xfaces.c +++ b/src/xfaces.c @@ -5144,6 +5144,19 @@ lookup_basic_face (struct window *w, struct frame *f, int face_id) for the very common no-remapping case. */ mapping = assq_no_quit (name, Vface_remapping_alist); if (NILP (mapping)) + { + /* Special treatment for mode-line and header-line faces, for + backward compatibility: people might remap 'mode-line' and + 'header-line' faces and expect the *-active and *-inactive + faces to change accordingly. */ + if (face_id == MODE_LINE_ACTIVE_FACE_ID + || face_id == MODE_LINE_INACTIVE_FACE_ID) + mapping = assq_no_quit (Qmode_line, Vface_remapping_alist); + else if (face_id == HEADER_LINE_ACTIVE_FACE_ID + || face_id == HEADER_LINE_INACTIVE_FACE_ID) + mapping = assq_no_quit (Qheader_line, Vface_remapping_alist); + } + if (NILP (mapping)) return face_id; /* Give up. */ /* If there is a remapping entry, lookup the face using NAME, which will @@ -7447,6 +7460,7 @@ syms_of_xfaces (void) DEFSYM (Qcursor, "cursor"); DEFSYM (Qborder, "border"); DEFSYM (Qmouse, "mouse"); + /* Qmode_line is defined in keyboard.c */ DEFSYM (Qmode_line_inactive, "mode-line-inactive"); DEFSYM (Qmode_line_active, "mode-line-active"); DEFSYM (Qvertical_border, "vertical-border"); From debbugs-submit-bounces@debbugs.gnu.org Sat Dec 07 04:54:11 2024 Received: (at 73862) by debbugs.gnu.org; 7 Dec 2024 09:54:12 +0000 Received: from localhost ([127.0.0.1]:45435 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tJrVr-0002dJ-Ia for submit@debbugs.gnu.org; Sat, 07 Dec 2024 04:54:11 -0500 Received: from eggs.gnu.org ([209.51.188.92]:43782) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tJrVo-0002d1-RC for 73862@debbugs.gnu.org; Sat, 07 Dec 2024 04:54:09 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tJrVi-0000hM-VN; Sat, 07 Dec 2024 04:54:03 -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=IF0i9bTQ8UR56vF2oOb6Td1ji0BI9D/1/3jEPOme3Yw=; b=ZRqO6HfEaSJ9RICzRwJJ pTNZbJXTFqFGT9vg5IY6V+KLVGP8IhArNwxHS9A3Fnv9Qjb1TdLh1WMcf+2xV2MZ2pW5A31+Lx0e1 l3QmZ3cVCmj77eksWLwl7Z9wJlJYKhYz0GX6fWgCYiQqCEjxEbQcxC7ftpahWOu6GncIXgty4TFhs mxTN8Am1QhrH0dteLWVWdsnnv/G30jL9Lx7PzeVhV0D43b5IBFCon3gU8C8sXD9J5Q+rB5ItOokjL ruMDe1SPjqMrgMWAfQFjl/IpHFQKyQlpN7zUJLUvdAathRObAL7YjgvICm0f/Hf8PHhUJXYaxcF+h bfH/DFtpJCdd2A==; Date: Sat, 07 Dec 2024 11:54:00 +0200 Message-Id: <86jzcbkedj.fsf@gnu.org> From: Eli Zaretskii To: Aaron Jensen In-Reply-To: (message from Aaron Jensen on Fri, 6 Dec 2024 11:28:53 -0500) Subject: Re: bug#73862: [PATCH] Add `header-line-active` and `header-line-inactive` faces. References: <86wmgfzhgc.fsf@gnu.org> <86zflay7hh.fsf@gnu.org> <86jzcey3cu.fsf@gnu.org> <8634j1n9nx.fsf@gnu.org> <86jzcdkx6t.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 73862 Cc: trevor.m.murphy@gmail.com, me@eshelyaron.com, monnier@iro.umontreal.ca, 73862@debbugs.gnu.org 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: Aaron Jensen > Date: Fri, 6 Dec 2024 11:28:53 -0500 > Cc: Stefan Monnier , trevor.m.murphy@gmail.com, me@eshelyaron.com, > 73862@debbugs.gnu.org > > Would it be possible, aside from the remapping of the particular face being > built (like header-line-active) to disable remapping when building the > basic faces? It occurred to me that one way to see the problem is that > there is inconsistency in how the remapping are applied (because they are > per-buffer). If it were consistent that the remap was not applied to any > face that the basic face inherited from, then the problem wouldn't appear > to be as bad as it is. It would come across as a limitation, rather than > something that seems like a defect. If we are going to change the C code related to basic faces, I'd prefer the semi-kludgey change I sent a few minutes ago. It at least brings the effect closer to naïve user expectations. From debbugs-submit-bounces@debbugs.gnu.org Sat Dec 07 08:29:43 2024 Received: (at 73862) by debbugs.gnu.org; 7 Dec 2024 13:29:43 +0000 Received: from localhost ([127.0.0.1]:45965 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tJusQ-0005Eb-IU for submit@debbugs.gnu.org; Sat, 07 Dec 2024 08:29:43 -0500 Received: from mail-lj1-f179.google.com ([209.85.208.179]:50317) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tJusO-0005EM-CV for 73862@debbugs.gnu.org; Sat, 07 Dec 2024 08:29:41 -0500 Received: by mail-lj1-f179.google.com with SMTP id 38308e7fff4ca-3001d009633so25951411fa.0 for <73862@debbugs.gnu.org>; Sat, 07 Dec 2024 05:29:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1733578114; x=1734182914; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:references:from:in-reply-to :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=4+dG/RbKR1jAPgvdehDSnPEY+IkRm81YQgY+PzOgAfE=; b=T9w53EyIdzT8NL6V2lm541KWUhbtJlSDREvXsQWJ/Wy0qVt8TeNKLZsnsAb1dMHgIw s8YAlU/dYNb3oBeuZTdAyA66+zeWoCnPn930R/Wl/WrsGSXvfQOHflXl+dvpNWRfb7P+ vUad50xro3jqtAD7u93f/koU+OgMA0Qv5haMKd/YfVoh08HbHcJCwPLQ3sQRF1RxiSwB 0rhe5BsViBdmNEXzfrPW0yAAs72bams5C/loKPnf0Tt9/zkpf2VbH2Ln5eO/dXPZr7U9 /HxHeeexjzph2WM+qr8uD/wHvpvCglfrflE6DnutCZUk3mWUqf6eR5sVNnNTOPWxfiw2 IKoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733578114; x=1734182914; h=cc:to:subject:message-id:date:references:from:in-reply-to :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=4+dG/RbKR1jAPgvdehDSnPEY+IkRm81YQgY+PzOgAfE=; b=Vg9pdNcJfqfMXkDOKyvcKqp7MSauNYiJ030ujyzNPp8tGhr7pPsFs+aM7g2AKAFKfF Lm44YEsm5tsRTPNqyPuAPc3zSIw21PGNbUDQevRZ2akFFJzJO2uH/Ud2+l0sb1yCsSvw 08hF5cBHmS13METV6SZ83qTDiHeNAC+sGXXy9OVHde4GKQz/kcingAWQSJUHUpuTCDw5 LbpS6G1LOOW1ZosTfl3iVDki5whuoa0whKPCNiOCDugWi+T013ETKFu4VzdunbJsYmji LehEv+0tEOcXzH2t4PiUxnS+yww2B3dNZmjQrehntd0X9/UBiCx6C51sZ4OoZF3+KhYH cgtQ== X-Forwarded-Encrypted: i=1; AJvYcCXxU1h0eQguNw7Hfw+fSU5alihLhLqEMhfPSJzQ3ibO13mJj/5obGZzq4nboZDIPLVKTitMtw==@debbugs.gnu.org X-Gm-Message-State: AOJu0YxFR0FoJ2hH+B318VR4moKhmH/eP2gYwN46qiWz6R7ZR+eKAQ2s Pq61lO5p9nwV+uN950olnjCviynxnY2A9eJJ55MqmzQkOKr/FCDRoNgNYWSzbVgM8ITp7Pdlr+v qMJTtffao94zxCp7NHu6p+d6/Zeg= X-Gm-Gg: ASbGnctj34ylLmwpwnJCurLK12/NTlENobS8i2n99E2xwLbPd17h8ODoHUghLZrTgxu 5XIQj3LuJXV3OUylHJvSbxmGvPh1JOruOz6oMjVGeAWhUcxi0aUeb4F5K X-Google-Smtp-Source: AGHT+IEpqwyijPMbItte+q7dkbnHc53EGFNMO1y5gkaHIBorVv7mH2ztPnEVa9aFhhffKp9qV4u7+luttGFBKALgEmA= X-Received: by 2002:a2e:9a0e:0:b0:300:1d45:8705 with SMTP id 38308e7fff4ca-3002f8aa077mr21539011fa.1.1733578113996; Sat, 07 Dec 2024 05:28:33 -0800 (PST) Received: from 649336022844 named unknown by gmailapi.google.com with HTTPREST; Sat, 7 Dec 2024 07:28:33 -0600 Mime-Version: 1.0 X-Superhuman-Draft-ID: draft00c7da932ae014ff In-Reply-To: <86ldwrkeiy.fsf@gnu.org> From: Aaron Jensen X-Mailer: Superhuman Desktop (2024-12-02T20:06:08Z) X-Superhuman-ID: m4e7mwia.398bed27-545d-4704-a69a-3f07fbf82f3f References: <86wmgfzhgc.fsf@gnu.org> <86zflay7hh.fsf@gnu.org> <86jzcey3cu.fsf@gnu.org> <8634j1n9nx.fsf@gnu.org> <86ldwrkeiy.fsf@gnu.org> Date: Sat, 7 Dec 2024 07:28:33 -0600 Message-ID: Subject: Re: bug#73862: [PATCH] Add `header-line-active` and `header-line-inactive` faces. To: Eli Zaretskii Content-Type: multipart/alternative; boundary="000000000000ace10a0628ae1bde" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 73862 Cc: trevor.m.murphy@gmail.com, me@eshelyaron.com, Stefan Monnier , 73862@debbugs.gnu.org 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.0 (-) --000000000000ace10a0628ae1bde Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Dec 07, 2024 at 1:50 AM, Eli Zaretskii wrote: > If we do prefer to support remapping mode-line and header-line faces, the= n > I can suggest the semi-kludgey "fix" below. Is this better than what we > have now? > Does this patch make it so that remaps are considered for header-line even if header-line-active no longer inherits from header-line? If so, I'd consider that even more surprising. The more I think about this, the less inclined I'd be to play special case whack-a-mole with it and the more I'd be inclined to either "live with it" or figure out a way to disable remapping entirely in certain rendering contexts. Tab bar mode is another one that comes to mind that probably shouldn't use remaps at all when rendering. We could treat the computing of basic faces similarly=E2=80=A6 a= side from the initial remap of *-inactive/active, remapping would stop being considered. If that's not feasible, then I don't see this proposed patch as better. Users have already made do with the header-line transition in 29 it sounds like. Thanks, --000000000000ace10a0628ae1bde Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Dec 07, 2024 at 1:50 AM, Eli Zaretskii= <eliz@gnu.org> wrote: <= br>

If we do prefer to support re= mapping mode-line and header-line faces, then I can suggest the semi-kludgey "fix" below. Is this better = than what we have now?

<= div class=3D"">

Does this patch ma= ke it so that remaps are considered for header-line even if header-line-act= ive no longer inherits from header-line? If so, I'd consider that even = more surprising. The more I think about this, the less inclined I'd be = to play special case whack-a-mole with it and the more I'd be inclined = to either "live with it" or figure out a way to disable remapping= entirely in certain rendering contexts. Tab bar mode is another one that c= omes to mind that probably shouldn't use remaps at all when rendering. = We could treat the computing=C2=A0of basic faces similarly=E2=80=A6 aside f= rom the initial remap of *-inactive/active, remapping would stop being cons= idered. If that's not feasible, then I don't see this proposed patc= h as better. Users have already made do with the header-line transition in = 29 it sounds like.

Thank= s,
--000000000000ace10a0628ae1bde-- From debbugs-submit-bounces@debbugs.gnu.org Sat Dec 07 10:02:45 2024 Received: (at 73862) by debbugs.gnu.org; 7 Dec 2024 15:02:45 +0000 Received: from localhost ([127.0.0.1]:48183 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tJwKS-00025o-KT for submit@debbugs.gnu.org; Sat, 07 Dec 2024 10:02:45 -0500 Received: from eggs.gnu.org ([209.51.188.92]:53148) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tJwKO-00025X-Po for 73862@debbugs.gnu.org; Sat, 07 Dec 2024 10:02:42 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tJwKJ-0006VG-40; Sat, 07 Dec 2024 10:02:35 -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=iyKoefbkF7bfukIfMjeT/B5pXHkZWpIyXF0g9jqyb5U=; b=eh5caTo3Xyud xcgbEf/+F8vfe92plQvlKL93B0t50sgnTXXGd8qXx5wXXOrksmFEb9nq1D7Vumt1jlv6a2+qupzH8 89vbmgzpNsTDFWCugw4evsy1OfF6+ukWuRomK0+7WS7p6f+LqjZqmorpz32nWFGcY+7uwY94f6Mtf fucMADocEi74fZZUr2KXvnHhjMVxEPGzaIoy7nW+nv7e777RpMVoZP62CC0349hPNcpdu7ekeNfWo 0R0whchENycphm2iijtnlK9nYwmOWa/se498QUKe01OX535tg2UWo99SV2oMD39lH0d5P2uXJr9I7 OGJ0wsRatU12Y33DXX40UQ==; Date: Sat, 07 Dec 2024 17:02:32 +0200 Message-Id: <865xnviliv.fsf@gnu.org> From: Eli Zaretskii To: Aaron Jensen In-Reply-To: (message from Aaron Jensen on Sat, 7 Dec 2024 07:28:33 -0600) Subject: Re: bug#73862: [PATCH] Add `header-line-active` and `header-line-inactive` faces. References: <86wmgfzhgc.fsf@gnu.org> <86zflay7hh.fsf@gnu.org> <86jzcey3cu.fsf@gnu.org> <8634j1n9nx.fsf@gnu.org> <86ldwrkeiy.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 73862 Cc: trevor.m.murphy@gmail.com, me@eshelyaron.com, monnier@iro.umontreal.ca, 73862@debbugs.gnu.org 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: Aaron Jensen > Date: Sat, 7 Dec 2024 07:28:33 -0600 > Cc: Stefan Monnier , trevor.m.murphy@gmail.com, me@eshelyaron.com, > 73862@debbugs.gnu.org > > On Sat, Dec 07, 2024 at 1:50 AM, Eli Zaretskii wrote: > > > If we do prefer to support remapping mode-line and header-line faces, then > > I can suggest the semi-kludgey "fix" below. Is this better than what we > > have now? > > Does this patch make it so that remaps are considered for header-line even > if header-line-active no longer inherits from header-line? It shouldn't. If you apply it and see something like that, it should be considered a bug somewhere (but I would be very surprised if it did happen). All this change does it give the code the chance to account for remapping of header-line-active if header-line was remapped. But if the latter doesn't inherit from the former, that chance will not produce anything that depends on header-line's remapping. > The more I think about this, the less > inclined I'd be to play special case whack-a-mole with it and the more I'd > be inclined to either "live with it" or figure out a way to disable > remapping entirely in certain rendering contexts. Disabling remapping entirely is not feasible, since too many places already account for remapping. > Tab bar mode is another one that comes to mind that probably > shouldn't use remaps at all when rendering. Why not? From debbugs-submit-bounces@debbugs.gnu.org Sat Dec 07 12:14:30 2024 Received: (at 73862) by debbugs.gnu.org; 7 Dec 2024 17:14:30 +0000 Received: from localhost ([127.0.0.1]:48352 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tJyNx-0008OH-Qr for submit@debbugs.gnu.org; Sat, 07 Dec 2024 12:14:30 -0500 Received: from mail-lj1-f175.google.com ([209.85.208.175]:60756) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tJyNw-0008O4-4t for 73862@debbugs.gnu.org; Sat, 07 Dec 2024 12:14:28 -0500 Received: by mail-lj1-f175.google.com with SMTP id 38308e7fff4ca-3011c7b39c7so3057681fa.1 for <73862@debbugs.gnu.org>; Sat, 07 Dec 2024 09:14:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1733591602; x=1734196402; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=AUW+n01TlFiNXaOeuupKvoLOEpY6byZZ/ZMdmPzsQy4=; b=Bq7DMzR8+wm839uR/kTlzqDxd4AiGq3tuFP8HP6ktA1Mv4GF/RLgiaxjkPd8vsknLm WYRqhlS69aQHrG2rycrHv++dwy4VZJgWrM2TjNg+TLo7tQ4fllSWQpbqLXHvrWzzLKN7 5FPrLw3ohebNennnDgbLAxjjJBsZhJXQIr7oVfZEAXTyIbSuFcOnmhPmWriAjHo7AKYx vjFGCLaGvokMG1dKhUVp25E5xVLl++gk7IyjvLkj3tP1zPkLIALeTnEEaqFnU3Tfwep5 TuJmA/NtC44wS7wgpbubqM6TkDJM5+RDVxUJ/PPEIEskqrDR0MC0KIgEabspd20YIqO5 81Vw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733591602; x=1734196402; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=AUW+n01TlFiNXaOeuupKvoLOEpY6byZZ/ZMdmPzsQy4=; b=AjGlJXXh7jlLtiHqiw4xjN0FxI3xwMSct7GfiLEe6Zlomxza6zo9yjAh2rHGTIRbkL dIS0q1Ie2Ghg08xuVAiu2ADqKAIQ/Dc6UkIruv7UR7GtOm2ec6bm1b9OSQf4Nd4d8iBc hpV2Yhq5D5gYH4+0BLAPxrRrO1yLJGnx+Nsquku+O9MVqf+Qi7aBv1iORz5A0zNc0sr8 QRA7uNkvcjcWqFr+NhaSc3qiooQkq56Erco7+d/omnOGmfbsdD/Ws9yvYhNV9GmACRZr bGrZGdzzyXAUihwP8s2GtyNrRwpup9+dCO5XOO1wVPvM6/CMXNXIg2C3ybWaUkzsI9ka QCnA== X-Forwarded-Encrypted: i=1; AJvYcCW7k8ggoRTggQjqQojqhSrFSoT+aA8AHTKQ5Fg6wYTYz4vQoCsPhifkmWRUepLV2HYEVOezKg==@debbugs.gnu.org X-Gm-Message-State: AOJu0YwqdBNcuBGNeCmCfPKcJdLgM4WqPD4u6Y5gV6zQ5zLig9Ymw3MJ p0S+O21qhU2DYWCMLWOXXOSOK5++n+YhMgrUZptYnce1VJqOmmtV/AlD4UzWfOsK8XrUKaK1kmi 1Mr9KXIonaFO420PCPp1Y9HgYwEM= X-Gm-Gg: ASbGncsC0IUT4wYuP15md7MKFiezAmGve1NQdM3Y6F9qHD0aDiD/gS2wWkTciRAOVWO WCt5JjcnFLK0bcy4dIDnh/FIWpsepA7fh5qN3SxEFiEbraLZj9EVCifh6 X-Google-Smtp-Source: AGHT+IH+1lQ4lDu6Dtn/g5mGgHhVXdaA5TTla1ksFAB740+gnxIV9CwTFb+t6y7cgFgFXNb/55ifx7sFl+nVRWZDMEc= X-Received: by 2002:a2e:be9b:0:b0:300:160f:7c76 with SMTP id 38308e7fff4ca-3002fd44fc5mr37646321fa.25.1733591601580; Sat, 07 Dec 2024 09:13:21 -0800 (PST) Received: from 649336022844 named unknown by gmailapi.google.com with HTTPREST; Sat, 7 Dec 2024 12:13:21 -0500 Mime-Version: 1.0 X-Mailer: Superhuman Desktop (2024-12-02T20:06:08Z) X-Superhuman-ID: m4efnzhr.76fbec41-06fd-4a02-abe6-aee0da987733 In-Reply-To: <865xnviliv.fsf@gnu.org> References: <86wmgfzhgc.fsf@gnu.org> <86zflay7hh.fsf@gnu.org> <86jzcey3cu.fsf@gnu.org> <8634j1n9nx.fsf@gnu.org> <86ldwrkeiy.fsf@gnu.org> <865xnviliv.fsf@gnu.org> From: Aaron Jensen X-Superhuman-Draft-ID: draft00145d7b2ca1fe1c Date: Sat, 7 Dec 2024 12:13:20 -0500 Message-ID: Subject: Re: bug#73862: [PATCH] Add `header-line-active` and `header-line-inactive` faces. To: Eli Zaretskii Content-Type: multipart/alternative; boundary="0000000000009912340628b13f5a" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 73862 Cc: trevor.m.murphy@gmail.com, me@eshelyaron.com, monnier@iro.umontreal.ca, 73862@debbugs.gnu.org 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.0 (-) --0000000000009912340628b13f5a Content-Type: text/plain; charset="UTF-8" On Sat, Dec 07, 2024 at 7:02 AM, Eli Zaretskii wrote: > It shouldn't. If you apply it and see something like that, it should be > considered a bug somewhere (but I would be very surprised if it did happen). > Ok, I tested it and you're right, I couldn't see this happen. What I did see happen was if I did this: (custom-set-faces '(header-line-active ((t (:inherit highlight))))) (face-remap-set-base 'highlight 'default) Then the remapping doesn't work. I'm not surprised at this point, but it's still "surprising". Given it's highly unlikely people would do something like this, one could get away with a patch like this most likely. All this change does it give the code the chance to account for remapping > of header-line-active if header-line was remapped. But if the latter > doesn't inherit from the former, that chance will not produce anything that > depends on header-line's remapping. > Ok, thanks. I can't say I understand the code yet, I'd have to study it Tab bar mode is another one that comes to mind that probably shouldn't use > remaps at all when rendering. > > Why not? > Because it's rendered outside of a single buffer. I tried to use it for https://github.com/aaronjensen/emacs-modern-tab-bar and it was a bad idea. I added hooks to set the remaps in every buffer, but once I had a child frame open or was away from the window, the remaps would not be in effect. I ended up doing it with a custom theme, which worked fine and was a better idea. So yes, technically, they "work" and if one anted to make the tab bar look different while a single buffer was selected, they could, so I retract my suggestion to make remapping not work there. Thanks, --0000000000009912340628b13f5a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Dec 07, 2024 at 7:02 AM, Eli Zaretskii <eliz@gnu.org> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

It shouldn't. If you apply it and see something like that, it should be considered a bug somewhere (but I would be very surprised if it did happen).

=
Ok, I tested it and you're right, I couldn't see thi= s happen.

What I did see happen was if I did = this:

(custom-set-faces '(header-lin= e-active ((t (:inherit highlight)))))
(face-remap-set-base &#= 39;highlight 'default)

Then the remapping = doesn't work. I'm not surprised at this point, but it's still &= quot;surprising".=C2=A0 Given it's highly unlikely people would do= something like this, one could get away with a patch like this most likely= .

All this change does it give the code the chance to account for remapping of header-line-active if header-line was remapped. But if the latter doesn't inherit from the former, that chance will not produce anything that depends on header-line's remapping.

=

Ok, tha= nks. I can't say I understand the code yet, I'd have to study it

Tab bar mode is another one that comes to mind that probably shouldn't use remaps at all when rendering.

Why not?


<= /div>
Because it's rendered outside of a single buffer. I tried to = use it for=C2=A0https://github.com/aaronjensen/emacs-modern-tab-bar=C2=A0and it wa= s a bad idea. I added hooks to set the remaps in every buffer, but once I h= ad a child frame open or was away from the window, the remaps would not be = in effect. I ended up doing it with a custom theme, which worked fine and w= as a better idea. So yes, technically, they "work" and if one=C2= =A0anted to make the tab bar look different while a single buffer was selec= ted, they could, so I retract my suggestion to make remapping not work ther= e.=C2=A0

Thanks,
<= /body> --0000000000009912340628b13f5a-- From debbugs-submit-bounces@debbugs.gnu.org Sat Dec 07 13:25:50 2024 Received: (at 73862) by debbugs.gnu.org; 7 Dec 2024 18:25:51 +0000 Received: from localhost ([127.0.0.1]:48478 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tJzV0-0003iM-CU for submit@debbugs.gnu.org; Sat, 07 Dec 2024 13:25:50 -0500 Received: from eggs.gnu.org ([209.51.188.92]:32958) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tJzUx-0003i4-Um for 73862@debbugs.gnu.org; Sat, 07 Dec 2024 13:25:49 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tJzUr-00029e-7q; Sat, 07 Dec 2024 13:25: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=5t1DSDVZJrIM6vooeqViFvKx5hVqc+SWVv0TDtRJA7k=; b=hC0QHiC6OARk zRam8y6BfTlf5wRPGmV484TrAsM4E4B2kXqZ+AqUBrcjuKAc/IZOEGZ8Nj15BWBaqeqY1wobITVOq R5nK8cT1cJkm2+vw1nVgxuY7v2Eg7pk+VHBOZAWJqESppF8OXa2/yHS39mfFhLUuzKWHuCKl0D/Sp xBTBWZq+O5yJO1NwOZIWxygihxTUCpSIkBh0H0C0ONTNLEluxPBGO2UUexn6iI8xOy0cj4H4G/RrJ 56rdyEIQfDAmt4lf7i5JQK1Qfq1edStdbvK1B74nnn98YF26C2KD6gmiJtgFFMuS2XR2+JE1/MYpk Ua0UC9S7Rua8V80dFPkHNg==; Date: Sat, 07 Dec 2024 20:25:38 +0200 Message-Id: <86wmgbgxjx.fsf@gnu.org> From: Eli Zaretskii To: Aaron Jensen In-Reply-To: (message from Aaron Jensen on Sat, 7 Dec 2024 12:13:20 -0500) Subject: Re: bug#73862: [PATCH] Add `header-line-active` and `header-line-inactive` faces. References: <86wmgfzhgc.fsf@gnu.org> <86zflay7hh.fsf@gnu.org> <86jzcey3cu.fsf@gnu.org> <8634j1n9nx.fsf@gnu.org> <86ldwrkeiy.fsf@gnu.org> <865xnviliv.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 73862 Cc: trevor.m.murphy@gmail.com, me@eshelyaron.com, monnier@iro.umontreal.ca, 73862@debbugs.gnu.org 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: Aaron Jensen > Date: Sat, 7 Dec 2024 12:13:20 -0500 > Cc: monnier@iro.umontreal.ca, trevor.m.murphy@gmail.com, me@eshelyaron.com, > 73862@debbugs.gnu.org > > On Sat, Dec 07, 2024 at 7:02 AM, Eli Zaretskii wrote: > > > It shouldn't. If you apply it and see something like that, it should be > > considered a bug somewhere (but I would be very surprised if it did happen). > > > > Ok, I tested it and you're right, I couldn't see this happen. > > What I did see happen was if I did this: > > (custom-set-faces '(header-line-active ((t (:inherit highlight))))) > (face-remap-set-base 'highlight 'default) > > Then the remapping doesn't work. Repeat after me: "basic faces cannot follow remapping due to face inheritance". They are called "basic" because they aren't supposed to inherit from anything, but be used to inherit _from_. The patch I posted is supposed to make Emacs be more backward-compatible, in that people who used to remap header-line will see their remapping propagate to header-line-active etc., but only as long as they inherit from header-line, which they do by default. Making header-line inherit from highlight didn't work before, and should not be expected to work now. If we install the patch I posted, I wouldn't even document this special handling of these faces, because its only purpose is to help with backward compatibility. > I'm not surprised at this point, but it's still "surprising". It had never worked! And was not supposed to work! > Given it's highly unlikely people would do something > like this, one could get away with a patch like this most likely. If people were doing something like that, they would be complaining long ago. > > Tab bar mode is another one that comes to mind that probably shouldn't use > > remaps at all when rendering. > > > > Why not? > > Because it's rendered outside of a single buffer. It doesn't have to be. It's just a face. Granted, when a face is used without relation to a buffer, then using a buffer-local customization of it (which is what face-remapping is) is not a good idea. As with many Emacs features, users shoot themselves in the foot by (ab)using the features outside of their intended design space, and then complain that things fall apart. Emacs trusts the users that they know what they are doing, although that trust is not always justified, it seems... From debbugs-submit-bounces@debbugs.gnu.org Sat Dec 07 13:47:39 2024 Received: (at 73862) by debbugs.gnu.org; 7 Dec 2024 18:47:39 +0000 Received: from localhost ([127.0.0.1]:48504 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tJzq7-0004kC-2J for submit@debbugs.gnu.org; Sat, 07 Dec 2024 13:47:39 -0500 Received: from mail-lj1-f178.google.com ([209.85.208.178]:57428) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tJzq3-0004k2-S4 for 73862@debbugs.gnu.org; Sat, 07 Dec 2024 13:47:37 -0500 Received: by mail-lj1-f178.google.com with SMTP id 38308e7fff4ca-2ffbf4580cbso32255681fa.2 for <73862@debbugs.gnu.org>; Sat, 07 Dec 2024 10:47:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1733597195; x=1734201995; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=aHn6vwITilklVmuJT3zydfgg8jCxZWbpqZ/2EqZSYZc=; b=OurZ1EY3yhvyCSeWgbptL2cK3qTkH/C3ViBc/daCBNv8PFCont09Wy3vwCA5XKA36u VwKO1sqwySsyUH3HRK94sySjINxkZkj1wGHtRfAKRBqXALcGqol3b5xpQsGotF37Pv4f ppOUtiQipYOUJWJG/e85UbrqwU9NECnOzyli/K9t0Cy2h+cCOuhhaGASJpYFJKqliqIQ Db4voJSgANYtcGNqtgToJDwTQs0AG/xELvbTe19SFFssZ2IrFbfo7bZNsDMfhZYNG+/G NRDqq/pCSHKHGamUI1McwZsYwzC6ewNGI/umhgg5zaWPCvHBjke1mzG044lN8YWws+CL TrqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733597195; x=1734201995; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=aHn6vwITilklVmuJT3zydfgg8jCxZWbpqZ/2EqZSYZc=; b=bbxF3ZI6qtC8phuVvPzUQL5OV+1GjjgJGu0MbbaLOzVfiHHFLyvPW4iUSZQxpM3Yx+ LNxuZyXZAyUmM7cOgPHrrzSlhO8n6IEQpvxLysw25qH+q37LVKosvUafucK2jzToSZNK WX9mbmMq3vCIzYC8oKqCFlvOtjiTnw8tQiFPrV1gh0XWT5gpns4dSAxx9jc2XRzraEDF OJvjU1pP8h9iv21y0RIJgZBhKUg8hDCC5Cddps14dIgefGOSKUJm56E02Wpb0zNlmoC0 80DWvFC7sgLFcKbxGWmdjSJugp9JRpRRsXhq3Oqo8A25XJdLEJVxPoAX5A/coosxI98n WKTg== X-Forwarded-Encrypted: i=1; AJvYcCXXAriEZosrV98n/JijluoXjF8QQ7JtUZHF0+wIX/paO0XJ0CjMuEE4eFCuMcxMkdrtcYuYzA==@debbugs.gnu.org X-Gm-Message-State: AOJu0Yyk1/QFeHiQQ5RbvnvtPP+0HWXqhU/g3d8lc9mjiubu8LDMmOY8 M2Jvuhno9toox/CiYJh42gMtDbvGe5GId1qdiTbjvbMdJDHs8WrA8EYSLh1hmzzEXJJi1Q1mcon WisHuBfLg8wzh2R0wMraCyJPEamE= X-Gm-Gg: ASbGncvD675OkEd6hL8nAUqsmOfioB9ND2uXLZ8qSheVkHiAtXjt/lRcNmSfOhBhRAo uPhDu4wc2IC1vgQFff3KlIudb4//T221jVFIp4ia7nm09noPfqX6rBwHY X-Google-Smtp-Source: AGHT+IHJBujf5uB1ZRB7Af2nP+EJtTi7c/OcRSSZa17pu42y4E+r+2WKmoQSb+Rha5MES660ZhkI9XkIdKqedKzZnGk= X-Received: by 2002:a2e:9a0e:0:b0:300:1f12:3d54 with SMTP id 38308e7fff4ca-3002f62f680mr35589601fa.1.1733597194562; Sat, 07 Dec 2024 10:46:34 -0800 (PST) Received: from 649336022844 named unknown by gmailapi.google.com with HTTPREST; Sat, 7 Dec 2024 13:46:33 -0500 Mime-Version: 1.0 In-Reply-To: <86wmgbgxjx.fsf@gnu.org> References: <86wmgfzhgc.fsf@gnu.org> <86zflay7hh.fsf@gnu.org> <86jzcey3cu.fsf@gnu.org> <8634j1n9nx.fsf@gnu.org> <86ldwrkeiy.fsf@gnu.org> <865xnviliv.fsf@gnu.org> <86wmgbgxjx.fsf@gnu.org> From: Aaron Jensen X-Mailer: Superhuman Desktop (2024-12-02T20:06:08Z) X-Superhuman-ID: m4eizvg6.38fd5ae4-1367-402f-b014-79191ae116f0 X-Superhuman-Draft-ID: draft0095f23857e0a4bd Date: Sat, 7 Dec 2024 13:46:33 -0500 Message-ID: Subject: Re: bug#73862: [PATCH] Add `header-line-active` and `header-line-inactive` faces. To: Eli Zaretskii Content-Type: multipart/alternative; boundary="000000000000f738a70628b28cc1" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 73862 Cc: trevor.m.murphy@gmail.com, me@eshelyaron.com, monnier@iro.umontreal.ca, 73862@debbugs.gnu.org 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.0 (-) --000000000000f738a70628b28cc1 Content-Type: text/plain; charset="UTF-8" On Sat, Dec 07, 2024 at 10:25 AM, Eli Zaretskii wrote: > Repeat after me: "basic faces cannot follow remapping due to face > inheritance". > Oh, I know that *now*. I also know what basic faces are *now*. I'm no longer ignorant to this, and, for what it's worth, this came across as rude given the circumstances. I'm not being obstinate here. I'm not expecting Emacs to do something it never did. I'm only representing the beginner's mind. The thing that we *should* be considering when designing tools. Developers "knowing better" than users is what makes so much of the software we use garbage. Emacs isn't garbage, but I'm trying to communicate that this behavior is surprising because there is no explicit (that I know of) differentiation between "basic" faces and non-"basic" faces. You said this about me not knowing about basic faces: "As a Lisp programmer, you aren't supposed to know that, or care." And I'm saying that as someone who does not know what a basic face is, how in the world can I be expected to know or intuit that this classification I do not know exist means that inheriting and remapping doesn't work? That is my *only* point. They are called "basic" because they aren't supposed to inherit from > anything, but be used to inherit _from_. > If this were *prevented* or a warning in some way, this would solve all of the problems. If this is really what they are, and that were codified and explicit, the guard rails would be in place to teach the beginner users. I would prefer this to something that enables backwards compatibility, but that ship may have sunk (sailed) already. A combination of the two things could work as well (explicit backwards compatibility, for mode-line and header-line faces, but a warning when "basic" faces inherit from anything else). The patch I posted is supposed to make Emacs be more backward-compatible, > in that people who used to remap header-line will see their remapping > propagate to header-line-active etc., but only as long as they inherit from > header-line, which they do by default. Making header-line inherit from > highlight didn't work before, and should not be expected to work now. > > If we install the patch I posted, I wouldn't even document this special > handling of these faces, because its only purpose is to help with backward > compatibility. > > I'm not surprised at this point, but it's still "surprising". > > It had never worked! And was not supposed to work! > I believe you are misunderstanding my use of the word "surprising". I hope it's more clear now. As with many Emacs features, users shoot themselves in the foot by > (ab)using the features outside of their intended design space, and then > complain that things fall apart. Emacs trusts the users that they know what > they are doing, although that trust is not always justified, it seems... > > Aye, even someone who has been using Emacs for nearly 10 years does not know everything about customizing it and building packages for it and has to learn through trial and error. It's part of what makes Emacs Emacs. I learned something about face remapping and themes in building that package and I'm glad to know it. That said, as software designers, we are not supposed to be frustrated be insulting when our users complain "that things fall apart", nor should we think of it as trust not being justified. We can miss the target too. If our designs are not intention revealing, or are "surprising", we should recognize that as feedback and recognize we may have gotten something wrong. Our users are doing us a favor by giving us feedback in that moment. Belittling them doesn't get us anywhere good, in my experience. There will always be users that we could never "dumb things down" enough for, and if that's how I'm coming across right now, I apologize. Aaron --000000000000f738a70628b28cc1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Dec 07, 2024 at 10:25 AM, Eli Zaretski= i <eliz@gnu.org> wrote:<= br>

Repeat after me: "basic faces cannot follow remapping due to face inheritance".

=

Oh, I know that *= now*. I also know what basic faces are *now*. I'm no longer ignorant to= this, and, for what it's worth, this came across as rude given the cir= cumstances. I'm not being obstinate here. I'm not expecting Emacs t= o do something it never did. I'm only representing the beginner's m= ind. The thing that we *should* be considering when designing tools. Develo= pers "knowing better" than users is what makes so much of the sof= tware we use garbage. Emacs isn't garbage, but I'm trying to commun= icate that this behavior is surprising because there is no explicit (that I= know of) differentiation between "basic" faces and non-"bas= ic" faces.=C2=A0

Yo= u said this about me not knowing about basic faces: "As a Lisp programmer, you aren't supposed to know that, or c= are."

And I'm saying that as someone w= ho does not know what a basic face is, how in the world can I be expected t= o know or intuit that this classification I do not know exist means that in= heriting and remapping doesn't work? That is my *only* point.=C2=A0
<= div class=3D"">

They are called "basic" because they aren't supposed to inher= it from anything, but be used to inherit _from_.


If this were *prevented* or = a warning in some way, this would solve all of the problems. If this is rea= lly what they are, and that were codified and explicit, the guard rails wou= ld be in place to teach the beginner users. I would prefer this to somethin= g that enables backwards compatibility, but that ship may have sunk (sailed= ) already. A combination of the two things could work as well (explicit=C2= =A0backwards compatibility, for mode-line and header-line faces, but a warn= ing when "basic" faces inherit from anything else).

The patch I posted is supposed to make Emacs be more backward-compatible, in that people who used to remap header-line will see their remapping propagate to header-line-active etc., but only as long as they inherit from header-line, which they do by default. Making header-line inherit from highlight didn't work before, and should not be expected to work now.

If we install the patch I posted, I wouldn't even document this special handling of these faces, because its only purpose is to help with backward compatibility.

I'm not surprised at this point, but it's still "surprising&qu= ot;.

It had never worked! And was not supposed to work!


I believe you are= misunderstanding my use of the word "surprising". I hope it'= s more clear now.

As with many Emacs features, users shoot themselves in the foot by
(ab)using the features outside of their intended design space, and then complain that things fall apart. Emacs trusts the users that they know what they are doing, although that trust is not always justified, it seems...


Aye, even someone who has been using = Emacs for nearly 10 years does not know everything about customizing it and= building packages=C2=A0for it and has to learn through trial and error. It= 's part of what makes Emacs Emacs. I learned something about face remap= ping and themes in building that package and I'm glad to know it.

That said, as software designers, we are not suppos= ed to be frustrated be insulting when our users complain "that things = fall apart", nor should we think of it as trust not being justified. W= e can miss the target too. If our designs are not intention revealing, or a= re "surprising", we should recognize that as feedback and recogni= ze=C2=A0we may have gotten something wrong. Our users are doing us a favor = by giving us feedback in that moment. Belittling them doesn't get us an= ywhere good, in my experience. There will always be users that we could nev= er "dumb things down" enough for, and if that's how=C2=A0I= 9;m coming across right now, I apologize.

Aaro= n

--000000000000f738a70628b28cc1-- From debbugs-submit-bounces@debbugs.gnu.org Sat Dec 07 14:00:11 2024 Received: (at 73862) by debbugs.gnu.org; 7 Dec 2024 19:00:11 +0000 Received: from localhost ([127.0.0.1]:48525 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tK02E-0005PE-G0 for submit@debbugs.gnu.org; Sat, 07 Dec 2024 14:00:11 -0500 Received: from eggs.gnu.org ([209.51.188.92]:50978) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tK02B-0005JG-AE for 73862@debbugs.gnu.org; Sat, 07 Dec 2024 14:00:08 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tK024-00053J-Vg; Sat, 07 Dec 2024 14:00: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=BbcdIj3jWng+K3IxRN83koNbyM2z94mMXZm490pd/Mk=; b=DN3wGzUCh7X/ CcIbGmI3ThKT68EV5YYsnN30vV5grZL+ivTW3CPRuW2szsCCqlsLyx8UVsUHhOe3shBXiEzSZc4sC VYkwG2vCGrrMyh0hoqrY2YejrELmDMera9GAK0+PBbqg3KHvw1e1UIs2MgwyujTAMdE76ZndQ8Y97 0nYEnKeQkfXAMq7JSPmNwp2oK0dvWDzJJRDDmOgiwUzAccJ/QZ7yFFT0SAFxYFK9x3SnV6RvqceoA 7fSgexYjCq0D0HCXTHVxUthaFDR2OFg0MJ5MdTyHgf9Cc2K1Z8wOReHlWlGnKbBH3zxG61dnN7M1C FqidyI7boQJ7roQcgTG1qg==; Date: Sat, 07 Dec 2024 20:59:56 +0200 Message-Id: <86ttbfgvyr.fsf@gnu.org> From: Eli Zaretskii To: Aaron Jensen In-Reply-To: (message from Aaron Jensen on Sat, 7 Dec 2024 13:46:33 -0500) Subject: Re: bug#73862: [PATCH] Add `header-line-active` and `header-line-inactive` faces. References: <86wmgfzhgc.fsf@gnu.org> <86zflay7hh.fsf@gnu.org> <86jzcey3cu.fsf@gnu.org> <8634j1n9nx.fsf@gnu.org> <86ldwrkeiy.fsf@gnu.org> <865xnviliv.fsf@gnu.org> <86wmgbgxjx.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 73862 Cc: trevor.m.murphy@gmail.com, me@eshelyaron.com, monnier@iro.umontreal.ca, 73862@debbugs.gnu.org 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: Aaron Jensen > Date: Sat, 7 Dec 2024 13:46:33 -0500 > Cc: monnier@iro.umontreal.ca, trevor.m.murphy@gmail.com, me@eshelyaron.com, > 73862@debbugs.gnu.org > > On Sat, Dec 07, 2024 at 10:25 AM, Eli Zaretskii wrote: > > > Repeat after me: "basic faces cannot follow remapping due to face > > inheritance". > > > > Oh, I know that *now*. I also know what basic faces are *now*. I'm no > longer ignorant to this, and, for what it's worth, this came across as rude > given the circumstances. I'm not being obstinate here. I'm not expecting > Emacs to do something it never did. I'm only representing the beginner's > mind. The thing that we *should* be considering when designing tools. > Developers "knowing better" than users is what makes so much of the > software we use garbage. Emacs isn't garbage, but I'm trying to communicate > that this behavior is surprising because there is no explicit (that I know > of) differentiation between "basic" faces and non-"basic" faces. > > You said this about me not knowing about basic faces: "As a Lisp > programmer, you aren't supposed to know that, or care." > > And I'm saying that as someone who does not know what a basic face is, how > in the world can I be expected to know or intuit that this classification I > do not know exist means that inheriting and remapping doesn't work? That is > my *only* point. > > They are called "basic" because they aren't supposed to inherit from > > anything, but be used to inherit _from_. > > > > If this were *prevented* or a warning in some way, this would solve all of > the problems. If this is really what they are, and that were codified and > explicit, the guard rails would be in place to teach the beginner users. I > would prefer this to something that enables backwards compatibility, but > that ship may have sunk (sailed) already. A combination of the two things > could work as well (explicit backwards compatibility, for mode-line and > header-line faces, but a warning when "basic" faces inherit from anything > else). > > The patch I posted is supposed to make Emacs be more backward-compatible, > > in that people who used to remap header-line will see their remapping > > propagate to header-line-active etc., but only as long as they inherit from > > header-line, which they do by default. Making header-line inherit from > > highlight didn't work before, and should not be expected to work now. > > > > If we install the patch I posted, I wouldn't even document this special > > handling of these faces, because its only purpose is to help with backward > > compatibility. > > > > I'm not surprised at this point, but it's still "surprising". > > > > It had never worked! And was not supposed to work! > > > > I believe you are misunderstanding my use of the word "surprising". I hope > it's more clear now. > > As with many Emacs features, users shoot themselves in the foot by > > (ab)using the features outside of their intended design space, and then > > complain that things fall apart. Emacs trusts the users that they know what > > they are doing, although that trust is not always justified, it seems... > > > > > Aye, even someone who has been using Emacs for nearly 10 years does not > know everything about customizing it and building packages for it and has > to learn through trial and error. It's part of what makes Emacs Emacs. I > learned something about face remapping and themes in building that package > and I'm glad to know it. > > That said, as software designers, we are not supposed to be frustrated be > insulting when our users complain "that things fall apart", nor should we > think of it as trust not being justified. We can miss the target too. If > our designs are not intention revealing, or are "surprising", we should > recognize that as feedback and recognize we may have gotten something > wrong. Our users are doing us a favor by giving us feedback in that moment. > Belittling them doesn't get us anywhere good, in my experience. There will > always be users that we could never "dumb things down" enough for, and if > that's how I'm coming across right now, I apologize. I'm sorry you interpret what I wrote as rude, or insulting, or anything of that kind. If anything, it was supposed to be mildly humorous. And when I say "you aren't supposed to", I don't mean you personally. So this is all a huge misunderstanding. My only motivation was to explain what you see and maybe make Emacs a tad better, that's all. Sorry. P.S. My personal conclusion from this, and from many past bug reports that causes us to add explicit remapping in many places, is that face-remapping was a clever hack that should not have been allowed to happen without a thorough rewrite of all the basic code which supports faces and their merging. Hindsight is always 20/20. From debbugs-submit-bounces@debbugs.gnu.org Sat Dec 07 14:07:40 2024 Received: (at 73862) by debbugs.gnu.org; 7 Dec 2024 19:07:40 +0000 Received: from localhost ([127.0.0.1]:48533 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tK09U-0005jP-BE for submit@debbugs.gnu.org; Sat, 07 Dec 2024 14:07:40 -0500 Received: from mail-lj1-f178.google.com ([209.85.208.178]:53723) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tK09R-0005jG-56 for 73862@debbugs.gnu.org; Sat, 07 Dec 2024 14:07:38 -0500 Received: by mail-lj1-f178.google.com with SMTP id 38308e7fff4ca-2ffdbc0c103so28184691fa.3 for <73862@debbugs.gnu.org>; Sat, 07 Dec 2024 11:07:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1733598396; x=1734203196; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:references:from:in-reply-to :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=DlRriEmite/6LkgYucPdIUKQjzEZxhnrP3SrdWTWAJY=; b=VCww+pkMr3XNZ2MPjO/vVz4MsfEwi4S8U+CIXRPW+tZHzOIz7unh/p62CT+AHJIhCi 1ahowEhM07X5wHDz5fcpVjmiDCTtvIs6hqmHD4+qFbeGfmp+HKNuJX9XqAsoLjh9j7SV fyt1PWnc9qjAXFpCJUu6VLdu7K6S5Qr/HqxTjcdlApOa8r5xoDNAnqz75rTJlyDyqmIT q/HVSyZu7ijp7NwHhhGzIVaSRA2ZcOzYXwpWRIx3EOKabiXsvPB4wawKAye5hVVFJhur mUg/QDSsRuhL6oA8M63oFwv+lCCdPvRIftVXhyO+x+RnKlVC8HV1UIrk6kqsLneNPVN7 g/9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733598396; x=1734203196; h=cc:to:subject:message-id:date:references:from:in-reply-to :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=DlRriEmite/6LkgYucPdIUKQjzEZxhnrP3SrdWTWAJY=; b=YaE24TjUqQAVhtPqgEzOkLvP+hNdsX82tCklUDdgzf+c55QcWDyiW0SJVKcYGDioLG 80anvjvMqNhi7eqIT+zDwCYiwP0VHxtdhrXq6pRaX5OuZrOaIk1sAj+ISByiNValc3YF kpR0ermutU7kfDk6HH9956r4jEoTY+p3pP5RjdsgA6JrHOUjzNQDcdBXDklx22VbBuJD F6v44fnS6zICaC7PtiZeLnGi3mGx9XedFi1ETlkMHDj7x5DsFT11hYUbsOkrF0aRZ9Yz EEuSTE6Xmcmir2ivsYwwb/DNyQ774OYYMs7vmq3YayD76++5vNulvv5IsTnwJvme3RS4 KpEw== X-Forwarded-Encrypted: i=1; AJvYcCVfILqcjVgl1Xov+Pl229sPKzDEROEDVFUJcGMJCqz3+gEQc+zEuSpKiJK11oC1jlQ8sNcd/g==@debbugs.gnu.org X-Gm-Message-State: AOJu0Yx98PyVgQQoMiHvFN0plwsZsGU+gRhVCRoiGORlVsHZiPlDkjGT Iwd2/JoOxmiJ014aW+Wq6HqxpJmdHFz6bwhaANNXKXxlUsTksSUOTcqm+XtIdHYtCSK/s4hKDHE uOMbd6tt1S5vBM78QjsFkKQ4FfLY= X-Gm-Gg: ASbGnct7NwSGLwCNpitIHEdtUxXrqT+ivhLR4BDReXX9qY3z6501CqfZnlo++HK0FYu boO4IHqrmcJRyB0WR6anrk7o2M00eUeVED/VzPg2oiUgApcNPmvUpGDUc X-Google-Smtp-Source: AGHT+IEpgEDrtSbY1RXQIjva6KkRCzLuO8ZL3DGH/JWeR0+8bmj9IY4fzQR/jhlwGlK66S5Q7MyMAFDNENXrllkWdUc= X-Received: by 2002:a05:651c:888:b0:300:43f9:ad57 with SMTP id 38308e7fff4ca-30043f9ae30mr9693711fa.32.1733598395929; Sat, 07 Dec 2024 11:06:35 -0800 (PST) Received: from 649336022844 named unknown by gmailapi.google.com with HTTPREST; Sat, 7 Dec 2024 14:06:35 -0500 Mime-Version: 1.0 X-Mailer: Superhuman Desktop (2024-12-02T20:06:08Z) In-Reply-To: <86ttbfgvyr.fsf@gnu.org> From: Aaron Jensen X-Superhuman-ID: m4ejpmil.08cf928d-85fa-4b32-b47a-5b0af4ab70f4 X-Superhuman-Draft-ID: draft007a1c0c4b7ed5ab References: <86wmgfzhgc.fsf@gnu.org> <86zflay7hh.fsf@gnu.org> <86jzcey3cu.fsf@gnu.org> <8634j1n9nx.fsf@gnu.org> <86ldwrkeiy.fsf@gnu.org> <865xnviliv.fsf@gnu.org> <86wmgbgxjx.fsf@gnu.org> <86ttbfgvyr.fsf@gnu.org> Date: Sat, 7 Dec 2024 14:06:35 -0500 Message-ID: Subject: Re: bug#73862: [PATCH] Add `header-line-active` and `header-line-inactive` faces. To: Eli Zaretskii Content-Type: multipart/alternative; boundary="000000000000929d340628b2d42c" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 73862 Cc: trevor.m.murphy@gmail.com, me@eshelyaron.com, monnier@iro.umontreal.ca, 73862@debbugs.gnu.org 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.0 (-) --000000000000929d340628b2d42c Content-Type: text/plain; charset="UTF-8" On Sat, Dec 07, 2024 at 10:59 AM, Eli Zaretskii wrote: > I'm sorry you interpret what I wrote as rude, or insulting, or anything of > that kind. If anything, it was supposed to be mildly humorous. And when I > say "you aren't supposed to", I don't mean you personally. > Thank you, it's all good and I'm glad it was only a misinterpretation on my part. For what it's worth, I do appreciate the *massive* amount of user engagement choose to do. Thank you for that and for everything else you do for Emacs. P.S. My personal conclusion from this, and from many past bug reports that > causes us to add explicit remapping in many places, is that face-remapping > was a clever hack that should not have been allowed to happen without a > thorough rewrite of all the basic code which supports faces and their > merging. Hindsight is always 20/20. > That's a very interesting conclusion, and it makes sense. Would it make sense to extend the face doc strings that should not use inheritance to indicate that? That combined with the backwards compatibility fix you suggested may very well be a good compromise for the current circumstance. Alternatively, if there were a path to deprecating header-line and mode-line then the compatibility fix could be skipped. Thanks, Aaron --000000000000929d340628b2d42c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Dec 07, 2024 at 10:59 AM, Eli Zaretskii <eliz@gnu.org> wrote:
<= div class=3D"sh-quoted-content">
=

I'm sorry you interpret what I wrote as rude, or insulting, or anything of that kind. If anything, it was supposed to be mildly humorous. And when I say "you aren't supposed to", I don'= ;t mean you personally.


Thank you, it's all good and I'm glad it was only= a misinterpretation on my part. For what it's worth, I do appreciate t= he *massive* amount of user engagement choose to do. Thank you for that and= for everything else you do for Emacs.

P.S. My personal conclusion from this, and from many past bug reports that causes us to add explicit remapping in many places, is that face-remapping was a clever hack that should not have been allowed to happen without a thorough rewrite of all the basic code which supports faces and their merging. Hindsight is always 20/20.


That's a ver= y interesting conclusion, and it makes sense.

= Would it make sense to extend the face doc strings that should not use inhe= ritance to indicate that? That combined with the backwards compatibility fi= x you suggested may very well be a good compromise for the current circumst= ance.

Alternatively, if there were=C2=A0a path= to deprecating header-line and mode-line then the compatibility=C2=A0fix c= ould be skipped.

Thanks,

<= div>Aaron

--000000000000929d340628b2d42c-- From debbugs-submit-bounces@debbugs.gnu.org Sat Dec 07 14:20:03 2024 Received: (at 73862) by debbugs.gnu.org; 7 Dec 2024 19:20:03 +0000 Received: from localhost ([127.0.0.1]:48556 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tK0LS-0006HL-LI for submit@debbugs.gnu.org; Sat, 07 Dec 2024 14:20:03 -0500 Received: from eggs.gnu.org ([209.51.188.92]:59796) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tK0LQ-0006Gf-N9 for 73862@debbugs.gnu.org; Sat, 07 Dec 2024 14:20:01 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tK0LK-0007AI-AM; Sat, 07 Dec 2024 14:19:54 -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=Emc0GukwrnYgUhHlJIOx+3tP12Vz83wK75hMbuc0nE0=; b=avXMxWHTIcLg EK1evRhJVOhwPMZ21BU9Di4Q9XH/Vg2UJWxb2cKCeq+TvXiSxMhAudl70Jr1DgqifFjxMDfflArfm Vj6jIvACqI5cZZ3U6V/oucnFEoGMN6eyJqDgMbCkbPqxpnZA2cuUzNPMhmZIKmwAXS49zVa0PnhyD ih+6aMBCCtQiJ2a0P5wAGKnsm/dHl8WcyC5a/lpio5xiR1k/H8Vd0rZTW3ijLIURCKPT88q8JObjk w9/HNq/bG/X4/zOvf/nn0sZYXLBLndgsbMofJxNAeNn//bATWdtDw6kEJ0PTq09CPLqrLolbbKZLG 8rrirYIHu1KDwO6aT8hy9g==; Date: Sat, 07 Dec 2024 21:19:52 +0200 Message-Id: <86r06jgv1j.fsf@gnu.org> From: Eli Zaretskii To: Aaron Jensen In-Reply-To: (message from Aaron Jensen on Sat, 7 Dec 2024 14:06:35 -0500) Subject: Re: bug#73862: [PATCH] Add `header-line-active` and `header-line-inactive` faces. References: <86wmgfzhgc.fsf@gnu.org> <86zflay7hh.fsf@gnu.org> <86jzcey3cu.fsf@gnu.org> <8634j1n9nx.fsf@gnu.org> <86ldwrkeiy.fsf@gnu.org> <865xnviliv.fsf@gnu.org> <86wmgbgxjx.fsf@gnu.org> <86ttbfgvyr.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 73862 Cc: trevor.m.murphy@gmail.com, me@eshelyaron.com, monnier@iro.umontreal.ca, 73862@debbugs.gnu.org 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: Aaron Jensen > Date: Sat, 7 Dec 2024 14:06:35 -0500 > Cc: monnier@iro.umontreal.ca, trevor.m.murphy@gmail.com, me@eshelyaron.com, > 73862@debbugs.gnu.org > > Would it make sense to extend the face doc strings that should not use > inheritance to indicate that? I'm not sure. Inheritance does work for the basic faces, it's just that face-remapping doesn't get passed by inheritance. > Alternatively, if there were a path to deprecating header-line and > mode-line then the compatibility fix could be skipped. Let's see what Stefan and others think about this. We also haven't yet heard from Eshel. From debbugs-submit-bounces@debbugs.gnu.org Sat Dec 07 15:00:43 2024 Received: (at 73862) by debbugs.gnu.org; 7 Dec 2024 20:00:43 +0000 Received: from localhost ([127.0.0.1]:48619 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tK0yo-0008Mg-Qa for submit@debbugs.gnu.org; Sat, 07 Dec 2024 15:00:43 -0500 Received: from mail-lj1-f180.google.com ([209.85.208.180]:48598) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tK0yj-0008ML-Pc for 73862@debbugs.gnu.org; Sat, 07 Dec 2024 15:00:41 -0500 Received: by mail-lj1-f180.google.com with SMTP id 38308e7fff4ca-3003e203acaso8144541fa.1 for <73862@debbugs.gnu.org>; Sat, 07 Dec 2024 12:00:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1733601572; x=1734206372; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:references:in-reply-to:from :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=IsRr5xpr1kfK2RBM7ae8pJJhYGQGCVuDeQlFq9c1Mqc=; b=hlHe4ZLc9DpjMvFu1mUYkwdYPvIsr1QQebEVNi/zQDm3IwcYiXLrS8d8TqSDpowFxZ IqkUku4w2xsTbRQrFR/ApqMtXQ0ZeAE7Z7Lwnx2fdRj4oD7Z8il37a56IH6RpHuHCCMg 3MWMOW05guUc4w1w1Wb/jXqfaF6qd8bQA4Srd5dY7l6Za3M5nCGgVenJkDAukU4QmRmx kHbRaA0TtV6e7xrszEN4kb6VtSCLU/W0LUEBmXNoeYTKTGDKEFNQR0V+HQ8GMUeUIz6x DiOIsxk0zK/rHdDB4AJ6K/OqpgK2eT8CHWN4vCNgsCWDh7weQz3z5k6DgrDrmz2dktiv YbRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733601572; x=1734206372; h=cc:to:subject:message-id:date:references:in-reply-to:from :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=IsRr5xpr1kfK2RBM7ae8pJJhYGQGCVuDeQlFq9c1Mqc=; b=thEXc108E20lUV3zBFGVHGKNF6uh+nYusJ1TDcQlJSbrQAsCgzLmAE0uJHNLpwf09w 1nT4AJwc53mg0AKSnoaQWcy8b3VuVnpkdxzMyCzIlwHJdDRj+HjUP6R5oSnbMwFQFLPT 5QX6Y66QV5PtYxT+Vb157vTLrGpt32ZQQKichXYl1UKtKqvw5d5g0iy/6swejGvh3yBF wm6hAU67QPRwyp69WKxYRxzPd3cOiz5Kuna+GwC5rpg9egymPNQOooi9RH+DnZvRUups kl+atgzudlVk7WbqoLU9R3wE6Sl+Czde50MS4hkKrixARndXNTvYYcZBm3hZKBZbYp7m dPnw== X-Forwarded-Encrypted: i=1; AJvYcCXKf8fhqyrqU4dPwsDCyHc7L51UPxr/DUYHh0YJVIRutj4Fe3Xv+KzeuoikgMsBqvJK79/v+A==@debbugs.gnu.org X-Gm-Message-State: AOJu0YwUDP+5GkQ0s8TDbMcXxkbkwI/KRd9Jf/32VFNGCT20OYMNdHab Z1MDSAMKRgsIceIPG4wGxbYiMFViLCPcJKIy1XiHKyNeQHHkNBTWpaFgjN9aFVA+vxv+P/Aycsa 09AxgJJVnCTLzIuLEhcEKMyo4Cok= X-Gm-Gg: ASbGncuzoz+ze0+3/69Dukrj9jklTGwhwRV5t6SrMt70sEzay8ruFQLHvalz+irKdtu 7Ei+CL7OEz1ZD+XrAB0tnEaGnpn7lO9jrNq/n9/XnEdyDIVYDGKOlDA5V X-Google-Smtp-Source: AGHT+IFGUSIk1UwsyXfyqbH18mQVODO5AJOVRQTpmDRXYtpy1yntlH0QJgDfIZ79821ckQv+dwOXGCN7dsf3E2xVSok= X-Received: by 2002:a05:651c:154f:b0:300:3a15:8f1f with SMTP id 38308e7fff4ca-3003a1593admr23882761fa.32.1733601571461; Sat, 07 Dec 2024 11:59:31 -0800 (PST) Received: from 649336022844 named unknown by gmailapi.google.com with HTTPREST; Sat, 7 Dec 2024 14:59:30 -0500 Mime-Version: 1.0 From: Aaron Jensen X-Superhuman-ID: m4ello73.95a68c99-786f-4ac0-90b7-696c251d971d In-Reply-To: <86r06jgv1j.fsf@gnu.org> References: <86wmgfzhgc.fsf@gnu.org> <86zflay7hh.fsf@gnu.org> <86jzcey3cu.fsf@gnu.org> <8634j1n9nx.fsf@gnu.org> <86ldwrkeiy.fsf@gnu.org> <865xnviliv.fsf@gnu.org> <86wmgbgxjx.fsf@gnu.org> <86ttbfgvyr.fsf@gnu.org> <86r06jgv1j.fsf@gnu.org> X-Mailer: Superhuman Desktop (2024-12-02T20:06:08Z) X-Superhuman-Draft-ID: draft000d29c40e307c9b Date: Sat, 7 Dec 2024 14:59:30 -0500 Message-ID: Subject: Re: bug#73862: [PATCH] Add `header-line-active` and `header-line-inactive` faces. To: Eli Zaretskii Content-Type: multipart/alternative; boundary="000000000000d9674f0628b391c5" X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 73862 Cc: trevor.m.murphy@gmail.com, me@eshelyaron.com, monnier@iro.umontreal.ca, 73862@debbugs.gnu.org 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.0 (-) --000000000000d9674f0628b391c5 Content-Type: text/plain; charset="UTF-8" On Sat, Dec 07, 2024 at 11:19 AM, Eli Zaretskii wrote: > From: Aaron Jensen > Date: Sat, 7 Dec 2024 14:06:35 -0500 > Cc: monnier@iro.umontreal.ca, trevor.m.murphy@gmail.com, me@eshelyaron.com, > 73862@debbugs.gnu.org > > Would it make sense to extend the face doc strings that should not use > inheritance to indicate that? > > I'm not sure. Inheritance does work for the basic faces, it's just that > face-remapping doesn't get passed by inheritance. > Yeah, I guess that'd be throwing the baby out with the bathwater. I retract. Another possibility would be to issue a warning when attempting to remap mode-line or header-line. The user would at least see that what they're doing is fraught. I believe this would require reconciling the terminal vs GUI difference for mode-line you mentioned earlier. This would still be adding specialization in a generalized place, and arguably that's a worse place to do it than where you added it in your patch, so feel free to disregard that idea. Thanks, Aaron --000000000000d9674f0628b391c5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Dec 07, 2024 at 11:19 AM, Eli Zaretskii <eliz@gnu.org> wrote:
<= div class=3D"sh-quoted-content">
=

From: Aaron Jensen <aaronjensen@gmail.c= om>
Date: Sat, 7 Dec 202= 4 14:06:35 -0500
Cc: monnier@iro.umontreal.ca, = trevor.m.murphy@gmail.com, me@eshelyaron.com,=20 73862@debbugs.gnu.org

Would it make sense to extend the face doc strings that should not use inheritance to indicate that?

I'm not sure. Inheritance does work for the basic faces, it's just that face-remapping doesn't get passed by inheritance.


Yeah, I gu= ess that'd be throwing the baby out with the bathwater. I retract.
<= /div>

Another possibility would be to issue a warning wh= en attempting=C2=A0to remap mode-line or header-line. The user would at lea= st see that what they're doing is fraught. I believe this would require= reconciling the terminal vs GUI difference for mode-line you mentioned ear= lier. This would still be adding specialization in a generalized place, and= arguably that's a worse place to do it than where you added it in your= patch, so feel free to disregard that idea.

T= hanks,

Aaron

<= div>
--000000000000d9674f0628b391c5-- From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 08 09:11:14 2024 Received: (at 73862) by debbugs.gnu.org; 8 Dec 2024 14:11:14 +0000 Received: from localhost ([127.0.0.1]:50116 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tKI09-0003DC-HG for submit@debbugs.gnu.org; Sun, 08 Dec 2024 09:11:13 -0500 Received: from mail.eshelyaron.com ([107.175.124.16]:46646 helo=eshelyaron.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tKI06-0003D2-JL for 73862@debbugs.gnu.org; Sun, 08 Dec 2024 09:11:11 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eshelyaron.com; s=mail; t=1733667070; bh=+I1UU7G7GEpOe2WFxpojsJy2KTpnElphP21XWLEG5TM=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=YyvcwJv+q1H9j7jrcnUpoeNtnjFjubWCgf4AYIq4Z2JUp57uLcHSEU05O8MtIRmFi vxamzM7J0Nx8h9dbBS+1uCAKwRzXtueU4k4OX/c+TEPJ9GrltfygjMNWGYRitwf5Vr +iDlpIBUA110AoLuFUaaS9CdTrLlBc55rhY6jefnagI8CmfodsF+DcRfr1PmX5Aa8W l8D1r/TK7dsan3T2CwkzJYwjtQ4AKystUqzqN7gvsusckPK27Sx877PB2XqHL8esN0 oxnb984PP8V8cwOtuTHWAuO62d1cnh7d/AlDeVnB/nzDUoPhOcsBHbMI6YGHMK+Z6f AR7vzXlLUm2WQ== From: Eshel Yaron To: Eli Zaretskii Subject: Re: bug#73862: [PATCH] Add `header-line-active` and `header-line-inactive` faces. In-Reply-To: <86r06jgv1j.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 07 Dec 2024 21:19:52 +0200") References: <86wmgfzhgc.fsf@gnu.org> <86zflay7hh.fsf@gnu.org> <86jzcey3cu.fsf@gnu.org> <8634j1n9nx.fsf@gnu.org> <86ldwrkeiy.fsf@gnu.org> <865xnviliv.fsf@gnu.org> <86wmgbgxjx.fsf@gnu.org> <86ttbfgvyr.fsf@gnu.org> <86r06jgv1j.fsf@gnu.org> Date: Sun, 08 Dec 2024 15:11:07 +0100 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 73862 Cc: trevor.m.murphy@gmail.com, monnier@iro.umontreal.ca, Aaron Jensen , 73862@debbugs.gnu.org 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.0 (-) Hi, Eli Zaretskii writes: >> From: Aaron Jensen >> Date: Sat, 7 Dec 2024 14:06:35 -0500 >> Cc: monnier@iro.umontreal.ca, trevor.m.murphy@gmail.com, me@eshelyaron.com, >> 73862@debbugs.gnu.org >> >> Would it make sense to extend the face doc strings that should not use >> inheritance to indicate that? > > I'm not sure. Inheritance does work for the basic faces, it's just > that face-remapping doesn't get passed by inheritance. > >> Alternatively, if there were a path to deprecating header-line and >> mode-line then the compatibility fix could be skipped. > > Let's see what Stefan and others think about this. > > We also haven't yet heard from Eshel. I don't have any concrete suggestions at this point. It's surely a complicated situation. The workaround of remapping both header-line-active and header-line-inactive instead of header-line seems to work. The way I see it, the essence of the issue is that the "face" abstraction is leaky, in the sense that some faces (these "basic faces") behave differently from other faces in some cases that involve inheritance and remapping. I think this calls for either changing the way basic faces are handled so they do behave like any other face, or clearly documenting their subtleties. Eshel From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 08 09:57:42 2024 Received: (at 73862) by debbugs.gnu.org; 8 Dec 2024 14:57:42 +0000 Received: from localhost ([127.0.0.1]:51365 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tKIj7-0005qc-QT for submit@debbugs.gnu.org; Sun, 08 Dec 2024 09:57:42 -0500 Received: from eggs.gnu.org ([209.51.188.92]:50012) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tKIj5-0005qL-5R for 73862@debbugs.gnu.org; Sun, 08 Dec 2024 09:57:39 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tKIiy-0006ze-Oe; Sun, 08 Dec 2024 09:57:33 -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=RyX/nnAMeIxVirvlrUpF+Dy0onvTzqSrVo14z6ZgoHU=; b=amGxBipxT8Yk lNwnnjo5oHG6AnqEcNgQS51zEXAe9kTdfoCO6oigJw+8tIciOcDZSc7XBJgzBFw/qWfZah1AY5co1 ArFlIc/pVYwJ5lD11QeXPIttVEkDR/WNO89YTyxXEvu6W35ORwgqMyrEOJzhK7hwM/SSrKvywSfCi w6Tsn1KvsG9/xxguYdx9zFV/Q3lT2BIQNvWK6CkOSMhs3blRKw/s9dbogpVoU3DDGppC451twwHa0 1Ig3j2RI7vQIJiFA8K81vYrClTIXu8iy/DL4BrZA+wm8+w2mxCly2HcOtNwyfEkZCSwaS6kiJToZU 3V3LWYO9ZR5iSpqg/DZb0g==; Date: Sun, 08 Dec 2024 16:57:17 +0200 Message-Id: <86jzcafcj6.fsf@gnu.org> From: Eli Zaretskii To: Eshel Yaron In-Reply-To: (message from Eshel Yaron on Sun, 08 Dec 2024 15:11:07 +0100) Subject: Re: bug#73862: [PATCH] Add `header-line-active` and `header-line-inactive` faces. References: <86wmgfzhgc.fsf@gnu.org> <86zflay7hh.fsf@gnu.org> <86jzcey3cu.fsf@gnu.org> <8634j1n9nx.fsf@gnu.org> <86ldwrkeiy.fsf@gnu.org> <865xnviliv.fsf@gnu.org> <86wmgbgxjx.fsf@gnu.org> <86ttbfgvyr.fsf@gnu.org> <86r06jgv1j.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 73862 Cc: trevor.m.murphy@gmail.com, monnier@iro.umontreal.ca, aaronjensen@gmail.com, 73862@debbugs.gnu.org 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: Eshel Yaron > Cc: Aaron Jensen , monnier@iro.umontreal.ca, > trevor.m.murphy@gmail.com, 73862@debbugs.gnu.org > Date: Sun, 08 Dec 2024 15:11:07 +0100 > > Eli Zaretskii writes: > > > We also haven't yet heard from Eshel. > > I don't have any concrete suggestions at this point. It's surely a > complicated situation. Did you try the patch I posted, and if you did, did it resolve your original problems? That's what I wanted to hear, since you were one of the two persons who raised these issues. > The workaround of remapping both header-line-active and > header-line-inactive instead of header-line seems to work. The way I > see it, the essence of the issue is that the "face" abstraction is > leaky, in the sense that some faces (these "basic faces") behave > differently from other faces in some cases that involve inheritance and > remapping. AFAIK, only face-remapping behaves differently, and only when a basic face inherits from another. The inheritance itself work as with other faces. > I think this calls for either changing the way basic faces are > handled so they do behave like any other face, or clearly > documenting their subtleties. Patches to rework the faces support so that these idiosyncrasies are removed will be most welcome. I just don't plan on doing that myself, as I won't have time for that. TIA From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 08 11:29:10 2024 Received: (at 73862) by debbugs.gnu.org; 8 Dec 2024 16:29:10 +0000 Received: from localhost ([127.0.0.1]:51477 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tKK9e-0001vC-Ey for submit@debbugs.gnu.org; Sun, 08 Dec 2024 11:29:10 -0500 Received: from mail.eshelyaron.com ([107.175.124.16]:51986 helo=eshelyaron.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tKK9c-0001v3-9p for 73862@debbugs.gnu.org; Sun, 08 Dec 2024 11:29:09 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eshelyaron.com; s=mail; t=1733675347; bh=Na//p+gBAbbhTCXnMrcFmUJbM+6HCS7wFJ25cx+L9DQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=hcq7YQm+dM5lBrjHHaSFRbOMJV6AKHOFWRLM6HOAvLdGCGorbqEQ8H49Y6qPk64P7 HXJFKu/RFwiF0ktxqglhY6Y8kQB7Y6PwN5WmuCtv1H/b8SznOoAE8mBZpOG5Vb8/Kh NmJnIxirdG7RUWHKrJgDbANJeCAB7roSRe8rkbtAGNVzV8ysRLd4Pr8glN2mknAP24 xEiabJqRZhsbsRVinJYp3PfqqBjt2oEAXTClGkgZ7dfHgU30fE+DofWRIe/dhz/tFk +7iBvrWpBsUuf9o6J7WYmXiysZJZL9wrPgEuIJeXU0Z8bHYHN59C4PjCxBCPTduDXL +GeAQLp4pnMag== From: Eshel Yaron To: Eli Zaretskii Subject: Re: bug#73862: [PATCH] Add `header-line-active` and `header-line-inactive` faces. In-Reply-To: <86jzcafcj6.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 08 Dec 2024 16:57:17 +0200") References: <86wmgfzhgc.fsf@gnu.org> <86zflay7hh.fsf@gnu.org> <86jzcey3cu.fsf@gnu.org> <8634j1n9nx.fsf@gnu.org> <86ldwrkeiy.fsf@gnu.org> <865xnviliv.fsf@gnu.org> <86wmgbgxjx.fsf@gnu.org> <86ttbfgvyr.fsf@gnu.org> <86r06jgv1j.fsf@gnu.org> <86jzcafcj6.fsf@gnu.org> Date: Sun, 08 Dec 2024 17:29:04 +0100 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 73862 Cc: trevor.m.murphy@gmail.com, monnier@iro.umontreal.ca, aaronjensen@gmail.com, 73862@debbugs.gnu.org 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.0 (-) Eli Zaretskii writes: >> From: Eshel Yaron >> Cc: Aaron Jensen , monnier@iro.umontreal.ca, >> trevor.m.murphy@gmail.com, 73862@debbugs.gnu.org >> Date: Sun, 08 Dec 2024 15:11:07 +0100 >> >> Eli Zaretskii writes: >> >> > We also haven't yet heard from Eshel. >> >> I don't have any concrete suggestions at this point. It's surely a >> complicated situation. > > Did you try the patch I posted, and if you did, did it resolve your > original problems? I did now, and it doesn't entirely solve the problem: with this patch, after remapping header-line in one buffer, the remapping now works for that buffer as expected, but it still also "spreads" to other buffers, which is unexpected. From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 08 12:27:39 2024 Received: (at 73862) by debbugs.gnu.org; 8 Dec 2024 17:27:40 +0000 Received: from localhost ([127.0.0.1]:51559 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tKL4F-0004nq-DA for submit@debbugs.gnu.org; Sun, 08 Dec 2024 12:27:39 -0500 Received: from mail-lj1-f175.google.com ([209.85.208.175]:46377) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tKL4C-0004nZ-7F for 73862@debbugs.gnu.org; Sun, 08 Dec 2024 12:27:37 -0500 Received: by mail-lj1-f175.google.com with SMTP id 38308e7fff4ca-30167f4c1deso8346381fa.1 for <73862@debbugs.gnu.org>; Sun, 08 Dec 2024 09:27:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1733678790; x=1734283590; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:references:in-reply-to:from :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=yjXsa502WmPdzQIocXgpb2DG0FaIawr9TxmbCZZgWeg=; b=gtjYqgsJBI2m0RtlO1GojZb66IFyp/MuAokMQQCusMTLeq+Y59RFpXuPLr6SA66I3k p6FB5WikHTruB9w2YQ6lD1BPndfdiLyLVEjo92fy8gdc0Rbubwt3Ur+e0+8MKitu+vT/ b9QE0ly4Qg3Qa5RoaHmWdwzML5DxeS+XqHXAXp4t8Mhe8MuYfZmRIWX7UC9AUDGLWzhg 9A59rblyrIO7raDIX2D3xBnmtvArHb2KOnnVc0896+0DkU01Vzo2RLtraKjFMpDi5dL5 iHNntFHVkii3mPY7BPkX0goaNe3MWg4594iEMq0cjv1wHjnmbsRuZ20dXuFfuYx3wHG6 bfvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733678790; x=1734283590; h=cc:to:subject:message-id:date:references:in-reply-to:from :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=yjXsa502WmPdzQIocXgpb2DG0FaIawr9TxmbCZZgWeg=; b=U8vOBM+j99ay4+DC4M5KE65p3E2Vj3LoNiQILBCcDg0PJE1wJWUwEEeUsHFfhlRaSe LpHPkMN12zl7oGL52QSAlhTw7RBKFoFFw3SZay7j2q2tdHPmKIIapmYcvQyZcNPk7lp/ +GBDKEXUXjDLrKJA0SXZF3ZV57SW7Em8xwnfA/vvExchwJz+kro71qNQ9j7jXj1yj6ac Q25eDpyFakpMibu5DvssIDi6RmmmyIUFasEv2tJ6vrUKRKUGnGTRU9fG/KO4UmLL5DtD zc++Wpmo9U9+Ta1pJ6u8w5CJu5lWjeoP26Z2UvBIxLUActcruK8vsmSK0aFrEKG3j5FG B4Dw== X-Forwarded-Encrypted: i=1; AJvYcCVD3gl2VQoWjScB3g7l8xJCke8fiakxeb2ABWKMlNwLKX5Tw9zXU26JXcHC/yXjsWCBR6Nvzg==@debbugs.gnu.org X-Gm-Message-State: AOJu0YwEahh4SFxWJmMuH3IwzqTD90kFoCkJsY+nE2HGNI8bGfdPJWoS 5DPN2ikYhAjnbo7tpdkmocdQ6nKlTyrpBS8u0V9O5pulMDzKTZbJP1x1lVJACs1LtnWVtOTdbZq agTVJ7VHCWlKlInLc6BguuT46NeE= X-Gm-Gg: ASbGnctcwoWl/tGOPbmDbf4yv15fCQ/Gamt+RMi90gIv9xzwOalORRvVa7hbQdfcDTG I3yXyQKQDbkLC278ilALOMLnMOm11hEscROP5ObyLNGolF8zaLnE3BT8= X-Google-Smtp-Source: AGHT+IFjVCEztWaSTHCmeN3ESpmiFCqd23RVaghghnTYyID/2Sbe6B7csz873aRjc7jZJMr+FqZBGORV/pZZkg4bjoQ= X-Received: by 2002:a2e:86da:0:b0:302:2620:ec89 with SMTP id 38308e7fff4ca-3022620ef1dmr408001fa.19.1733678789914; Sun, 08 Dec 2024 09:26:29 -0800 (PST) Received: from 649336022844 named unknown by gmailapi.google.com with HTTPREST; Sun, 8 Dec 2024 12:26:29 -0500 Mime-Version: 1.0 X-Mailer: Superhuman Desktop (2024-12-06T20:05:50Z) X-Superhuman-ID: m4fvkqnr.f9edd5a9-f0f4-491b-ac2b-afadc3a523ab From: Aaron Jensen X-Superhuman-Draft-ID: draft001c139085d92c11 In-Reply-To: References: <86wmgfzhgc.fsf@gnu.org> <86zflay7hh.fsf@gnu.org> <86jzcey3cu.fsf@gnu.org> <8634j1n9nx.fsf@gnu.org> <86ldwrkeiy.fsf@gnu.org> <865xnviliv.fsf@gnu.org> <86wmgbgxjx.fsf@gnu.org> <86ttbfgvyr.fsf@gnu.org> <86r06jgv1j.fsf@gnu.org> <86jzcafcj6.fsf@gnu.org> Date: Sun, 8 Dec 2024 12:26:29 -0500 Message-ID: Subject: Re: bug#73862: [PATCH] Add `header-line-active` and `header-line-inactive` faces. To: Eshel Yaron Content-Type: multipart/alternative; boundary="0000000000006d781e0628c58c92" X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 73862 Cc: trevor.m.murphy@gmail.com, Eli Zaretskii , monnier@iro.umontreal.ca, 73862@debbugs.gnu.org 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.0 (-) --0000000000006d781e0628c58c92 Content-Type: text/plain; charset="UTF-8" On Sun, Dec 08, 2024 at 8:29 AM, Eshel Yaron wrote: > Eli Zaretskii writes: > > From: Eshel Yaron > Cc: Aaron Jensen , monnier@iro.umontreal.ca, > trevor.m.murphy@gmail.com, 73862@debbugs.gnu.org > Date: Sun, 08 Dec 2024 15:11:07 +0100 > > Eli Zaretskii writes: > > We also haven't yet heard from Eshel. > > I don't have any concrete suggestions at this point. It's surely a > complicated situation. > > Did you try the patch I posted, and if you did, did it resolve your > original problems? > > I did now, and it doesn't entirely solve the problem: with this patch, > after remapping header-line in one buffer, the remapping now works for that > buffer as expected, but it still also "spreads" to other buffers, which is > unexpected. > I see the leak now as well. When I tested it at first, I did not see it perhaps because I did not switch back to the original window and trigger a computation of the basic faces. That's what causes the leak. Steps: (setq header-line-format "Some header") (face-remap-set-base 'header-line 'highlight) (switch-to-buffer-other-window "new") ;; In new buffer/window: (setq header-line-format "Some header") (other-window) ;; In original buffer/window: (set-face-attribute 'default nil :height (+ (face-attribute 'default :height) 10)) Aaron --0000000000006d781e0628c58c92 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Dec 08, 2024 at 8:29 AM, Eshel Yaron <= /span><me@eshelyaron.com> wrote= :

Eli Zaretskii <= ;eliz@gnu.org> writes:

From: Eshel Yaron <me@eshelyaron.com>= ;
Cc: Aaron Jensen <aaronjensen@gmail.co= m>, monnier@iro.umontreal.= ca, trevor.m.murphy@gmail.com, 73862@debbugs.gnu.org
Date: Sun, 08 Dec 20= 24 15:11:07 +0100

Eli Zaretskii <eliz@gnu.org> writes:

We also haven't yet heard from Eshel.

I don't have any concrete suggestions at this point. It's surely a complicated situation.

Did you try the patch I posted, and if you did, did it resolve your original problems? =20

I did now, and it doesn't entirely solve the problem: with this patch, after remapping header-line in one buffer, the remapping now works for that buffer as expected, but it still also "spreads" to other buf= fers, which is unexpected.


I see the leak = now as well. When I tested it at first, I did not see it perhaps because I = did not switch back to the original window and trigger a computation=C2=A0o= f the basic faces. That's what causes the leak.

Steps:

(setq header-line-format "Some header")
(face-remap-set-base 'header-line 'highlight)
<= /div>
(switch-to-buffer-other-window "new")
;; In new buffer/window:
(setq header-line-format "Some header")
(other-window)
;; In original buffer/w= indow:
(set-face-attribute 'default nil :height (+ (face-attr= ibute 'default :height) 10))

Aaron
--0000000000006d781e0628c58c92-- From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 08 12:39:33 2024 Received: (at 73862) by debbugs.gnu.org; 8 Dec 2024 17:39:33 +0000 Received: from localhost ([127.0.0.1]:51595 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tKLFl-0005NQ-2b for submit@debbugs.gnu.org; Sun, 08 Dec 2024 12:39:33 -0500 Received: from eggs.gnu.org ([209.51.188.92]:47078) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tKLFj-0005NA-3c for 73862@debbugs.gnu.org; Sun, 08 Dec 2024 12:39:31 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tKLFd-0008AB-BC; Sun, 08 Dec 2024 12:39:25 -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=vXglKDNJkkBV31qyfO38QxRUetmbR1KO2GtwUC9BSZE=; b=rpHRFqbjXHUU HUOgT2tz2ShEZ6A/pvEWokOP/cZaRMMKVIwzq8d1NpchsVz7x7Shhe6fmaWy0Tzzbr5b5PVIxhaNi DjhJWAzsaVurLiu9Uecs1ktApRFXxRO8QLXwRwTTanLfYbImwrfzx6KVMOCmIqvxTge9Uo5VBQDyO ZKjGAzk9K43IQ3LJtwrYfy23Z9LYGafsZUzkJUcIcy9BU7MJUz8E3JuSvD+i0PT1DrnvHkDnUwbZk +ZatDObjfYfwSHzxjjktLHY1P6jWIpKs3ZFVfjYWp87vXDySr0FXvumqlEF22tYXlWuDInDyrS6bz mxVjxmDkfcq4czy2Mu3zgQ==; Date: Sun, 08 Dec 2024 19:39:19 +0200 Message-Id: <867c8af514.fsf@gnu.org> From: Eli Zaretskii To: Eshel Yaron In-Reply-To: (message from Eshel Yaron on Sun, 08 Dec 2024 17:29:04 +0100) Subject: Re: bug#73862: [PATCH] Add `header-line-active` and `header-line-inactive` faces. References: <86wmgfzhgc.fsf@gnu.org> <86zflay7hh.fsf@gnu.org> <86jzcey3cu.fsf@gnu.org> <8634j1n9nx.fsf@gnu.org> <86ldwrkeiy.fsf@gnu.org> <865xnviliv.fsf@gnu.org> <86wmgbgxjx.fsf@gnu.org> <86ttbfgvyr.fsf@gnu.org> <86r06jgv1j.fsf@gnu.org> <86jzcafcj6.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 73862 Cc: trevor.m.murphy@gmail.com, monnier@iro.umontreal.ca, aaronjensen@gmail.com, 73862@debbugs.gnu.org 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: Eshel Yaron > Cc: aaronjensen@gmail.com, monnier@iro.umontreal.ca, > trevor.m.murphy@gmail.com, 73862@debbugs.gnu.org > Date: Sun, 08 Dec 2024 17:29:04 +0100 > > Eli Zaretskii writes: > > >> From: Eshel Yaron > >> Cc: Aaron Jensen , monnier@iro.umontreal.ca, > >> trevor.m.murphy@gmail.com, 73862@debbugs.gnu.org > >> Date: Sun, 08 Dec 2024 15:11:07 +0100 > >> > >> Eli Zaretskii writes: > >> > >> > We also haven't yet heard from Eshel. > >> > >> I don't have any concrete suggestions at this point. It's surely a > >> complicated situation. > > > > Did you try the patch I posted, and if you did, did it resolve your > > original problems? > > I did now, and it doesn't entirely solve the problem: with this patch, > after remapping header-line in one buffer, the remapping now works for > that buffer as expected, but it still also "spreads" to other buffers, > which is unexpected. What do you mean by "spreads to other buffers"? When you remapped header-line face before this change on master, did it behave differently, and if so, how? From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 08 15:56:39 2024 Received: (at 73862) by debbugs.gnu.org; 8 Dec 2024 20:56:39 +0000 Received: from localhost ([127.0.0.1]:51852 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tKOKU-0006qK-Kn for submit@debbugs.gnu.org; Sun, 08 Dec 2024 15:56:39 -0500 Received: from mail.eshelyaron.com ([107.175.124.16]:58968 helo=eshelyaron.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tKOKS-0006qC-HI for 73862@debbugs.gnu.org; Sun, 08 Dec 2024 15:56:37 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eshelyaron.com; s=mail; t=1733691396; bh=1Z60hxz7jgRkRuwGF5CugAkESuggacu1atWylabdBZI=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=ONj9tqA4AWX+C+7Uy1CeuUpmrk5Irkw0qpeiPWT9ihqO6MbFfFElKtxW8jA/qK+R9 uIYZIb4TWqrnzI3A5bc8xKokEOqDqemhp9QeSCDNOhud1bAs528Fd9UMUM7MZDqx+w roDC8setgtbM0FmiHhuznRluBi+x6R/uRxzJlwmBV36XtnH0GrNwdLcKMCFqYEyTvM fte9LWiPERqwDPSmzNtc2/hL448zwGtnsIk2zD5ZaT5yWPiqJeGvZZjEC2ZCZK9w8r rXX8JbOITB6rGwRv4kT9AuoJMQmVvZ/SatIohpnLpL0zAdpUCu7NlumgHB8ZSxG1Qh LN7vxWSwdGWqg== From: Eshel Yaron To: Eli Zaretskii Subject: Re: bug#73862: [PATCH] Add `header-line-active` and `header-line-inactive` faces. In-Reply-To: <867c8af514.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 08 Dec 2024 19:39:19 +0200") References: <86zflay7hh.fsf@gnu.org> <86jzcey3cu.fsf@gnu.org> <8634j1n9nx.fsf@gnu.org> <86ldwrkeiy.fsf@gnu.org> <865xnviliv.fsf@gnu.org> <86wmgbgxjx.fsf@gnu.org> <86ttbfgvyr.fsf@gnu.org> <86r06jgv1j.fsf@gnu.org> <86jzcafcj6.fsf@gnu.org> <867c8af514.fsf@gnu.org> Date: Sun, 08 Dec 2024 21:56:33 +0100 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 73862 Cc: trevor.m.murphy@gmail.com, monnier@iro.umontreal.ca, aaronjensen@gmail.com, 73862@debbugs.gnu.org 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.0 (-) Hi, Eli Zaretskii writes: >> From: Eshel Yaron >> Cc: aaronjensen@gmail.com, monnier@iro.umontreal.ca, >> trevor.m.murphy@gmail.com, 73862@debbugs.gnu.org >> Date: Sun, 08 Dec 2024 17:29:04 +0100 >> >> Eli Zaretskii writes: >> >> > Did you try the patch I posted, and if you did, did it resolve your >> > original problems? >> >> I did now, and it doesn't entirely solve the problem: with this patch, >> after remapping header-line in one buffer, the remapping now works for >> that buffer as expected, but it still also "spreads" to other buffers, >> which is unexpected. > > What do you mean by "spreads to other buffers"? When you remapped > header-line face before this change on master, did it behave > differently, and if so, how? Yes, before the introduction of header-line-(in)active, remapping header-line buffer-locally in buffer A with face-remap-add-relative would only affect the appearance of the header line in windows that show buffer A. Now, with this change and your patch, doing so can also affect header lines in other windows, that display other buffers. Aaron shared a recipe to reproduce this behavior, copied here: --8<---------------cut here---------------start------------->8--- (setq header-line-format "Some header") (face-remap-set-base 'header-line 'highlight) (switch-to-buffer-other-window "new") ;; In new buffer/window: (setq header-line-format "Some header") (other-window 1) ;; In original buffer/window: (set-face-attribute 'default nil :height (+ (face-attribute 'default :height) 10)) --8<---------------cut here---------------end--------------->8--- Eshel From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 08 22:28:56 2024 Received: (at 73862) by debbugs.gnu.org; 9 Dec 2024 03:28:56 +0000 Received: from localhost ([127.0.0.1]:52405 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tKUS7-0001Bj-Nl for submit@debbugs.gnu.org; Sun, 08 Dec 2024 22:28:56 -0500 Received: from eggs.gnu.org ([209.51.188.92]:46000) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tKUS4-0001BS-S1 for 73862@debbugs.gnu.org; Sun, 08 Dec 2024 22:28:53 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tKUPs-0003KY-VO; Sun, 08 Dec 2024 22:26:37 -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=UYMdJXypanvDUgS9auqpzXoMcgtD8W+7gp9+rQteJCE=; b=gAe8tpwhU8+A oTLiL47QeG4+WelJHNXPYVrWdSjQkhRG85xoucPsiz9e5Nabsb+TLDkPJTI41ryN8LCXRo5dXIwnq Eeu2GzQ3jy1XjvNIijcffm8CEUso4GjQJAJNsqlQW9m+icXFtgsgWEZmO0QS7CFANjDcoBjPsJSFj dkdeJLSVjY1MLlbpUUX4CMlphVH3ttMbPUsw/2p4DzlFlxf3v+wygl+RL9ATt0ctjaLsqo3/sOie/ zqWIoZLj4mhxSibI+yqZ+pkn8FCMq4PJBKPJ8mmTa+IMcgj350hpg7wYuEGKYZfeOn3KQa0QqSkZb Lr1iw0hmfwSFzSMFdLFW2A==; Date: Mon, 09 Dec 2024 05:26:34 +0200 Message-Id: <86ldwpedud.fsf@gnu.org> From: Eli Zaretskii To: Eshel Yaron In-Reply-To: (message from Eshel Yaron on Sun, 08 Dec 2024 21:56:33 +0100) Subject: Re: bug#73862: [PATCH] Add `header-line-active` and `header-line-inactive` faces. References: <86zflay7hh.fsf@gnu.org> <86jzcey3cu.fsf@gnu.org> <8634j1n9nx.fsf@gnu.org> <86ldwrkeiy.fsf@gnu.org> <865xnviliv.fsf@gnu.org> <86wmgbgxjx.fsf@gnu.org> <86ttbfgvyr.fsf@gnu.org> <86r06jgv1j.fsf@gnu.org> <86jzcafcj6.fsf@gnu.org> <867c8af514.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 73862 Cc: trevor.m.murphy@gmail.com, monnier@iro.umontreal.ca, aaronjensen@gmail.com, 73862@debbugs.gnu.org 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: Eshel Yaron > Cc: trevor.m.murphy@gmail.com, monnier@iro.umontreal.ca, > aaronjensen@gmail.com, 73862@debbugs.gnu.org > Date: Sun, 08 Dec 2024 21:56:33 +0100 > > Aaron shared a recipe to reproduce this behavior, copied here: > > --8<---------------cut here---------------start------------->8--- > (setq header-line-format "Some header") > (face-remap-set-base 'header-line 'highlight) > (switch-to-buffer-other-window "new") > ;; In new buffer/window: > (setq header-line-format "Some header") > (other-window 1) > ;; In original buffer/window: > (set-face-attribute 'default nil :height (+ (face-attribute 'default :height) 10)) > --8<---------------cut here---------------end--------------->8--- Are you also change the attributes of the default face to cause the "spreading"? If not, please show a recipe. Because I was unable to see this without something like the last line of the recipe, and also that line _must_ be in the buffer where header-line is remapped, otherwise the effect is not seen. From debbugs-submit-bounces@debbugs.gnu.org Mon Dec 09 03:56:12 2024 Received: (at 73862) by debbugs.gnu.org; 9 Dec 2024 08:56:12 +0000 Received: from localhost ([127.0.0.1]:52842 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tKZYq-000060-F0 for submit@debbugs.gnu.org; Mon, 09 Dec 2024 03:56:12 -0500 Received: from mail.eshelyaron.com ([107.175.124.16]:57730 helo=eshelyaron.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tKZYn-00005r-QY for 73862@debbugs.gnu.org; Mon, 09 Dec 2024 03:56:10 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eshelyaron.com; s=mail; t=1733734569; bh=Co2FOm84dgWVdT2T1owBjlheiYRh4sw+cx7GXcOF5lo=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=n1qHverL/xWnXWA6VS6pLejiwWeUELYINTTRnGADL9XJpAbijGqWLRhhv2VGSPL6G hnv9k16pWZir7VdyXj1jZ5avSBay/kPGGlYXdTp4OY7hdHsvFu/1U2XXf3JVcMXlt+ 3stUvHR8lxHp3SdYK7NUWVRB7UpFJRdqXZF5G/c+ykFNzn13Gph4KuvDBxd1BHbnci J6wpcjPznE5QX0KljAsKhk5EH0T1j0yqiMkwupfqgcuBZW2g4LGE1NzW5t9dSf8X8H onHxZA30YNEy6pt/FMg6UBnBsiY8/g036S6tM/0MbkmVTBIEt/rHyZTtR6CY9r1UI0 Sl9kw2cChFrqg== From: Eshel Yaron To: Eli Zaretskii Subject: Re: bug#73862: [PATCH] Add `header-line-active` and `header-line-inactive` faces. In-Reply-To: <86ldwpedud.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 09 Dec 2024 05:26:34 +0200") References: <86jzcey3cu.fsf@gnu.org> <8634j1n9nx.fsf@gnu.org> <86ldwrkeiy.fsf@gnu.org> <865xnviliv.fsf@gnu.org> <86wmgbgxjx.fsf@gnu.org> <86ttbfgvyr.fsf@gnu.org> <86r06jgv1j.fsf@gnu.org> <86jzcafcj6.fsf@gnu.org> <867c8af514.fsf@gnu.org> <86ldwpedud.fsf@gnu.org> Date: Mon, 09 Dec 2024 09:56:06 +0100 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 73862 Cc: trevor.m.murphy@gmail.com, monnier@iro.umontreal.ca, aaronjensen@gmail.com, 73862@debbugs.gnu.org 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.0 (-) Hi, Eli Zaretskii writes: >> From: Eshel Yaron >> Cc: trevor.m.murphy@gmail.com, monnier@iro.umontreal.ca, >> aaronjensen@gmail.com, 73862@debbugs.gnu.org >> Date: Sun, 08 Dec 2024 21:56:33 +0100 >> >> Aaron shared a recipe to reproduce this behavior, copied here: >> >> --8<---------------cut here---------------start------------->8--- >> (setq header-line-format "Some header") >> (face-remap-set-base 'header-line 'highlight) >> (switch-to-buffer-other-window "new") >> ;; In new buffer/window: >> (setq header-line-format "Some header") >> (other-window 1) >> ;; In original buffer/window: >> (set-face-attribute 'default nil :height (+ (face-attribute 'default :height) 10)) >> --8<---------------cut here---------------end--------------->8--- > > Are you also change the attributes of the default face to cause the > "spreading"? If not, please show a recipe. Because I was unable to > see this without something like the last line of the recipe, and also > that line _must_ be in the buffer where header-line is remapped, > otherwise the effect is not seen. Yes, I used C-x C-M-= in the buffer in which I remapped header-line. From debbugs-submit-bounces@debbugs.gnu.org Sat Dec 14 04:45:51 2024 Received: (at 73862) by debbugs.gnu.org; 14 Dec 2024 09:45:51 +0000 Received: from localhost ([127.0.0.1]:45503 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tMOid-0007Ce-Bf for submit@debbugs.gnu.org; Sat, 14 Dec 2024 04:45:51 -0500 Received: from mail.eshelyaron.com ([107.175.124.16]:38964 helo=eshelyaron.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tMOib-0007CU-Ge for 73862@debbugs.gnu.org; Sat, 14 Dec 2024 04:45:50 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eshelyaron.com; s=mail; t=1734169549; bh=z3hxeg10U759d+uCHAf187gfkkKkbPnkJ81V0Js2/gg=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=f/wJNM2cMx9nd8t1pCBH8uG4tRS+kWCuQ4NI+lf2mlvwJViz6pGT1LZyoVRzNBCmM eVlLvPGbxzMNmR1HIlHPhfFr/uJ65BWNYagQksUaz911lXM9XxZBmTWGdlO5baaAw8 pVcAkM3wjM5OUTbM3pfAP/ND9imCGm9Bz+wPjRgbfXYMUpwCE7lHMZ7Jgg0e6kAHdO wy2WcBeH9mkiiYyBQN0R03JIoy2reHr87vX0KHeCgW7nVJQQ4EpWayu+3zX6i3Pt41 7InLGkGQtVQeSogi54FWVfUZZLvQ626mIsoDm7mzSsorBfRQm+5VFpzFA/UcfiRlMK 8EkLoUF5Ct0fQ== From: Eshel Yaron To: Eshel Yaron via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Subject: Re: bug#73862: [PATCH] Add `header-line-active` and `header-line-inactive` faces. In-Reply-To: (Eshel Yaron via's message of "Mon, 09 Dec 2024 09:56:06 +0100") References: <86jzcey3cu.fsf@gnu.org> <8634j1n9nx.fsf@gnu.org> <86ldwrkeiy.fsf@gnu.org> <865xnviliv.fsf@gnu.org> <86wmgbgxjx.fsf@gnu.org> <86ttbfgvyr.fsf@gnu.org> <86r06jgv1j.fsf@gnu.org> <86jzcafcj6.fsf@gnu.org> <867c8af514.fsf@gnu.org> <86ldwpedud.fsf@gnu.org> Date: Sat, 14 Dec 2024 10:45:45 +0100 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 73862 Cc: trevor.m.murphy@gmail.com, Ihor Radchenko , 73862@debbugs.gnu.org, aaronjensen@gmail.com, monnier@iro.umontreal.ca, Eli Zaretskii 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.0 (-) Eshel Yaron writes: > Hi, > > Eli Zaretskii writes: > >>> From: Eshel Yaron >>> Cc: trevor.m.murphy@gmail.com, monnier@iro.umontreal.ca, >>> aaronjensen@gmail.com, 73862@debbugs.gnu.org >>> Date: Sun, 08 Dec 2024 21:56:33 +0100 >>> >>> Aaron shared a recipe to reproduce this behavior, copied here: >>> >>> --8<---------------cut here---------------start------------->8--- >>> (setq header-line-format "Some header") >>> (face-remap-set-base 'header-line 'highlight) >>> (switch-to-buffer-other-window "new") >>> ;; In new buffer/window: >>> (setq header-line-format "Some header") >>> (other-window 1) >>> ;; In original buffer/window: >>> (set-face-attribute 'default nil :height (+ (face-attribute 'default :height) 10)) >>> --8<---------------cut here---------------end--------------->8--- >> >> Are you also change the attributes of the default face to cause the >> "spreading"? If not, please show a recipe. Because I was unable to >> see this without something like the last line of the recipe, and also >> that line _must_ be in the buffer where header-line is remapped, >> otherwise the effect is not seen. > > Yes, I used C-x C-M-= in the buffer in which I remapped header-line. Note that this issue also affects Org: org-columns remaps header-line in org-columns--display-here. (CC'ing Ihor.) Best, Eshel From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 22 10:53:09 2024 Received: (at 73862) by debbugs.gnu.org; 22 Dec 2024 15:53:09 +0000 Received: from localhost ([127.0.0.1]:51519 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tPOGS-00038X-MG for submit@debbugs.gnu.org; Sun, 22 Dec 2024 10:53:09 -0500 Received: from eggs.gnu.org ([209.51.188.92]:38996) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tPOGO-00037y-Ml for 73862@debbugs.gnu.org; Sun, 22 Dec 2024 10:53:07 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tPOGI-0007DP-Sr; Sun, 22 Dec 2024 10:52: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=VHt9XlipKvkRbNqpzUYaccLKFxLSMmuGuS4xpv+OjmE=; b=GoA9gBJ7cfvq Pcq/VpKZ2e7C0/Iz86R8j5O1C7USrQYWaHQi47ZfAWK0dzwxl5x3IOkICWt3YLKpIf2lVgNPDuIRm Rd4c8t2dwpOpMHyBz9STfheBz0dpw0xh6IuFT8VMSaca/io9TiHjBP9cvqxUg3LW7M50mHg5hgmqL hxK/qrVYFw5BA0T17hNliDphCb/srKi0WwYnJJmUNZDint6626takQGlUUsNP6p45wqh3dblwyV8C swiOWB5Hz/eRafJ6w0brqKaFhAQHHnSuJifakeVFbuNhJ/oePUluZPkDC5TlXcVlqE/OTnMPjbafm D6ozijxv3/ET5kmzRLVehw==; Date: Sun, 22 Dec 2024 17:52:25 +0200 Message-Id: <86r05z67gm.fsf@gnu.org> From: Eli Zaretskii To: Eshel Yaron , aaronjensen@gmail.com In-Reply-To: (message from Eshel Yaron on Sat, 14 Dec 2024 10:45:45 +0100) Subject: Re: bug#73862: [PATCH] Add `header-line-active` and `header-line-inactive` faces. References: <86jzcey3cu.fsf@gnu.org> <8634j1n9nx.fsf@gnu.org> <86ldwrkeiy.fsf@gnu.org> <865xnviliv.fsf@gnu.org> <86wmgbgxjx.fsf@gnu.org> <86ttbfgvyr.fsf@gnu.org> <86r06jgv1j.fsf@gnu.org> <86jzcafcj6.fsf@gnu.org> <867c8af514.fsf@gnu.org> <86ldwpedud.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 73862 Cc: trevor.m.murphy@gmail.com, yantar92@posteo.net, monnier@iro.umontreal.ca, 73862@debbugs.gnu.org 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: Eshel Yaron > Cc: Eli Zaretskii , trevor.m.murphy@gmail.com, > monnier@iro.umontreal.ca, aaronjensen@gmail.com, 73862@debbugs.gnu.org, > Ihor Radchenko > Date: Sat, 14 Dec 2024 10:45:45 +0100 > > Eshel Yaron writes: > > >>> Aaron shared a recipe to reproduce this behavior, copied here: > >>> > >>> --8<---------------cut here---------------start------------->8--- > >>> (setq header-line-format "Some header") > >>> (face-remap-set-base 'header-line 'highlight) > >>> (switch-to-buffer-other-window "new") > >>> ;; In new buffer/window: > >>> (setq header-line-format "Some header") > >>> (other-window 1) > >>> ;; In original buffer/window: > >>> (set-face-attribute 'default nil :height (+ (face-attribute 'default :height) 10)) > >>> --8<---------------cut here---------------end--------------->8--- > >> > >> Are you also change the attributes of the default face to cause the > >> "spreading"? If not, please show a recipe. Because I was unable to > >> see this without something like the last line of the recipe, and also > >> that line _must_ be in the buffer where header-line is remapped, > >> otherwise the effect is not seen. > > > > Yes, I used C-x C-M-= in the buffer in which I remapped header-line. > > Note that this issue also affects Org: org-columns remaps header-line in > org-columns--display-here. (CC'ing Ihor.) Please try the patch below. If it gives good results, please run with it for awhile, and tell if you see anything unusual or unexpected. diff --git a/src/xfaces.c b/src/xfaces.c index 5f60f38..9591a5c 100644 --- a/src/xfaces.c +++ b/src/xfaces.c @@ -5143,10 +5143,19 @@ lookup_basic_face (struct window *w, struct frame *f, int face_id) for the very common no-remapping case. */ mapping = assq_no_quit (name, Vface_remapping_alist); if (NILP (mapping)) - return face_id; /* Give up. */ + { + Lisp_Object face_attrs[LFACE_VECTOR_SIZE]; + + /* If the face inherits from another, we need to realize it, + because the parent face could be remapped. */ + if (!get_lface_attributes (w, f, name, face_attrs, false, 0) + || NILP (face_attrs[LFACE_INHERIT_INDEX]) + || UNSPECIFIEDP (face_attrs[LFACE_INHERIT_INDEX])) + return face_id; /* Give up. */ + } - /* If there is a remapping entry, lookup the face using NAME, which will - handle the remapping too. */ + /* If there is a remapping entry, or the face inherits from another, + lookup the face using NAME, which will handle the remapping too. */ remapped_face_id = lookup_named_face (w, f, name, false); if (remapped_face_id < 0) return face_id; /* Give up. */ @@ -5863,6 +5872,11 @@ realize_basic_faces (struct frame *f) if (realize_default_face (f)) { + /* Basic faces must be realized disregarding face-remapping-alist, + since otherwise face-remapping might affect the basiic faces in + the face cache. */ + specpdl_ref count = SPECPDL_INDEX (); + specbind (Qface_remapping_alist, Qnil); realize_named_face (f, Qmode_line_active, MODE_LINE_ACTIVE_FACE_ID); realize_named_face (f, Qmode_line_inactive, MODE_LINE_INACTIVE_FACE_ID); realize_named_face (f, Qtool_bar, TOOL_BAR_FACE_ID); @@ -5884,6 +5898,7 @@ realize_basic_faces (struct frame *f) realize_named_face (f, Qchild_frame_border, CHILD_FRAME_BORDER_FACE_ID); realize_named_face (f, Qtab_bar, TAB_BAR_FACE_ID); realize_named_face (f, Qtab_line, TAB_LINE_FACE_ID); + unbind_to (count, Qnil); /* Reflect changes in the `menu' face in menu bars. */ if (FRAME_FACE_CACHE (f)->menu_face_changed_p) From debbugs-submit-bounces@debbugs.gnu.org Mon Dec 23 05:20:58 2024 Received: (at 73862) by debbugs.gnu.org; 23 Dec 2024 10:20:58 +0000 Received: from localhost ([127.0.0.1]:53397 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tPfYX-00050r-Im for submit@debbugs.gnu.org; Mon, 23 Dec 2024 05:20:58 -0500 Received: from mail.eshelyaron.com ([107.175.124.16]:47678 helo=eshelyaron.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tPfYV-00050i-4J for 73862@debbugs.gnu.org; Mon, 23 Dec 2024 05:20:56 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eshelyaron.com; s=mail; t=1734949254; bh=esAohmbqBBikGfCsPCNanCweT0s7k3UO9yxDNvLysPY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=p1PbGt2JOpgussUqjHPHd4slU8xFnErR5TuMhr4H3ioastJcIOeoC8MU9vCelXzA2 lN0sEi903YIBFS7nL1w1fvY/axpMH1GNyAGtr8JyZWiQZRV6hZ/sOwOiWzeZnGmpkb f714AEKieEvpKchyMR6EosZUwgFuSpDS61jaxZcK4mKDjX0X57Xly3Id0C6uXEk9NS Tb4DBuraRxnAQ6n8JxQjpcttWuGYr7IiOUNfbYESShf1JPZTIWb/pd28pCLgmS+u/A jK40jlDYBBjJ0iV3NCcv52QSt9qm/w6vZSB5unVzSrBGJrCeamflrK6yQg9HkCUikX wz2N3rj3g03uQ== From: Eshel Yaron To: Eli Zaretskii Subject: Re: bug#73862: [PATCH] Add `header-line-active` and `header-line-inactive` faces. In-Reply-To: <86r05z67gm.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 22 Dec 2024 17:52:25 +0200") References: <8634j1n9nx.fsf@gnu.org> <86ldwrkeiy.fsf@gnu.org> <865xnviliv.fsf@gnu.org> <86wmgbgxjx.fsf@gnu.org> <86ttbfgvyr.fsf@gnu.org> <86r06jgv1j.fsf@gnu.org> <86jzcafcj6.fsf@gnu.org> <867c8af514.fsf@gnu.org> <86ldwpedud.fsf@gnu.org> <86r05z67gm.fsf@gnu.org> Date: Mon, 23 Dec 2024 11:20:51 +0100 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 73862 Cc: trevor.m.murphy@gmail.com, yantar92@posteo.net, monnier@iro.umontreal.ca, aaronjensen@gmail.com, 73862@debbugs.gnu.org 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.0 (-) Eli Zaretskii writes: >> From: Eshel Yaron >> Cc: Eli Zaretskii , trevor.m.murphy@gmail.com, >> monnier@iro.umontreal.ca, aaronjensen@gmail.com, 73862@debbugs.gnu.org, >> Ihor Radchenko >> Date: Sat, 14 Dec 2024 10:45:45 +0100 >> >> Eshel Yaron writes: >> >> >>> Aaron shared a recipe to reproduce this behavior, copied here: >> >>> >> >>> --8<---------------cut here---------------start------------->8--- >> >>> (setq header-line-format "Some header") >> >>> (face-remap-set-base 'header-line 'highlight) >> >>> (switch-to-buffer-other-window "new") >> >>> ;; In new buffer/window: >> >>> (setq header-line-format "Some header") >> >>> (other-window 1) >> >>> ;; In original buffer/window: >> >>> (set-face-attribute 'default nil :height (+ (face-attribute 'default :height) 10)) >> >>> --8<---------------cut here---------------end--------------->8--- >> >> >> >> Are you also change the attributes of the default face to cause the >> >> "spreading"? If not, please show a recipe. Because I was unable to >> >> see this without something like the last line of the recipe, and also >> >> that line _must_ be in the buffer where header-line is remapped, >> >> otherwise the effect is not seen. >> > >> > Yes, I used C-x C-M-= in the buffer in which I remapped header-line. >> >> Note that this issue also affects Org: org-columns remaps header-line in >> org-columns--display-here. (CC'ing Ihor.) > > Please try the patch below. If it gives good results, please run with > it for awhile, and tell if you see anything unusual or unexpected. Thanks, so far so good. Best, Eshel From debbugs-submit-bounces@debbugs.gnu.org Mon Dec 23 16:20:37 2024 Received: (at 73862) by debbugs.gnu.org; 23 Dec 2024 21:20:37 +0000 Received: from localhost ([127.0.0.1]:58271 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tPpqv-0004Ll-D9 for submit@debbugs.gnu.org; Mon, 23 Dec 2024 16:20:37 -0500 Received: from mail-lj1-f172.google.com ([209.85.208.172]:48422) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tPpqs-0004La-LN for 73862@debbugs.gnu.org; Mon, 23 Dec 2024 16:20:35 -0500 Received: by mail-lj1-f172.google.com with SMTP id 38308e7fff4ca-3003e203acaso46561861fa.1 for <73862@debbugs.gnu.org>; Mon, 23 Dec 2024 13:20:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1734988774; x=1735593574; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=tB5NfLxHNWVUWdM3FLzwjEQwK/k/tHFDcKHlKXWKSqY=; b=AgYOnOsONz/Pt/YXV+73T0NXBZ/DCvwaoYAqPJg2dWLBhZJIWnVLob//2DYsUwxSac ANnTdRXUP5Q+r1ZEYvkdAreshqE03cuuIA2QLAs6CuwUv7TaXOEQV1ETdOQrFZ+un5zF m1abshULcUQdCPJ1EGkUCpR08zWommaGa/GN+LuE8Iwq39JrOJgzTD79ddOihC2GKrkm cu4lxw6wEptoLAtfRuSWkEHQZyuJNCcWNMMeTQgW2QlQohNu1ZP9rUPORh+UlGPaGbG2 2YcBokbl0t7/3rLfDtcHDT9Hn1IecmjLRF86VS2iRqpU+Y7my5E6ttKkufmBS80VtKbe a91A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734988774; x=1735593574; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=tB5NfLxHNWVUWdM3FLzwjEQwK/k/tHFDcKHlKXWKSqY=; b=WM6/Dgn6H0i/nxCd0KAWnSwVaIX3RSXpZbmDWwTn01GN+klS4P/1sFNjLyCbDvfEBM jQUx2BdBuolOjPfcup4vYSLTjYAonfsTlU/pUMCq0Ig9Rbx2mQXcW+/TGaOKMrn7uP6l gjOGuYFD4pDMRW8ROHUzNUDbQBt0jKDau9aGkWQBkzYNxkAqs8btNG54Bh+EUfJdHSWs sIgcmq2N2xRwnFQ6ZI3BvzdTBJ0V2aeOyk0DOJ9UV562Edr5mvaMEn6UvpiLtAUxsq4B lGVu4KIrQ/Z3TeGp2y3Fm3GBu+X4K7fm/OZIFBTH2Kuhfipio4KsmXnE9BLcseyBiDbI OljQ== X-Forwarded-Encrypted: i=1; AJvYcCUUmgDuR+zs2/JGoV4sEjckzECoN7KjWHCrQBc3c3clcDlRiI4g2cVYe+5/9o8zTgGQxt9Gpg==@debbugs.gnu.org X-Gm-Message-State: AOJu0YxObF3MLUx1EheS0qEyHNwRGvgNj8TBbWZv8a6M5JHRdPy8T+9a NNFo6Oo3dXZ6ltblJtEInmoOVhdcy5/BZfz92JxckMVCbYvtGbS8R9u0gRdcQFgBAOFfQYP6xmh fJRK4MVtIvgFtFQtRzq0ADAKR4So= X-Gm-Gg: ASbGncuATfTxkEFNGQUZM8YlF8mzAkzuPZYPUQDBax3hQblkx1xUr2f+SXeuIGJ5EgP HhJZmM81XwXurhOw9e/jRHh9wQWChMPSVs037fPTGyDsJCeasOfzSS63kGy8l+g== X-Google-Smtp-Source: AGHT+IFH/zlfhCtuV0EXzLtzokFN7yISyK2YLq9IXfZXPmwkPZIx8r0MwnnWR2cpS23AFg7mF/UVS631KnHPYavRYHE= X-Received: by 2002:a05:651c:4ca:b0:302:3355:f756 with SMTP id 38308e7fff4ca-304685de7e4mr39257001fa.35.1734988773523; Mon, 23 Dec 2024 13:19:33 -0800 (PST) Received: from 649336022844 named unknown by gmailapi.google.com with HTTPREST; Mon, 23 Dec 2024 13:19:32 -0800 Mime-Version: 1.0 X-Superhuman-Draft-ID: draft00f51776a2728fc5 X-Superhuman-ID: m51ji90b.db49fa28-b4b4-4ae1-85ef-f9e9685bad64 In-Reply-To: References: <8634j1n9nx.fsf@gnu.org> <86ldwrkeiy.fsf@gnu.org> <865xnviliv.fsf@gnu.org> <86wmgbgxjx.fsf@gnu.org> <86ttbfgvyr.fsf@gnu.org> <86r06jgv1j.fsf@gnu.org> <86jzcafcj6.fsf@gnu.org> <867c8af514.fsf@gnu.org> <86ldwpedud.fsf@gnu.org> <86r05z67gm.fsf@gnu.org> From: Aaron Jensen X-Mailer: Superhuman Desktop (2024-12-18T20:41:51Z) Date: Mon, 23 Dec 2024 13:19:32 -0800 Message-ID: Subject: Re: bug#73862: [PATCH] Add `header-line-active` and `header-line-inactive` faces. To: Eshel Yaron Content-Type: multipart/alternative; boundary="0000000000008909ed0629f68d97" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 73862 Cc: trevor.m.murphy@gmail.com, Eli Zaretskii , yantar92@posteo.net, monnier@iro.umontreal.ca, 73862@debbugs.gnu.org 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.0 (-) --0000000000008909ed0629f68d97 Content-Type: text/plain; charset="UTF-8" On Mon, Dec 23, 2024 at 2:20 AM, Eshel Yaron wrote: > Eli Zaretskii writes: > > Please try the patch below. If it gives good results, please run with it > for awhile, and tell if you see anything unusual or unexpected. > > Thanks, so far so good. > Same for me, it's also working so far. Are there any tradeoffs with this approach other than additional code complexity? Any performance concerns? Thanks, Aaron --0000000000008909ed0629f68d97 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Dec 23, 2024 at 2:20 AM, Eshel Yaron <me@eshelyaron.com> wrote:
=

Eli Zaretskii <eliz@= gnu.org> writes:

Please try the patch below. If it gives good results, please run with it for awhile, and tell if you see anything unusual or unexpected.

Thanks, so far so good.

<= /div>

Same for me, it's also working so far.

Are there any tradeoffs with this=C2=A0approach = other than additional code complexity? Any performance concerns?
<= div>
Thanks,

Aaron

--0000000000008909ed0629f68d97-- From debbugs-submit-bounces@debbugs.gnu.org Mon Dec 23 22:30:44 2024 Received: (at 73862) by debbugs.gnu.org; 24 Dec 2024 03:30:45 +0000 Received: from localhost ([127.0.0.1]:58875 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tPvd6-0004kZ-GF for submit@debbugs.gnu.org; Mon, 23 Dec 2024 22:30:44 -0500 Received: from eggs.gnu.org ([209.51.188.92]:40236) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tPvd4-0004kN-Lx for 73862@debbugs.gnu.org; Mon, 23 Dec 2024 22:30:43 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tPvcy-0006iJ-GY; Mon, 23 Dec 2024 22:30:36 -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=rh5o3D2qZPlMJTU6kLayT2parO98P8a7y2LN47rB8kM=; b=VxcpBT35qSGa THp2YIrWUxQFJhv1CcuKqidCUjvNsSJFHqIkU4lqr2DVGTJ1/1zjnn6Lg8IoYv6kvsrGMiCp7H4Uz /ZQmQ6odBusYcJicUiqlwqykjC979Y2TLcQQPbHNtfDWDb3pbp+hsZnDAH51yNzPorb9LYMo5degU RI21vcS9PdC5NAr03uxnImHo2DRy+Zc30qZnN0L3d03rs/hfk4wzs1mbN9yoze8gwd9zsVQX1FOH6 WVbic63hdvqH8U0TC8TvB0m4/mbC9h+K4HRF8o/ggswFYQss64Vl6eqZhmKjD0k8pr6wvr3i3rOGn getbu+MjAdrE4qLTQG0Zww==; Date: Tue, 24 Dec 2024 05:30:31 +0200 Message-Id: <86wmfp3gh4.fsf@gnu.org> From: Eli Zaretskii To: Aaron Jensen In-Reply-To: (message from Aaron Jensen on Mon, 23 Dec 2024 13:19:32 -0800) Subject: Re: bug#73862: [PATCH] Add `header-line-active` and `header-line-inactive` faces. References: <8634j1n9nx.fsf@gnu.org> <86ldwrkeiy.fsf@gnu.org> <865xnviliv.fsf@gnu.org> <86wmgbgxjx.fsf@gnu.org> <86ttbfgvyr.fsf@gnu.org> <86r06jgv1j.fsf@gnu.org> <86jzcafcj6.fsf@gnu.org> <867c8af514.fsf@gnu.org> <86ldwpedud.fsf@gnu.org> <86r05z67gm.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 73862 Cc: trevor.m.murphy@gmail.com, yantar92@posteo.net, me@eshelyaron.com, monnier@iro.umontreal.ca, 73862@debbugs.gnu.org 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: Aaron Jensen > Date: Mon, 23 Dec 2024 13:19:32 -0800 > Cc: Eli Zaretskii , trevor.m.murphy@gmail.com, monnier@iro.umontreal.ca, > 73862@debbugs.gnu.org, yantar92@posteo.net > > On Mon, Dec 23, 2024 at 2:20 AM, Eshel Yaron wrote: > > Eli Zaretskii writes: > > Please try the patch below. If it gives good results, please run with it for awhile, and tell if you see > anything unusual or unexpected. > > Thanks, so far so good. > > Same for me, it's also working so far. > > Are there any tradeoffs with this approach other than additional code complexity? Any performance > concerns? I didn't time the code. It is a bit more expensive, but I don't know by how much. Maybe you could see what happens in a session with lots and lots of faces and report? From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 24 00:18:24 2024 Received: (at 73862) by debbugs.gnu.org; 24 Dec 2024 05:18:24 +0000 Received: from localhost ([127.0.0.1]:59011 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tPxJH-000191-Qa for submit@debbugs.gnu.org; Tue, 24 Dec 2024 00:18:24 -0500 Received: from mail-lj1-f178.google.com ([209.85.208.178]:61816) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tPxJD-00018q-Jr for 73862@debbugs.gnu.org; Tue, 24 Dec 2024 00:18:22 -0500 Received: by mail-lj1-f178.google.com with SMTP id 38308e7fff4ca-3002c324e7eso52202851fa.3 for <73862@debbugs.gnu.org>; Mon, 23 Dec 2024 21:18:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1735017438; x=1735622238; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=x7NiAhhDbiTrwjgxb4eyVvfRxmLHHreHBbLN3VqCZCM=; b=lIxmOwMs34SUbNH0ffvzX2k7CIifZo+jRB6y3GpiEDDNiLgu0RY3Lh3Oi7fwrNfRK7 7eZUdoxjtLNqAoYlkCFr636KSZ+1YWDn2wkO59wmS6/LIKytBb7agsPQrPd5+pisLaRs idrEm1ktqcFLbhTQY5YXeWwKGZSF5dtP7kXNHldZu83I1OkwgoYVooLRJtq/Ow0T5y/Q 1qKn0ouJiu4arqk5NnUW9dYWnhDxXQjnZLHrWl2f2ZEtSHdj/xZJ+lOCKFPNVyP2ak8a Ab7y1VVXRJdqDeqNsEzEvC/uC+wbI2/IB7NLy0DpxZDiKJQr/r5P7CaD4QOiJ96ybyWL CJsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1735017438; x=1735622238; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=x7NiAhhDbiTrwjgxb4eyVvfRxmLHHreHBbLN3VqCZCM=; b=i/3Ex52gBitsLGaC25etHtjHFIINnPsddeHvJ2jZbQp4Y+8vUJg9IqZhS23OU8J0Bv Uogwbx5jBAl46pCCJYduwqI8yBL1zWGZ1RtdnqkaXl5qVYO7rhZRYifow9UgylTSAYVD iC93/rKAdRu0rF3yTI1qAVhRR0lzswgqGrEuQGlWZSvTu+xAqo/ca3sQxzICtha+ocra u778E9KC3zs75njLaW7JaflRBjuOp9IJBzCJGuA4dP0xIK8vooTttdFF+9BiR0Yd7h4F LE01HqRblhtwKheYDXll5uw3qMkR7itpWZN6JgpAS+1M284avTy8vo7XR4TgZlTCPdaS IaUQ== X-Forwarded-Encrypted: i=1; AJvYcCUc9OoZ6BThmN451bIDMMBd9/BH6Mu8CxseBb6yfipQymbynsFNTFY9roFOCQ7VzGEbKwYeOA==@debbugs.gnu.org X-Gm-Message-State: AOJu0Yw/GeGev5XUJ8Y9XGR1HvSSDLpd+vZd4tC4amA2BOpriGkge3Ce /ii/risurpqQIwVEgfmr6K6BJ5eGB6VNzSW05EJvNQ28U1R6ooN071Ijmu+BVgc0+DhkzMaE4RC cYJ4TvIbntk60JDBFNRSc0huYmUY= X-Gm-Gg: ASbGncuaoEdlcAWKmIGgRQ5mG6yNOEt0YXRnPwdZsobr5Nn48HBuIrz4d7Q/vqd7RcK EOuKCVb9MaYx5ejP8JupkHOOruKVaxUsK6PtAoxzSpuZshdZaTcYFAn1Mbl+nsQ== X-Google-Smtp-Source: AGHT+IGgqN5MO8uM22xB1FYy+ZX4vjFsV4CBgbBp6JQHXBGWpkqZTb33Dly+qy30n+gU2mnd57EtwMlsXVnHXdrD6vY= X-Received: by 2002:a2e:a7ca:0:b0:300:26bc:4311 with SMTP id 38308e7fff4ca-30468569292mr35463591fa.18.1735017438300; Mon, 23 Dec 2024 21:17:18 -0800 (PST) Received: from 649336022844 named unknown by gmailapi.google.com with HTTPREST; Mon, 23 Dec 2024 21:17:16 -0800 Mime-Version: 1.0 X-Mailer: Superhuman Desktop (2024-12-18T20:41:51Z) X-Superhuman-Draft-ID: draft00c6989158efd2a0 References: <8634j1n9nx.fsf@gnu.org> <86ldwrkeiy.fsf@gnu.org> <865xnviliv.fsf@gnu.org> <86wmgbgxjx.fsf@gnu.org> <86ttbfgvyr.fsf@gnu.org> <86r06jgv1j.fsf@gnu.org> <86jzcafcj6.fsf@gnu.org> <867c8af514.fsf@gnu.org> <86ldwpedud.fsf@gnu.org> <86r05z67gm.fsf@gnu.org> <86wmfp3gh4.fsf@gnu.org> X-Superhuman-ID: m520kllb.d0278144-9876-4521-97b4-7565b6870dfb In-Reply-To: <86wmfp3gh4.fsf@gnu.org> From: Aaron Jensen Date: Mon, 23 Dec 2024 21:17:16 -0800 Message-ID: Subject: Re: bug#73862: [PATCH] Add `header-line-active` and `header-line-inactive` faces. To: Eli Zaretskii Content-Type: multipart/alternative; boundary="00000000000016d1820629fd3a8e" X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 73862 Cc: trevor.m.murphy@gmail.com, yantar92@posteo.net, me@eshelyaron.com, monnier@iro.umontreal.ca, 73862@debbugs.gnu.org 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.0 (-) --00000000000016d1820629fd3a8e Content-Type: text/plain; charset="UTF-8" On Mon, Dec 23, 2024 at 7:30 PM, Eli Zaretskii wrote: > From: Aaron Jensen > Date: Mon, 23 Dec 2024 13:19:32 -0800 > Cc: Eli Zaretskii , trevor.m.murphy@gmail.com, monnier@iro. > umontreal.ca, 73862@debbugs.gnu.org, yantar92@posteo.net > > On Mon, Dec 23, 2024 at 2:20 AM, Eshel Yaron wrote: > > Eli Zaretskii writes: > > Please try the patch below. If it gives good results, please run with it > for awhile, and tell if you see anything unusual or unexpected. > > Thanks, so far so good. > > Same for me, it's also working so far. > > Are there any tradeoffs with this approach other than additional code > complexity? Any performance concerns? > > I didn't time the code. It is a bit more expensive, but I don't know by > how much. Maybe you could see what happens in a session with lots and lots > of faces and report? > Does the change impact anything more than the infrequent basic face calculation (whatever the thing was we were triggering by changing the default face size) or is it in the standard render path? Aaron --00000000000016d1820629fd3a8e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Dec 23, 2024 at 7:30 PM, Eli Zaretskii <eliz@gnu.org> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

From: Aaron Jensen <aaronjensen@gmail.c= om>
Date: Mon, 23 Dec 20= 24 13:19:32 -0800
Cc: Eli Zaretskii <eliz@gnu.org>, trevor.m.murphy@gmail.com, monnier@iro.umontreal.ca,=20 73862@debbugs.gnu.org, yantar92@posteo.net

On Mon, Dec 23, 2024 at 2:20 AM, Eshel Yaron <me@eshelyaron.com> wrote:

Eli Zaretskii <eliz@gnu.org> writes:=20

Please try the patch below. If it gives good results, please run with it fo= r awhile, and tell if you see anything unusual or unexpected.=20

Thanks, so far so good.

Same for me, it's also working so far.

Are there any tradeoffs with this approach other than additional code compl= exity? Any performance concerns?

I didn't time the code. It is a bit more expensive, but I don't kn= ow by how much. Maybe you could see what happens in a session with lots and lots of faces and report?

<= /div>

Does the change impact anything more th= an the infrequent basic face calculation (whatever the thing was we were tr= iggering by changing the default face size) or is it in the standard render= path?

Aaron
--00000000000016d1820629fd3a8e-- From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 24 07:44:59 2024 Received: (at 73862) by debbugs.gnu.org; 24 Dec 2024 12:44:59 +0000 Received: from localhost ([127.0.0.1]:59870 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tQ4HS-0006W7-Ge for submit@debbugs.gnu.org; Tue, 24 Dec 2024 07:44:58 -0500 Received: from eggs.gnu.org ([209.51.188.92]:43318) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tQ4HO-0006Vs-B9 for 73862@debbugs.gnu.org; Tue, 24 Dec 2024 07:44:56 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tQ4HH-0008UQ-PU; Tue, 24 Dec 2024 07:44: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=j3oZyRv4dPGYg/sHODLyy0pkWllVPNgheLc0MyHzPkY=; b=hmLNHEBtf4VU zR5UDd/9nzAazQblQlyrqBZTkEMjyATljm/3axSvOnsFUVkm/7JEVDwEeAW+jlry/rgHluLfPkoIX bTo7Jpkq0on2BjzQqsAaR0SZ8jBhCu9Cif4ketp8f4i19GqfWgkpv4qHdEwmbSQoDX4fNJzbGGhm9 MLE6EmHj8ohuP0ynHOp/0zX9pMszpB2C8k9nXexrbgam0oSeyQFGma2DDFE63iSi+Bp5T3uy0nQqV ArvgZk/z6ase4qglpRCEbfmmTX/EvQO6Kuu4+lhLboy/divPPvHQnfJx9gBqo0Z9EVUpVuxTo3ixz 4aglTio7o57SJairbLpshQ==; Date: Tue, 24 Dec 2024 14:44:40 +0200 Message-Id: <86ikr92qtj.fsf@gnu.org> From: Eli Zaretskii To: Aaron Jensen In-Reply-To: (message from Aaron Jensen on Mon, 23 Dec 2024 21:17:16 -0800) Subject: Re: bug#73862: [PATCH] Add `header-line-active` and `header-line-inactive` faces. References: <8634j1n9nx.fsf@gnu.org> <86ldwrkeiy.fsf@gnu.org> <865xnviliv.fsf@gnu.org> <86wmgbgxjx.fsf@gnu.org> <86ttbfgvyr.fsf@gnu.org> <86r06jgv1j.fsf@gnu.org> <86jzcafcj6.fsf@gnu.org> <867c8af514.fsf@gnu.org> <86ldwpedud.fsf@gnu.org> <86r05z67gm.fsf@gnu.org> <86wmfp3gh4.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 73862 Cc: trevor.m.murphy@gmail.com, yantar92@posteo.net, me@eshelyaron.com, monnier@iro.umontreal.ca, 73862@debbugs.gnu.org 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: Aaron Jensen > Date: Mon, 23 Dec 2024 21:17:16 -0800 > Cc: me@eshelyaron.com, trevor.m.murphy@gmail.com, monnier@iro.umontreal.ca, > 73862@debbugs.gnu.org, yantar92@posteo.net > > Are there any tradeoffs with this approach other than additional code complexity? Any > performance concerns? > > I didn't time the code. It is a bit more expensive, but I don't know by how much. Maybe you could see > what happens in a session with lots and lots of faces and report? > > Does the change impact anything more than the infrequent basic face calculation (whatever the thing was > we were triggering by changing the default face size) or is it in the standard render path? It affects realization of basic faces and also their lookup (by face ID, which is what the display engine uses). But these two operations are not so rare. In particular, any change of attributes of a "named face" (a face identified by its symbol) will usually cause us free and re-realize all of the frame's faces, including the basic ones. Given what current Lisp programs like to do, this happens surprisingly frequently. And face look up happens every time a window is redisplayed. From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 04 06:47:57 2025 Received: (at 73862) by debbugs.gnu.org; 4 Jan 2025 11:47:57 +0000 Received: from localhost ([127.0.0.1]:53684 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tU2dI-0003Ny-L2 for submit@debbugs.gnu.org; Sat, 04 Jan 2025 06:47:57 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:40986) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tU2dG-0003Ne-VZ for 73862@debbugs.gnu.org; Sat, 04 Jan 2025 06:47:55 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tU2dB-0005Nc-Jq; Sat, 04 Jan 2025 06:47:49 -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=5ZgJL7VWgxkAanHhdSisklR4Z76T2GiqyA8qsEDHT6c=; b=S3F5WBJSFtvR wu0HT5El9BPTKXrsEsRowgSzDS2cVIYAIp0/S4mnx/qQbQtPGWkblQ8qpE6XRt0Xpaj0N/1Bq7EXm urVlzyv30gNtrMfxq+14wA2nbs675tkMtS2JWHsNgjOtklmgkffDHAwuemxVwc/E2x5D8zy+zLrru plxrIgu1P2uDyDdkN8Xh5CM6jVoQnwEl5jO8kvz03norHqTzENJlJW9iTjHxeYAXBqWCdAel1GNuv hBsZUdo8iKNBHrSdz/eoGveFYWob2RFhgnIa9w8PYyqRkA9mRQ0E10uDCyK/ZxgdL+WVS37PGViZi s4fBOXMrpj+VYImaMu71aQ==; Date: Sat, 04 Jan 2025 13:47:46 +0200 Message-Id: <86ed1ier6l.fsf@gnu.org> From: Eli Zaretskii To: me@eshelyaron.com, aaronjensen@gmail.com In-Reply-To: <86r05z67gm.fsf@gnu.org> (message from Eli Zaretskii on Sun, 22 Dec 2024 17:52:25 +0200) Subject: Re: bug#73862: [PATCH] Add `header-line-active` and `header-line-inactive` faces. References: <86jzcey3cu.fsf@gnu.org> <8634j1n9nx.fsf@gnu.org> <86ldwrkeiy.fsf@gnu.org> <865xnviliv.fsf@gnu.org> <86wmgbgxjx.fsf@gnu.org> <86ttbfgvyr.fsf@gnu.org> <86r06jgv1j.fsf@gnu.org> <86jzcafcj6.fsf@gnu.org> <867c8af514.fsf@gnu.org> <86ldwpedud.fsf@gnu.org> <86r05z67gm.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 73862 Cc: trevor.m.murphy@gmail.com, yantar92@posteo.net, monnier@iro.umontreal.ca, 73862@debbugs.gnu.org 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 (---) > Cc: trevor.m.murphy@gmail.com, yantar92@posteo.net, monnier@iro.umontreal.ca, > 73862@debbugs.gnu.org > Date: Sun, 22 Dec 2024 17:52:25 +0200 > From: Eli Zaretskii > > > From: Eshel Yaron > > Cc: Eli Zaretskii , trevor.m.murphy@gmail.com, > > monnier@iro.umontreal.ca, aaronjensen@gmail.com, 73862@debbugs.gnu.org, > > Ihor Radchenko > > Date: Sat, 14 Dec 2024 10:45:45 +0100 > > > > Eshel Yaron writes: > > > > >>> Aaron shared a recipe to reproduce this behavior, copied here: > > >>> > > >>> --8<---------------cut here---------------start------------->8--- > > >>> (setq header-line-format "Some header") > > >>> (face-remap-set-base 'header-line 'highlight) > > >>> (switch-to-buffer-other-window "new") > > >>> ;; In new buffer/window: > > >>> (setq header-line-format "Some header") > > >>> (other-window 1) > > >>> ;; In original buffer/window: > > >>> (set-face-attribute 'default nil :height (+ (face-attribute 'default :height) 10)) > > >>> --8<---------------cut here---------------end--------------->8--- > > >> > > >> Are you also change the attributes of the default face to cause the > > >> "spreading"? If not, please show a recipe. Because I was unable to > > >> see this without something like the last line of the recipe, and also > > >> that line _must_ be in the buffer where header-line is remapped, > > >> otherwise the effect is not seen. > > > > > > Yes, I used C-x C-M-= in the buffer in which I remapped header-line. > > > > Note that this issue also affects Org: org-columns remaps header-line in > > org-columns--display-here. (CC'ing Ihor.) > > Please try the patch below. If it gives good results, please run with > it for awhile, and tell if you see anything unusual or unexpected. No complaints, so are you okay with me installing the change on the master branch? From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 04 15:23:06 2025 Received: (at 73862) by debbugs.gnu.org; 4 Jan 2025 20:23:06 +0000 Received: from localhost ([127.0.0.1]:57555 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tUAfq-00030f-Ed for submit@debbugs.gnu.org; Sat, 04 Jan 2025 15:23:06 -0500 Received: from mail-lj1-x22e.google.com ([2a00:1450:4864:20::22e]:60615) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1tUAfn-00030V-Vp for 73862@debbugs.gnu.org; Sat, 04 Jan 2025 15:23:04 -0500 Received: by mail-lj1-x22e.google.com with SMTP id 38308e7fff4ca-3003943288bso152217191fa.0 for <73862@debbugs.gnu.org>; Sat, 04 Jan 2025 12:23:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736022182; x=1736626982; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:references:in-reply-to:from :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=AmsG3xyu7EipVmZ2CU8nnh1878A4vJfm1i+SIog4gH4=; b=j8atNMWk9zcXbAmcJcrDGqIKbPKDfzYiVO4A2jxh4B0eMJtBrPV30Mtc2Zj0Zx//qh J7BaZdTNQGf3Vx4deHj4XmJgAVhpgM3XMTTX+iJ3eQ3aJ9qrPP1EBtt6xzueMcVC8kyr GOVh656ivkgQITWWWimN1ekqUeNqIwuR1U2szfHjwCG/LODVsusAU8oJtfIgD2lARnVS ACHvTEumenAuReKk7xwhxWV39ge8sCmZKgbvh/DnGEoyOqVCBvCIq7MfLDH7aKz4Crq+ 1bGWX2Hft9eXnXPtT3NHZy0k3Ev1KJLiboeiyQpy5s+emE3KsV1dQwkugbojvlC006Nh Z9Ig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736022182; x=1736626982; h=cc:to:subject:message-id:date:references:in-reply-to:from :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=AmsG3xyu7EipVmZ2CU8nnh1878A4vJfm1i+SIog4gH4=; b=lnDIGrvhKbX4tpqpRmpho9rnQWHGbpX6iBJgQ2G+9Jyros/bSqsSGmRCv3okFbORN2 ytA9GnKmuse03Md+9AH3n3R6jbT/7+TZLppvxYZwQWYD7KDfVQD0eqD/92QIM5LwwYuI 30yQuheVP4U41bIAR0iKLXdDsSbeLOLzMCcJI+E8tZaD9wfdsj5m4hB6bDaFQo8TjRmU Y/aFp/2SgFlnD2yZ+oTRMM2eA7gFPw6c9rOnBn9ojra5UsZF3v2ltQEDl9H56inX4exn LJ4EwAUBppM0IbzJvh7bDdgt4i3k9BKcixysuvcPYK2AofIQu9eFFEslshco/wSFe3bH +AVA== X-Forwarded-Encrypted: i=1; AJvYcCVHm1OURWcdILBIeUsrG8sptqo2ltspUItAUe4D6N/gNF2NG8P8CuIiS+REpSBuQlym/dtysQ==@debbugs.gnu.org X-Gm-Message-State: AOJu0YwURWlhh4meMfWchUu6kDrR3g+6RaUZfQHTqn8Um8FWHVcApYAh TtKvAfBKom4ZEXtLROVuWX2XtTp7qbpI4/1n0SxI0aljm26uQ0e4S7E33jaTOBbBil/AjnjFIL0 xz8Zw7uabw6iuG192VNxsSIEKkHA= X-Gm-Gg: ASbGncs6YZXs4+zsOKZPzNPhwefzd0oCi3AaKCxClhRAZnWefNwIpWOGHpSfBUvKP3+ KcNmGTNNncMkepoGJVHvW+a/QK2j+B8dqlprL4rIN7ZCXnJZGcrjLgtbDIBrYfQ== X-Google-Smtp-Source: AGHT+IF2KyqpMrLDAEj0Tn3edNOMMltUfp8zo2QglL3ad0H/RJhvf9elORhHE01jKK3jadexBoGW3vxRZ/Iyb7BqBtE= X-Received: by 2002:a05:651c:1545:b0:302:3abc:d9e8 with SMTP id 38308e7fff4ca-304685f7499mr179776751fa.32.1736022182120; Sat, 04 Jan 2025 12:23:02 -0800 (PST) Received: from 649336022844 named unknown by gmailapi.google.com with HTTPREST; Sat, 4 Jan 2025 15:23:00 -0500 Mime-Version: 1.0 X-Superhuman-ID: m5imrrc9.0b28e811-442b-40ee-86b0-d93abce131e3 X-Superhuman-Draft-ID: draft001640df9ca8cd15 From: Aaron Jensen X-Mailer: Superhuman Desktop (2025-01-03T20:05:52Z) In-Reply-To: <86ed1ier6l.fsf@gnu.org> References: <86jzcey3cu.fsf@gnu.org> <8634j1n9nx.fsf@gnu.org> <86ldwrkeiy.fsf@gnu.org> <865xnviliv.fsf@gnu.org> <86wmgbgxjx.fsf@gnu.org> <86ttbfgvyr.fsf@gnu.org> <86r06jgv1j.fsf@gnu.org> <86jzcafcj6.fsf@gnu.org> <867c8af514.fsf@gnu.org> <86ldwpedud.fsf@gnu.org> <86r05z67gm.fsf@gnu.org> <86ed1ier6l.fsf@gnu.org> Date: Sat, 4 Jan 2025 15:23:00 -0500 Message-ID: Subject: Re: bug#73862: [PATCH] Add `header-line-active` and `header-line-inactive` faces. To: Eli Zaretskii Content-Type: multipart/alternative; boundary="0000000000007cd36e062ae7294f" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 73862 Cc: trevor.m.murphy@gmail.com, yantar92@posteo.net, me@eshelyaron.com, monnier@iro.umontreal.ca, 73862@debbugs.gnu.org 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.0 (-) --0000000000007cd36e062ae7294f Content-Type: text/plain; charset="UTF-8" On Sat, Jan 04, 2025 at 3:47 AM, Eli Zaretskii wrote: > No complaints, so are you okay with me installing the change on the master > branch? > > No concerns from me. Thank you. Aaron --0000000000007cd36e062ae7294f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Jan 04, 2025 at 3:47 AM, Eli Zaretskii <eliz@gnu.org> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

No complaints, so are you okay with me installing the cha= nge on the master branch?


No concerns from me. Thank you.

Aaron
<= /html> --0000000000007cd36e062ae7294f-- From debbugs-submit-bounces@debbugs.gnu.org Sun Jan 05 02:42:26 2025 Received: (at 73862) by debbugs.gnu.org; 5 Jan 2025 07:42:26 +0000 Received: from localhost ([127.0.0.1]:59608 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tULHG-0001nM-7h for submit@debbugs.gnu.org; Sun, 05 Jan 2025 02:42:26 -0500 Received: from mail.eshelyaron.com ([107.175.124.16]:39184 helo=eshelyaron.com) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tULHD-0001n5-Ei for 73862@debbugs.gnu.org; Sun, 05 Jan 2025 02:42:24 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eshelyaron.com; s=mail; t=1736062942; bh=NDbbG5Yi221ZZ3jerxp5Jja9E4Vn7WosFuj5e1GRZPw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=slRhweJj0vD5zfBTYc3sxMpdmpIvEdS/xY4FmoXXka2K83o5cqzpvLpKyalzJDuGN ekziOVGjo2jWsvYZma9ZeRKVHNfvNCbGWs8WbZP9envT2XqnwoMbfGiK/U7wH5MvV1 0AQAjGACpUF7s+qby8AIz0bRrEA5KokCDOPLp3Un8uYTh/22PN5Fsjt+tI7KfB1+GE vkkA7Wzkp16QdStN5q4k180n7/Rhf+MkUKin0eXBTKbFUcQhVBnqC7fyqs0Izygcpt TuDaGD/f+bR08M6tdDbeMDqp55biwOhwt8SiG9JTGE/P+DmuU0l0o7uXCP//CZvz8T MUGgM3Ifzy75A== From: Eshel Yaron To: Aaron Jensen Subject: Re: bug#73862: [PATCH] Add `header-line-active` and `header-line-inactive` faces. In-Reply-To: (Aaron Jensen's message of "Sat, 4 Jan 2025 15:23:00 -0500") References: <86ldwrkeiy.fsf@gnu.org> <865xnviliv.fsf@gnu.org> <86wmgbgxjx.fsf@gnu.org> <86ttbfgvyr.fsf@gnu.org> <86r06jgv1j.fsf@gnu.org> <86jzcafcj6.fsf@gnu.org> <867c8af514.fsf@gnu.org> <86ldwpedud.fsf@gnu.org> <86r05z67gm.fsf@gnu.org> <86ed1ier6l.fsf@gnu.org> Date: Sun, 05 Jan 2025 08:42:20 +0100 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 73862 Cc: trevor.m.murphy@gmail.com, Eli Zaretskii , 73862@debbugs.gnu.org, yantar92@posteo.net, monnier@iro.umontreal.ca 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.0 (-) Aaron Jensen writes: > On Sat, Jan 04, 2025 at 3:47 AM, Eli Zaretskii wrote: > > No complaints, so are you okay with me installing the change on the master branch? > > No concerns from me. Thank you. Same here. Thanks, Eshel From debbugs-submit-bounces@debbugs.gnu.org Sun Jan 05 05:42:07 2025 Received: (at 73862-done) by debbugs.gnu.org; 5 Jan 2025 10:42:07 +0000 Received: from localhost ([127.0.0.1]:60050 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tUO59-0002XC-2d for submit@debbugs.gnu.org; Sun, 05 Jan 2025 05:42:07 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:48994) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tUO56-0002WZ-5q for 73862-done@debbugs.gnu.org; Sun, 05 Jan 2025 05:42:04 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tUO50-0000Xm-Fv; Sun, 05 Jan 2025 05:41: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=ojrLr7MFpzae7mQw9SnrDbEFnoi0R1CF7cmJubm6vH0=; b=NwBT70KKNegC TkhvzLccng8uYJAsp7aYUTPJ3yHDDzi7t/K0e4OxZDlqQSaIPycic9TgX7Z1dPd2STmLZdVoOtPwF 34tSZzXjEAUTCpxaVcSq8Ra+nBBJTox7o669ydMFLnE1Y/8DdrGwsYemf2FBsC/iOoaL9bZ2PKCPi TtS6ZZVAOdhkQ0w7wtoHdnTEXneT6Mtyvr5gK5wJ47k5UbefGNMhacxZjQWkZLX4gyxMs3Z9keYb6 QNfvApkMnLxNJ6vX+P2gGDnFe6HdNvb/GbDVwm1mv8QpZMiK35bg4kNNFnFelewyBm+a7fZBD9fQ+ vTmGO4iSmESbxc09SaCXXA==; Date: Sun, 05 Jan 2025 12:41:55 +0200 Message-Id: <86pll18rv0.fsf@gnu.org> From: Eli Zaretskii To: Eshel Yaron In-Reply-To: (message from Eshel Yaron on Sun, 05 Jan 2025 08:42:20 +0100) Subject: Re: bug#73862: [PATCH] Add `header-line-active` and `header-line-inactive` faces. References: <86ldwrkeiy.fsf@gnu.org> <865xnviliv.fsf@gnu.org> <86wmgbgxjx.fsf@gnu.org> <86ttbfgvyr.fsf@gnu.org> <86r06jgv1j.fsf@gnu.org> <86jzcafcj6.fsf@gnu.org> <867c8af514.fsf@gnu.org> <86ldwpedud.fsf@gnu.org> <86r05z67gm.fsf@gnu.org> <86ed1ier6l.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 73862-done Cc: trevor.m.murphy@gmail.com, yantar92@posteo.net, monnier@iro.umontreal.ca, aaronjensen@gmail.com, 73862-done@debbugs.gnu.org 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: Eshel Yaron > Cc: Eli Zaretskii , trevor.m.murphy@gmail.com, > yantar92@posteo.net, monnier@iro.umontreal.ca, 73862@debbugs.gnu.org > Date: Sun, 05 Jan 2025 08:42:20 +0100 > > Aaron Jensen writes: > > > On Sat, Jan 04, 2025 at 3:47 AM, Eli Zaretskii wrote: > > > > No complaints, so are you okay with me installing the change on the master branch? > > > > No concerns from me. Thank you. > > Same here. Thanks, now installed on the master branch, and closing the bug. From debbugs-submit-bounces@debbugs.gnu.org Sun Jan 05 16:41:57 2025 Received: (at 73862-done) by debbugs.gnu.org; 5 Jan 2025 21:41:57 +0000 Received: from localhost ([127.0.0.1]:35625 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tUYNh-0004tV-09 for submit@debbugs.gnu.org; Sun, 05 Jan 2025 16:41:57 -0500 Received: from mail-lf1-x136.google.com ([2a00:1450:4864:20::136]:48236) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1tUYNe-0004tD-70 for 73862-done@debbugs.gnu.org; Sun, 05 Jan 2025 16:41:55 -0500 Received: by mail-lf1-x136.google.com with SMTP id 2adb3069b0e04-54024ecc33dso17031509e87.0 for <73862-done@debbugs.gnu.org>; Sun, 05 Jan 2025 13:41:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736113308; x=1736718108; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=do4jTRwmrYkO0vEkyVKlF1/pi0TKEeAulPlMWb+Wyb0=; b=a79Zet25JeJvOx6RYWcDMMACNdWguABgt7HwMXZb8jTsP6EEE9d3BZPTI1PedhcwKW SFZVZTn/28UJ4M8cHiPGrWfpYUGrwb+JbKiAu1EoF1QxjQhYV+87V0sTZoqhmzGqBkX5 YkcZ05K7g6xxU4X8pZ+PijkFWutKX68O2K2vBUYol/+dmbTUDY+Bm9BW4mjak28hLAjK ElQMK1zwZ/09PZ/qAXK6ehRdLTEdpkBaNV9kRPO9mKrnDhOssJmMbV9Ki6bdedmMp589 iCRRZ0T49tWc9XDwfMUzZ3641wBnzk7/EPuZTnMj2hxbNEl+8nR/J++ueG6TkIbCrn4l Fs4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736113308; x=1736718108; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=do4jTRwmrYkO0vEkyVKlF1/pi0TKEeAulPlMWb+Wyb0=; b=LGLrfJp+xjJsVMDt4cHA/0PyKI6VYH4U7y9s1BoAX+UoeYFgoTgaab/CYddu6YEMK7 hcyXCcMHyIsykMPbnGlBrvkRzlvJ8hG69i+dS+Q+QbMRpkQVGg3vh2PrHtDECIgis861 L8KwhAkuHglcrVK464Pu5VnyLwi2RAD/KsbKMd5htVKCmCBSn5EarLtlPRkSn5vST84u UDzLnzGsfQuEldmKIACd9OvXQVadITbCOSjHTlIZ776fYeE+T5kEC1mfRvCr0+C5wWfe 2kLM4EMUr9qHMtgMJCNP6b1YPoq6Hl0l6Z+UGCGF2A+lq49UmRBI/MKPzjO/U9ldi0Uo IGFA== X-Forwarded-Encrypted: i=1; AJvYcCXAlfbqL7JI7RRx9Ymu6ti2960KuDpQCCehF+VGWVnWr2Z7Xb6wBZJjrCvXTsnMXUXnOL5iO4f3uTQ9@debbugs.gnu.org X-Gm-Message-State: AOJu0Yw5410wSg7bunIH/G4gWuWEHDh+vRUagrNxTdxeyGsYeB2CZ13b tfq4DSM4gs3mz+gIvZznv0chiNfkdCdR3rg6EJqDVbMlobg7olH28mLOOMUf4KXClW8lRptBZKk Gzq+DCLc2xMv7KCxcIGeWOPrGvPo= X-Gm-Gg: ASbGncsFbdn7sz/KZReSo/3CByteFCO0TxkGV1koloPBGsB8ms+Xe0H6IXCH4UcERiB t1qa4MA4J5Nxu9wHpyxRzgIhPRvy8zJV5ddH5LHoBKI59aPAKOsmBHhLOkgdlFA== X-Google-Smtp-Source: AGHT+IE15elvvVShmfi+O2Wwip6f1OY9QVuocpBu6s5P29raYc1JDDXWRdcn1T3CqdoBTZl2SRzs1mFdSo9A07RcV1U= X-Received: by 2002:a05:6512:334d:b0:542:2999:2e54 with SMTP id 2adb3069b0e04-54229992e56mr11916645e87.12.1736113307593; Sun, 05 Jan 2025 13:41:47 -0800 (PST) Received: from 649336022844 named unknown by gmailapi.google.com with HTTPREST; Sun, 5 Jan 2025 13:41:47 -0800 Mime-Version: 1.0 X-Superhuman-Draft-ID: draft00fd513ba5d82107 In-Reply-To: <86pll18rv0.fsf@gnu.org> X-Mailer: Superhuman Desktop (2025-01-03T20:05:52Z) X-Superhuman-ID: m5k50wpy.80b6dfa5-5831-4a42-be7f-d5393a298947 References: <86ldwrkeiy.fsf@gnu.org> <865xnviliv.fsf@gnu.org> <86wmgbgxjx.fsf@gnu.org> <86ttbfgvyr.fsf@gnu.org> <86r06jgv1j.fsf@gnu.org> <86jzcafcj6.fsf@gnu.org> <867c8af514.fsf@gnu.org> <86ldwpedud.fsf@gnu.org> <86r05z67gm.fsf@gnu.org> <86ed1ier6l.fsf@gnu.org> <86pll18rv0.fsf@gnu.org> From: Aaron Jensen Date: Sun, 5 Jan 2025 13:41:47 -0800 Message-ID: Subject: Re: bug#73862: [PATCH] Add `header-line-active` and `header-line-inactive` faces. To: Eli Zaretskii Content-Type: multipart/alternative; boundary="000000000000fd3533062afc60f9" X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 73862-done Cc: trevor.m.murphy@gmail.com, yantar92@posteo.net, Eshel Yaron , monnier@iro.umontreal.ca, 73862-done@debbugs.gnu.org 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.0 (-) --000000000000fd3533062afc60f9 Content-Type: text/plain; charset="UTF-8" On Sun, Jan 05, 2025 at 2:41 AM, Eli Zaretskii wrote: > From: Eshel Yaron > Cc: Eli Zaretskii , trevor.m.murphy@gmail.com, yantar92@ > posteo.net, monnier@iro.umontreal.ca, 73862@debbugs.gnu.org Date: Sun, 05 > Jan 2025 08:42:20 +0100 > > Aaron Jensen writes: > > On Sat, Jan 04, 2025 at 3:47 AM, Eli Zaretskii wrote: > > No complaints, so are you okay with me installing the change on the master > branch? > > No concerns from me. Thank you. > > Same here. > > Thanks, now installed on the master branch, and closing the bug. > Thank you, much appreciated. Aaron --000000000000fd3533062afc60f9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Jan 05, 2025 at 2:41 AM, Eli Zaretskii <eliz@gnu.org> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

From: Eshel Yaron <me@eshelyaron.com>= ;
Cc: Eli Zaretskii <eliz@gnu.org>, trevor.m.murphy@gmail.com, yantar92@posteo.net, monnier@iro.umontreal.ca, 73862@debbugs.gnu.org Date: Sun, 05 Jan 20= 25 08:42:20 +0100

Aaron Jensen <aaronjensen@gmail.com= > writes:

On Sat, Jan 04, 2025 at 3:47 AM, Eli Zaretskii <eliz@= gnu.org> wrote:

No complaints, so are you okay with me installing the change on the master = branch?

No concerns from me. Thank you.

Same here.

Thanks, now installed on the master branch, and closing the bug.


Than= k you, much appreciated.

Aaron
--000000000000fd3533062afc60f9-- From unknown Fri Sep 05 15:34:44 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Mon, 03 Feb 2025 12:24:12 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator