* bug#39649: 27.0.60; tab-line doesn't scroll @ 2020-02-17 18:51 João Guerra 2020-02-17 23:03 ` Juri Linkov 0 siblings, 1 reply; 32+ messages in thread From: João Guerra @ 2020-02-17 18:51 UTC (permalink / raw) To: 39649 tab-line doesn't scroll despite tab-line-auto-hscroll being set to t. When having several buffers open and switching to one that is not currently visible in the tab-line the tab-line won't auto-scroll. Video example: https://youtu.be/TDBeox2tQoA In GNU Emacs 27.0.60 (build 1, x86_64-w64-mingw32) of 2019-12-28 built on CIRROCUMULUS Repository revision: 21c3020fcec0a32122d2680a391864a75393031b Repository branch: emacs-27 Windowing system distributor 'Microsoft Corp.', version 10.0.18363 System Description: Microsoft Windows 10 Pro (v10.0.1909.18363.535) Configured using: 'configure --without-dbus --host=x86_64-w64-mingw32 --without-compress-install -C 'CFLAGS=-O2 -static -g3'' Configured features: XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY W32NOTIFY ACL GNUTLS LIBXML2 HARFBUZZ ZLIB TOOLKIT_SCROLL_BARS MODULES THREADS PDUMPER LCMS2 GMP Important settings: value of $LANG: PTG locale-coding-system: cp1252 ^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#39649: 27.0.60; tab-line doesn't scroll 2020-02-17 18:51 bug#39649: 27.0.60; tab-line doesn't scroll João Guerra @ 2020-02-17 23:03 ` Juri Linkov 2020-02-18 20:27 ` João Guerra 0 siblings, 1 reply; 32+ messages in thread From: Juri Linkov @ 2020-02-17 23:03 UTC (permalink / raw) To: João Guerra; +Cc: 39649 > tab-line doesn't scroll despite tab-line-auto-hscroll being set to t. > > When having several buffers open and switching to one that is not > currently visible in the tab-line the tab-line won't auto-scroll. This is an intentional feature: auto-scroll is disabled after the first time when you scroll the tab-line manually. Otherwise you won't be able to scroll the tab-line with the mouse-wheel or using the arrow buttons when auto-scrolling is still in effect during manual scrolling. You can reset auto-scrolling by evaluating in e.g. ‘M-:’ (set-window-parameter nil 'tab-line-hscroll nil) But indeed this is not right way to do this - it should automatically reset auto-scrolling at some time afterwards after finishing manually scrolling the tab-line. I was unable to find such a natural event on which to reset auto-scrolling - there are too many different possible events to choose from. One of the most natural is to reset auto-scrolling after manually selecting a tab. Could you please try this patch to see if it solves your problem: diff --git a/lisp/tab-line.el b/lisp/tab-line.el index 8f1221abe4..86ac234f3d 100644 --- a/lisp/tab-line.el +++ b/lisp/tab-line.el @@ -600,6 +600,7 @@ tab-line-select-tab (let* ((posnp (event-start e)) (tab (get-pos-property 1 'tab (car (posn-string posnp)))) (buffer (if (bufferp tab) tab (cdr (assq 'buffer tab))))) + (set-window-parameter nil 'tab-line-hscroll nil) (if buffer (tab-line-select-tab-buffer buffer (posn-window posnp)) (let ((select (cdr (assq 'select tab)))) ^ permalink raw reply related [flat|nested] 32+ messages in thread
* bug#39649: 27.0.60; tab-line doesn't scroll 2020-02-17 23:03 ` Juri Linkov @ 2020-02-18 20:27 ` João Guerra 2020-02-18 22:39 ` Juri Linkov 0 siblings, 1 reply; 32+ messages in thread From: João Guerra @ 2020-02-18 20:27 UTC (permalink / raw) To: Juri Linkov; +Cc: 39649 Seems to fix the issue in a specific situation, viz. after I select a tab manually with the mouse. However, when selecting a buffer that is already visible in the tab-line the tab-line still might get scrolled or if I just scroll the tab-line and change to a non-visible buffer the tab-line doesn't get scrolled. I'm a bit interested in knowing the reasoning to not always scroll the tab-line. ^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#39649: 27.0.60; tab-line doesn't scroll 2020-02-18 20:27 ` João Guerra @ 2020-02-18 22:39 ` Juri Linkov 2020-02-19 0:24 ` Juri Linkov 0 siblings, 1 reply; 32+ messages in thread From: Juri Linkov @ 2020-02-18 22:39 UTC (permalink / raw) To: João Guerra; +Cc: 39649 > Seems to fix the issue in a specific situation, viz. after I select a > tab manually with the mouse. However, when selecting a buffer that is > already visible in the tab-line the tab-line still might get scrolled > or if I just scroll the tab-line and change to a non-visible buffer > the tab-line doesn't get scrolled. I'm a bit interested in knowing the > reasoning to not always scroll the tab-line. While you're manually scrolling the tab-line using the mouse wheel or clicking on arrow buttons, auto-scrolling should be disabled because it should not bring the current tab back into view immediately on every step of manual scrolling. Just imagine that you clicked on the arrow button to scroll, but it has no effect because auto-scrolling immediately moved the tab-line back to its original state. This is why auto-scrolling should be disabled during manual scrolling. Now the question: how to detect the moment when you stop manually scrolling? How would you indicate that manual scrolling is finished, and it's time to enable auto-scrolling to bring the currently selected tab back into view? I have no idea. ^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#39649: 27.0.60; tab-line doesn't scroll 2020-02-18 22:39 ` Juri Linkov @ 2020-02-19 0:24 ` Juri Linkov 2020-02-19 20:57 ` João Guerra 0 siblings, 1 reply; 32+ messages in thread From: Juri Linkov @ 2020-02-19 0:24 UTC (permalink / raw) To: João Guerra; +Cc: 39649 >> Seems to fix the issue in a specific situation, viz. after I select a >> tab manually with the mouse. However, when selecting a buffer that is >> already visible in the tab-line the tab-line still might get scrolled >> or if I just scroll the tab-line and change to a non-visible buffer >> the tab-line doesn't get scrolled. I'm a bit interested in knowing the >> reasoning to not always scroll the tab-line. > > While you're manually scrolling the tab-line using the mouse wheel > or clicking on arrow buttons, auto-scrolling should be disabled > because it should not bring the current tab back into view immediately > on every step of manual scrolling. Just imagine that you clicked > on the arrow button to scroll, but it has no effect because auto-scrolling > immediately moved the tab-line back to its original state. > This is why auto-scrolling should be disabled during manual scrolling. > > Now the question: how to detect the moment when you stop manually > scrolling? How would you indicate that manual scrolling is finished, > and it's time to enable auto-scrolling to bring the currently selected tab > back into view? I have no idea. Actually, I have an idea - the right moment is when the current buffer changes on the current tab. This patch is the right way to handle this case: diff --git a/lisp/tab-line.el b/lisp/tab-line.el index 86ac234f3d..ad2b167e33 100644 --- a/lisp/tab-line.el +++ b/lisp/tab-line.el @@ -464,6 +464,13 @@ tab-line-format (window-buffer) (window-parameter nil 'tab-line-hscroll))) (cache (window-parameter nil 'tab-line-cache))) + ;; Enable auto-hscroll again after it was disabled on manual scrolling. + ;; The moment to enable it is when the window-buffer was updated. + (when (and tab-line-auto-hscroll ; if auto-hscroll was enabled + (natnump (nth 2 cache-key)) ; non-negative on manual scroll + cache ; window-buffer was updated + (not (equal (nth 1 (car cache)) (nth 1 cache-key)))) + (set-window-parameter nil 'tab-line-hscroll nil)) (or (and cache (equal (car cache) cache-key) (cdr cache)) (cdr (set-window-parameter nil 'tab-line-cache ^ permalink raw reply related [flat|nested] 32+ messages in thread
* bug#39649: 27.0.60; tab-line doesn't scroll 2020-02-19 0:24 ` Juri Linkov @ 2020-02-19 20:57 ` João Guerra 2020-02-20 23:07 ` Juri Linkov 0 siblings, 1 reply; 32+ messages in thread From: João Guerra @ 2020-02-19 20:57 UTC (permalink / raw) To: Juri Linkov; +Cc: 39649 This seems better to me. However, scrolling is occurring when not necessary, which looks kinda weird https://youtu.be/_YG0XH8XJpI On Wed, 19 Feb 2020 at 01:51, Juri Linkov <juri@linkov.net> wrote: > > >> Seems to fix the issue in a specific situation, viz. after I select a > >> tab manually with the mouse. However, when selecting a buffer that is > >> already visible in the tab-line the tab-line still might get scrolled > >> or if I just scroll the tab-line and change to a non-visible buffer > >> the tab-line doesn't get scrolled. I'm a bit interested in knowing the > >> reasoning to not always scroll the tab-line. > > > > While you're manually scrolling the tab-line using the mouse wheel > > or clicking on arrow buttons, auto-scrolling should be disabled > > because it should not bring the current tab back into view immediately > > on every step of manual scrolling. Just imagine that you clicked > > on the arrow button to scroll, but it has no effect because auto-scrolling > > immediately moved the tab-line back to its original state. > > This is why auto-scrolling should be disabled during manual scrolling. > > > > Now the question: how to detect the moment when you stop manually > > scrolling? How would you indicate that manual scrolling is finished, > > and it's time to enable auto-scrolling to bring the currently selected tab > > back into view? I have no idea. > > Actually, I have an idea - the right moment is when the current buffer > changes on the current tab. This patch is the right way to handle this case: > > diff --git a/lisp/tab-line.el b/lisp/tab-line.el > index 86ac234f3d..ad2b167e33 100644 > --- a/lisp/tab-line.el > +++ b/lisp/tab-line.el > @@ -464,6 +464,13 @@ tab-line-format > (window-buffer) > (window-parameter nil 'tab-line-hscroll))) > (cache (window-parameter nil 'tab-line-cache))) > + ;; Enable auto-hscroll again after it was disabled on manual scrolling. > + ;; The moment to enable it is when the window-buffer was updated. > + (when (and tab-line-auto-hscroll ; if auto-hscroll was enabled > + (natnump (nth 2 cache-key)) ; non-negative on manual scroll > + cache ; window-buffer was updated > + (not (equal (nth 1 (car cache)) (nth 1 cache-key)))) > + (set-window-parameter nil 'tab-line-hscroll nil)) > (or (and cache (equal (car cache) cache-key) (cdr cache)) > (cdr (set-window-parameter > nil 'tab-line-cache ^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#39649: 27.0.60; tab-line doesn't scroll 2020-02-19 20:57 ` João Guerra @ 2020-02-20 23:07 ` Juri Linkov 2020-02-21 1:34 ` Noam Postavsky 0 siblings, 1 reply; 32+ messages in thread From: Juri Linkov @ 2020-02-20 23:07 UTC (permalink / raw) To: João Guerra; +Cc: 39649 > This seems better to me. However, scrolling is occurring when not > necessary, which looks kinda weird https://youtu.be/_YG0XH8XJpI Thanks for the detailed visual bug reports - it's clear now what should be fixed. The following patch provides almost prefect behavior with only one exception: it fails to switch back from manual scrolling to automatic scrolling when the tab-line is at its beginning, showing the first tab. The problem is that in Emacs there is no such thing as negative zero. I don't understand why Emacs doesn't support signed zero. For example in JavaScript: Math.sign(-0) => -0 Signed zero would help in the auto-hscroll implementation where positive integers encode positions of manual scrolling and negative integers encode positions of automatic scrolling. And switching from manual to automatic just changes the sign. But since positions count from zero, there is no way to distinguish manual scrolling position from automatic scrolling position at the beginning of the tab-line. I have no idea how to overcome this limitation. diff --git a/lisp/tab-line.el b/lisp/tab-line.el index 8f1221abe4..70ca7e2204 100644 --- a/lisp/tab-line.el +++ b/lisp/tab-line.el @@ -464,6 +466,13 @@ tab-line-format (window-buffer) (window-parameter nil 'tab-line-hscroll))) (cache (window-parameter nil 'tab-line-cache))) + ;; Enable auto-hscroll again after it was disabled on manual scrolling. + ;; The moment to enable it is when the window-buffer was updated. + (when (and tab-line-auto-hscroll ; if auto-hscroll was enabled + (natnump (nth 2 cache-key)) ; non-negative on manual scroll + cache ; window-buffer was updated + (not (equal (nth 1 (car cache)) (nth 1 cache-key)))) + (set-window-parameter nil 'tab-line-hscroll (- (nth 2 cache-key)))) (or (and cache (equal (car cache) cache-key) (cdr cache)) (cdr (set-window-parameter nil 'tab-line-cache ^ permalink raw reply related [flat|nested] 32+ messages in thread
* bug#39649: 27.0.60; tab-line doesn't scroll 2020-02-20 23:07 ` Juri Linkov @ 2020-02-21 1:34 ` Noam Postavsky 2020-02-22 23:52 ` Juri Linkov 0 siblings, 1 reply; 32+ messages in thread From: Noam Postavsky @ 2020-02-21 1:34 UTC (permalink / raw) To: Juri Linkov; +Cc: 39649, João Guerra Juri Linkov <juri@linkov.net> writes: > I don't understand why Emacs doesn't support signed zero. > For example in JavaScript: Math.sign(-0) => -0 It does, for floats (afaik, in JavaScript all numbers are floating point). (copysign 1.0 -0.0) ;=> -1.0 ^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#39649: 27.0.60; tab-line doesn't scroll 2020-02-21 1:34 ` Noam Postavsky @ 2020-02-22 23:52 ` Juri Linkov 2020-02-23 10:35 ` João Guerra 0 siblings, 1 reply; 32+ messages in thread From: Juri Linkov @ 2020-02-22 23:52 UTC (permalink / raw) To: Noam Postavsky; +Cc: 39649, João Guerra [-- Attachment #1: Type: text/plain, Size: 407 bytes --] >> I don't understand why Emacs doesn't support signed zero. >> For example in JavaScript: Math.sign(-0) => -0 > > It does, for floats (afaik, in JavaScript all numbers are floating > point). > > (copysign 1.0 -0.0) ;=> -1.0 Then if take into use floats, the distinction could be not between positive/negative floats, but between integers/floats. João, could you please try a new patch: [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: tab-line-auto-hscroll.patch --] [-- Type: text/x-diff, Size: 5217 bytes --] diff --git a/lisp/tab-line.el b/lisp/tab-line.el index 8f1221abe4..754a0a95ab 100644 --- a/lisp/tab-line.el +++ b/lisp/tab-line.el @@ -446,17 +446,19 @@ tab-line-format-template (setq hscroll nil) (set-window-parameter nil 'tab-line-hscroll hscroll)) (list separator - (when (and (integerp hscroll) (not (zerop hscroll))) + (when (and (numberp hscroll) (not (zerop hscroll))) tab-line-left-button) - (when (if (integerp hscroll) - (< (abs hscroll) (1- (length strings))) + (when (if (numberp hscroll) + (< (truncate hscroll) (1- (length strings))) (> (length strings) 1)) tab-line-right-button))) - (if hscroll (nthcdr (abs hscroll) strings) strings) + (if hscroll (nthcdr (truncate hscroll) strings) strings) (when (eq tab-line-tabs-function #'tab-line-tabs-window-buffers) (list (concat separator (when tab-line-new-tab-choice tab-line-new-button))))))) +(defvar tab-line-auto-hscroll) + (defun tab-line-format () "Template for displaying tab line for selected window." (let* ((tabs (funcall tab-line-tabs-function)) @@ -464,6 +466,13 @@ tab-line-format (window-buffer) (window-parameter nil 'tab-line-hscroll))) (cache (window-parameter nil 'tab-line-cache))) + ;; Enable auto-hscroll again after it was disabled on manual scrolling. + ;; The moment to enable it is when the window-buffer was updated. + (when (and tab-line-auto-hscroll ; if auto-hscroll was enabled + (integerp (nth 2 cache-key)) ; integer on manual scroll + cache ; window-buffer was updated + (not (equal (nth 1 (car cache)) (nth 1 cache-key)))) + (set-window-parameter nil 'tab-line-hscroll (float (nth 2 cache-key)))) (or (and cache (equal (car cache) cache-key) (cdr cache)) (cdr (set-window-parameter nil 'tab-line-cache @@ -490,12 +499,12 @@ tab-line-auto-hscroll ;; Continuation means tab-line doesn't fit completely, ;; thus scroll arrows are needed for scrolling. (setq show-arrows (> (vertical-motion 1) 0)) - ;; Try to auto-scroll only when scrolling is needed, + ;; Try to auto-hscroll only when scrolling is needed, ;; but no manual scrolling was performed before. (when (and tab-line-auto-hscroll show-arrows ;; Do nothing when scrolled manually - (not (and (integerp hscroll) (>= hscroll 0)))) + (not (integerp hscroll))) (let ((selected (seq-position strings 'selected (lambda (str prop) (get-pos-property 1 prop str))))) @@ -503,7 +512,7 @@ tab-line-auto-hscroll ((null selected) ;; Do nothing if no tab is selected ) - ((or (not (integerp hscroll)) (< selected (abs hscroll))) + ((or (not (numberp hscroll)) (< selected (truncate hscroll))) ;; Selected is scrolled to the left, or no scrolling yet (erase-buffer) (apply 'insert (reverse (seq-subseq strings 0 (1+ selected)))) @@ -520,14 +529,14 @@ tab-line-auto-hscroll (lambda (str tab) (eq (get-pos-property 1 'tab str) tab)))))) (when new-hscroll - (setq hscroll (- new-hscroll)) + (setq hscroll (float new-hscroll)) (set-window-parameter nil 'tab-line-hscroll hscroll))) (setq hscroll nil) (set-window-parameter nil 'tab-line-hscroll hscroll))) (t ;; Check if the selected tab is already visible (erase-buffer) - (apply 'insert (seq-subseq strings (abs hscroll) (1+ selected))) + (apply 'insert (seq-subseq strings (truncate hscroll) (1+ selected))) (goto-char (point-min)) (add-face-text-property (point-min) (point-max) 'tab-line) (when (> (vertical-motion 1) 0) @@ -547,7 +556,7 @@ tab-line-auto-hscroll (lambda (str tab) (eq (get-pos-property 1 'tab str) tab)))))) (when new-hscroll - (setq hscroll (- new-hscroll)) + (setq hscroll (float new-hscroll)) (set-window-parameter nil 'tab-line-hscroll hscroll))))))))) (list show-arrows hscroll)))) @@ -559,7 +568,7 @@ tab-line-hscroll (funcall tab-line-tabs-function)))) (set-window-parameter window 'tab-line-hscroll - (max 0 (min (+ (if (integerp hscroll) (abs hscroll) 0) (or arg 1)) + (max 0 (min (+ (if (numberp hscroll) (truncate hscroll) 0) (or arg 1)) (1- (length tabs))))) (when window (force-mode-line-update t)))) ^ permalink raw reply related [flat|nested] 32+ messages in thread
* bug#39649: 27.0.60; tab-line doesn't scroll 2020-02-22 23:52 ` Juri Linkov @ 2020-02-23 10:35 ` João Guerra 2020-02-23 23:06 ` Juri Linkov 0 siblings, 1 reply; 32+ messages in thread From: João Guerra @ 2020-02-23 10:35 UTC (permalink / raw) To: Juri Linkov; +Cc: 39649, Noam Postavsky Regarding the scrolling this seems more natural to me or at least more similar to most applications and thus to the expectations most people might have regarding scrolling file tabs. I did find a bug, didn't test if it was there before already: https://youtu.be/EAM581LO__8 On Sun, 23 Feb 2020 at 01:44, Juri Linkov <juri@linkov.net> wrote: > > >> I don't understand why Emacs doesn't support signed zero. > >> For example in JavaScript: Math.sign(-0) => -0 > > > > It does, for floats (afaik, in JavaScript all numbers are floating > > point). > > > > (copysign 1.0 -0.0) ;=> -1.0 > > Then if take into use floats, the distinction could be > not between positive/negative floats, but between integers/floats. > > João, could you please try a new patch: > ^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#39649: 27.0.60; tab-line doesn't scroll 2020-02-23 10:35 ` João Guerra @ 2020-02-23 23:06 ` Juri Linkov 2020-02-24 19:11 ` João Guerra 0 siblings, 1 reply; 32+ messages in thread From: Juri Linkov @ 2020-02-23 23:06 UTC (permalink / raw) To: João Guerra; +Cc: 39649, Noam Postavsky > Regarding the scrolling this seems more natural to me or at least more > similar to most applications and thus to the expectations most people > might have regarding scrolling file tabs. Yes, I agree. > I did find a bug, didn't test if it was there before already: > https://youtu.be/EAM581LO__8 Thanks, I tried to reproduce the bug, but it's not reproducible. Maybe it depends on your customization. I see that you customizied tab-line-tabs-function to "Same mode buffers" (tab-line-tabs-mode-buffers). But what about other tab-line customizations? Please send your tab-line faces customizations. I guess the bug depends on tab-line faces. Or you could try to reproduce the bug with default settings by 'emacs -Q'. ^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#39649: 27.0.60; tab-line doesn't scroll 2020-02-23 23:06 ` Juri Linkov @ 2020-02-24 19:11 ` João Guerra 2020-02-25 21:20 ` Juri Linkov 0 siblings, 1 reply; 32+ messages in thread From: João Guerra @ 2020-02-24 19:11 UTC (permalink / raw) To: Juri Linkov; +Cc: 39649, Noam Postavsky I have the same issue with `emacs -q` and `(setq tab-line-tabs-function #'tab-line-tabs-mode-buffers)` on GNU Emacs 27.0.60 (build 1, x86_64-w64-mingw32) of 2020-02-10. On Mon, 24 Feb 2020 at 00:51, Juri Linkov <juri@linkov.net> wrote: > > > Regarding the scrolling this seems more natural to me or at least more > > similar to most applications and thus to the expectations most people > > might have regarding scrolling file tabs. > > Yes, I agree. > > > I did find a bug, didn't test if it was there before already: > > https://youtu.be/EAM581LO__8 > > Thanks, I tried to reproduce the bug, but it's not reproducible. > Maybe it depends on your customization. > > I see that you customizied tab-line-tabs-function to "Same mode buffers" > (tab-line-tabs-mode-buffers). But what about other tab-line customizations? > Please send your tab-line faces customizations. I guess the bug depends > on tab-line faces. Or you could try to reproduce the bug with default > settings by 'emacs -Q'. ^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#39649: 27.0.60; tab-line doesn't scroll 2020-02-24 19:11 ` João Guerra @ 2020-02-25 21:20 ` Juri Linkov 2020-02-25 21:49 ` João Guerra 2020-02-28 13:16 ` Eli Zaretskii 0 siblings, 2 replies; 32+ messages in thread From: Juri Linkov @ 2020-02-25 21:20 UTC (permalink / raw) To: João Guerra; +Cc: 39649 Please help to understand how to reproduce this bug: > I have the same issue with `emacs -q` Have you tried `emacs -Q`? I don't know if there is any difference between `emacs -Q` and `emacs -q` on Windows. But `emacs -q` loads all resources so maybe it loads additional face definitions for tab-line. I see that left/right arrows in your bug report are XPM images. But I don't understand how this is possible because (info "(efaq-w32) Image support") says that Emacs has no built-in support for XPM on Windows. Please try to reproduce the same bug without XPM images by evaluating these lines: (setq tab-line-left-button " <") (setq tab-line-right-button "> ") Also it's possible that maybe the widths of these buttons affect the calculations somehow. Please also try to remove these arrow buttons temporarily with: (setq tab-line-left-button nil) (setq tab-line-right-button nil) Do you see the same bug? > on GNU Emacs 27.0.60 (build 1, x86_64-w64-mingw32) of 2020-02-10. The compilation date is 2020-02-10. Did you apply the patch that I sent? I could commit the patch, then you could update your repository if you want. ^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#39649: 27.0.60; tab-line doesn't scroll 2020-02-25 21:20 ` Juri Linkov @ 2020-02-25 21:49 ` João Guerra 2020-02-26 23:16 ` Juri Linkov 2020-02-28 13:16 ` Eli Zaretskii 1 sibling, 1 reply; 32+ messages in thread From: João Guerra @ 2020-02-25 21:49 UTC (permalink / raw) To: Juri Linkov; +Cc: 39649 It does have your patch, but just the latest one in this thread. Video demonstration: https://youtu.be/xq_JMBO4SyI. I'm using Emacs from https://alpha.gnu.org/gnu/emacs/pretest/windows/emacs-27/. It does have XPM support. Issue still happens when I do (setq tab-line-left-button nil) (setq tab-line-right-button nil) On Tue, 25 Feb 2020 at 22:33, Juri Linkov <juri@linkov.net> wrote: > > Please help to understand how to reproduce this bug: > > > I have the same issue with `emacs -q` > > Have you tried `emacs -Q`? > I don't know if there is any difference between > `emacs -Q` and `emacs -q` on Windows. But `emacs -q` > loads all resources so maybe it loads additional > face definitions for tab-line. > > I see that left/right arrows in your bug report are XPM images. > But I don't understand how this is possible because > (info "(efaq-w32) Image support") says that Emacs has > no built-in support for XPM on Windows. > > Please try to reproduce the same bug without XPM images > by evaluating these lines: > > (setq tab-line-left-button " <") > (setq tab-line-right-button "> ") > > Also it's possible that maybe the widths of these buttons > affect the calculations somehow. > > Please also try to remove these arrow buttons temporarily with: > > (setq tab-line-left-button nil) > (setq tab-line-right-button nil) > > Do you see the same bug? > > > on GNU Emacs 27.0.60 (build 1, x86_64-w64-mingw32) of 2020-02-10. > > The compilation date is 2020-02-10. > Did you apply the patch that I sent? > I could commit the patch, then you could > update your repository if you want. ^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#39649: 27.0.60; tab-line doesn't scroll 2020-02-25 21:49 ` João Guerra @ 2020-02-26 23:16 ` Juri Linkov 2020-02-26 23:33 ` Juri Linkov 2020-02-27 21:13 ` João Guerra 0 siblings, 2 replies; 32+ messages in thread From: Juri Linkov @ 2020-02-26 23:16 UTC (permalink / raw) To: João Guerra; +Cc: 39649 [-- Attachment #1: Type: text/plain, Size: 792 bytes --] > It does have your patch, but just the latest one in this thread. > Video demonstration: https://youtu.be/xq_JMBO4SyI. > I'm using Emacs from > https://alpha.gnu.org/gnu/emacs/pretest/windows/emacs-27/. It does > have XPM support. Thanks for the recipe. I tried everything possible, but still no bug reproduction. Given the above, may I ask you to run some debugging diagnostics: 1. load the attached file, e.g. with M-x load-file 2. M-x global-tab-line-mode 3. perform all steps from your bug report 4. after the last step, when the tab selection fails, execute M-x test1 RET and make a screenshot. The screenshot should look like on the image attached. I suspect that the problem comes from the tab-line fontified differently by core and when fontified manually in the buffer. [-- Attachment #2: screenshot1.png --] [-- Type: image/png, Size: 22200 bytes --] [-- Attachment #3: tab-line-1.el --] [-- Type: application/emacs-lisp, Size: 34051 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#39649: 27.0.60; tab-line doesn't scroll 2020-02-26 23:16 ` Juri Linkov @ 2020-02-26 23:33 ` Juri Linkov 2020-02-28 9:12 ` Eli Zaretskii 2020-02-27 21:13 ` João Guerra 1 sibling, 1 reply; 32+ messages in thread From: Juri Linkov @ 2020-02-26 23:33 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 39649, João Guerra > I suspect that the problem comes from the tab-line fontified differently > by core and when fontified manually in the buffer. Eli, could you explain why there no wrapper around the C function display_mode_element exposed to Lisp. The closest function is format-mode-line but still its formatting is different from what display_mode_element really displays in the tab-line. Steps to reproduce the problem: 1. emacs -Q 2. M-x global-tab-line-mode 3. C-x b test1 4. M-: (insert (format-mode-line (tab-line-format))) 5. Note how the tab uses the face tab-line-tab with released-button box style, but the tab-line doesn't use the face tab-line 6. C-x b test2 7. M-: (insert (format-mode-line (tab-line-format) 'tab-line)) 8. Note how the the tab-line now uses the face tab-line, but this face overrides the faces of individual tabs that should have the face tab-line-tab with released-button box style. I can't find a function that would insert to the current buffer a string formatted exactly as the tab-line displayed above the window. ^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#39649: 27.0.60; tab-line doesn't scroll 2020-02-26 23:33 ` Juri Linkov @ 2020-02-28 9:12 ` Eli Zaretskii 2020-02-29 21:44 ` Juri Linkov 0 siblings, 1 reply; 32+ messages in thread From: Eli Zaretskii @ 2020-02-28 9:12 UTC (permalink / raw) To: Juri Linkov; +Cc: 39649, joca.bt > From: Juri Linkov <juri@linkov.net> > Cc: João Guerra <joca.bt@gmail.com>, > 39649@debbugs.gnu.org > Date: Thu, 27 Feb 2020 01:33:00 +0200 > > > I suspect that the problem comes from the tab-line fontified differently > > by core and when fontified manually in the buffer. > > Eli, could you explain why there no wrapper around the C function > display_mode_element exposed to Lisp. Why would we need that? The related display code is in C, so we never needed to expose this to Lisp. I also don't understand the relation between this question and the recipes you show. > The closest function is format-mode-line but still its formatting is > different from what display_mode_element really displays in the > tab-line. Why is that a problem? format-mode-line was not intended to be used in display context. > 1. emacs -Q > 2. M-x global-tab-line-mode > > 3. C-x b test1 > 4. M-: (insert (format-mode-line (tab-line-format))) > 5. Note how the tab uses the face tab-line-tab > with released-button box style, but the tab-line > doesn't use the face tab-line I don't see tab-line-tab face, I see either tab-line-tab-inactive or tab-line-tab-current. And the button style and its mouse-sensitive behavior follows what I see on the real tab-line. But maybe I don't understand what you allude to here. What is the "tab" in this context, and what is "tab-line"? You have one inserted into buffer text and one displayed on header-line-like tab-line -- which one do you allude to here? And why do you think what is displayed is some kind of problem? > 6. C-x b test2 > 7. M-: (insert (format-mode-line (tab-line-format) 'tab-line)) > 8. Note how the the tab-line now uses the face tab-line, > but this face overrides the faces of individual tabs that > should have the face tab-line-tab with released-button box style. And here I don't understand what you mean by "overrides". > I can't find a function that would insert to the current buffer > a string formatted exactly as the tab-line displayed > above the window. Why is that needed? P.S. I did all the testing in Emacs 27.0.90, the latest emacs-27 branch. Thanks. ^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#39649: 27.0.60; tab-line doesn't scroll 2020-02-28 9:12 ` Eli Zaretskii @ 2020-02-29 21:44 ` Juri Linkov 2020-03-01 16:12 ` Eli Zaretskii 0 siblings, 1 reply; 32+ messages in thread From: Juri Linkov @ 2020-02-29 21:44 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 39649, joca.bt > Why would we need that? The related display code is in C, so we never > needed to expose this to Lisp. format-mode-line already exposes it, but fails to properly handle its arg FACE. > I also don't understand the relation between this question and the > recipes you show. format-mode-line can be used to get the same formatted string as is displayed on the tab-line. >> The closest function is format-mode-line but still its formatting is >> different from what display_mode_element really displays in the >> tab-line. > > Why is that a problem? format-mode-line was not intended to be used > in display context. format-mode-line does the right thing for this task, but its handling of the arg FACE is broken. >> 1. emacs -Q >> 2. M-x global-tab-line-mode >> >> 3. C-x b test1 >> 4. M-: (insert (format-mode-line (tab-line-format))) >> 5. Note how the tab uses the face tab-line-tab >> with released-button box style, but the tab-line >> doesn't use the face tab-line > > I don't see tab-line-tab face, I see either tab-line-tab-inactive or > tab-line-tab-current. And the button style and its mouse-sensitive > behavior follows what I see on the real tab-line. This is correct, I meant tab-line-tab-inactive and tab-line-tab-current that inherit from tab-line-tab. > But maybe I don't understand what you allude to here. What is the > "tab" in this context, and what is "tab-line"? You have one inserted > into buffer text and one displayed on header-line-like tab-line -- > which one do you allude to here? And why do you think what is > displayed is some kind of problem? "tab-line" visually should have an appearance defined by the face "tab-line", i.e. grey background that can be seen at whitespace between tabs, like in the case below. There is no problem here. The real problem is below. >> 6. C-x b test2 >> 7. M-: (insert (format-mode-line (tab-line-format) 'tab-line)) >> 8. Note how the the tab-line now uses the face tab-line, >> but this face overrides the faces of individual tabs that >> should have the face tab-line-tab with released-button box style. > > And here I don't understand what you mean by "overrides". Do you see the same button styles with the faces tab-line-tab-inactive and tab-line-tab-current as in the case above like they are on the real tab-line? These faces are lost when the arg FACE is specified. >> I can't find a function that would insert to the current buffer >> a string formatted exactly as the tab-line displayed >> above the window. > > Why is that needed? Actually, no other function needed. format-mode-line does it job, but doesn't handle its arg FACE correctly. No wonder that handling of its arg FACE is not yet implemented. I grepped the Emacs source code, and none of format-mode-line function calls uses the arg FACE. João said that everything already works, so this is not a problem for the Emacs 27 release. But in master format-mode-line could be fixed to implement better merging of its arg FACE with faces already existing on strings given in its arg FORMAT. ^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#39649: 27.0.60; tab-line doesn't scroll 2020-02-29 21:44 ` Juri Linkov @ 2020-03-01 16:12 ` Eli Zaretskii 2020-03-01 23:40 ` Juri Linkov 0 siblings, 1 reply; 32+ messages in thread From: Eli Zaretskii @ 2020-03-01 16:12 UTC (permalink / raw) To: Juri Linkov; +Cc: 39649, joca.bt > From: Juri Linkov <juri@linkov.net> > Cc: joca.bt@gmail.com, 39649@debbugs.gnu.org > Date: Sat, 29 Feb 2020 23:44:56 +0200 > > > Why would we need that? The related display code is in C, so we never > > needed to expose this to Lisp. > > format-mode-line already exposes it, but fails to properly > handle its arg FACE. So you are saying that we already have the API exposed to Lisp, but it (format-mode-line) doesn't work well? > >> 6. C-x b test2 > >> 7. M-: (insert (format-mode-line (tab-line-format) 'tab-line)) > >> 8. Note how the the tab-line now uses the face tab-line, > >> but this face overrides the faces of individual tabs that > >> should have the face tab-line-tab with released-button box style. > > > > And here I don't understand what you mean by "overrides". > > Do you see the same button styles with the faces tab-line-tab-inactive and > tab-line-tab-current as in the case above like they are on the real tab-line? > These faces are lost when the arg FACE is specified. I don't think this is a bug, the code behaves as intended. It's just that its intent might be not what you expect, and the available documentation doesn't help to expect what the code does. The doc string says, inter alia: Optional second arg FACE specifies the face property to put on all characters for which no face is specified. But what it really means is that text produced by the various %-constructs will have FACE if the %-constructs don't provide a face. In your case, you supply the function with a fixed string, so specifying FACE overrides the faces you have there, see store_mode_line_string (which is called in this case with PROPS set to nil). At this point let me turn the table and ask why did you need to pass FACE to format-mode-line in your case? What did you want to achieve? ^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#39649: 27.0.60; tab-line doesn't scroll 2020-03-01 16:12 ` Eli Zaretskii @ 2020-03-01 23:40 ` Juri Linkov 2020-09-20 8:40 ` Lars Ingebrigtsen 0 siblings, 1 reply; 32+ messages in thread From: Juri Linkov @ 2020-03-01 23:40 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 39649, joca.bt >> format-mode-line already exposes it, but fails to properly >> handle its arg FACE. > > So you are saying that we already have the API exposed to Lisp, but it > (format-mode-line) doesn't work well? Exactly. >> Do you see the same button styles with the faces tab-line-tab-inactive and >> tab-line-tab-current as in the case above like they are on the real tab-line? >> These faces are lost when the arg FACE is specified. > > I don't think this is a bug, the code behaves as intended. It's just > that its intent might be not what you expect, and the available > documentation doesn't help to expect what the code does. > > The doc string says, inter alia: > > Optional second arg FACE specifies the face property to put on all > characters for which no face is specified. It says "no face is specified", but actually the face is specified on all characters of tabs, and the implementation doesn't follow the documentation, e.g.: (tab-line-format) => (#(" tab1 x" 1 5 (face tab-line-tab-current))) ==================== The face 'tab-line-tab-current' is on all characters, yet (format-mode-line (tab-line-format) 'tab-line) overwrites the face 'tab-line-tab-current' with the face 'tab-line': (format-mode-line (tab-line-format) 'tab-line) => #(" tab1 x" 1 5 (face tab-line)) ======== > But what it really means is that text produced by the various > %-constructs will have FACE if the %-constructs don't provide a face. > In your case, you supply the function with a fixed string, so > specifying FACE overrides the faces you have there, see > store_mode_line_string (which is called in this case with PROPS set to > nil). Trying to find the minimal test case, it seems working correctly by merging faces, so there is no bug in the simplest case: (format-mode-line (propertize "tab1" 'face 'tab-line-tab-current)) => #("tab1" 0 4 (face tab-line-tab-current)) (format-mode-line (propertize "tab1" 'face 'tab-line-tab-current) 'tab-line) => #("tab1" 0 4 (face (tab-line-tab-current tab-line))) In the above case tab-line-tab-current and tab-line are merged. But the bug creeps in only when there is space between tabs: (format-mode-line (concat " " (propertize "tab1" 'face 'tab-line-tab-current) " x")) #(" tab1 x" 1 5 (face tab-line-tab-current)) (format-mode-line (concat " " (propertize "tab1" 'face 'tab-line-tab-current) " x") 'tab-line) #(" tab1 x" 0 1 (face tab-line) 1 5 (face tab-line) 5 7 (face tab-line)) Here the face 'tab-line' overwrites the face 'tab-line-tab-current'. > At this point let me turn the table and ask why did you need to pass > FACE to format-mode-line in your case? What did you want to achieve? With the arg FACE it should have the same look as on the real tab-line where tabs are placed on the line that already has the face 'tab-line'. ^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#39649: 27.0.60; tab-line doesn't scroll 2020-03-01 23:40 ` Juri Linkov @ 2020-09-20 8:40 ` Lars Ingebrigtsen 0 siblings, 0 replies; 32+ messages in thread From: Lars Ingebrigtsen @ 2020-09-20 8:40 UTC (permalink / raw) To: Juri Linkov; +Cc: 39649, joca.bt Juri Linkov <juri@linkov.net> writes: > But the bug creeps in only when there is space between tabs: > > (format-mode-line (concat " " (propertize "tab1" 'face > 'tab-line-tab-current) " x")) > #(" tab1 x" 1 5 (face tab-line-tab-current)) > > (format-mode-line (concat " " (propertize "tab1" 'face > 'tab-line-tab-current) " x") 'tab-line) > #(" tab1 x" 0 1 (face tab-line) 1 5 (face tab-line) 5 7 (face tab-line)) > > Here the face 'tab-line' overwrites the face 'tab-line-tab-current'. The mode-line formatting machinery doesn't support having a mixture of text properties over a single string -- for efficiency, it assumes that the same properties are used over the entire string. If you want something else, you unfortunately have to use :propertize or a list of strings. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#39649: 27.0.60; tab-line doesn't scroll 2020-02-26 23:16 ` Juri Linkov 2020-02-26 23:33 ` Juri Linkov @ 2020-02-27 21:13 ` João Guerra 2020-02-27 22:37 ` Juri Linkov 1 sibling, 1 reply; 32+ messages in thread From: João Guerra @ 2020-02-27 21:13 UTC (permalink / raw) To: Juri Linkov; +Cc: 39649 1. emacs -Q 2. M-x load-file tab-line-1.el 3. M-x global-tab-line-mode 4. M-: (setq tab-line-tabs-function #'tab-line-tabs-mode-buffers) 5. https://youtu.be/fQlrP0dlBbw On Thu, 27 Feb 2020 at 00:19, Juri Linkov <juri@linkov.net> wrote: > > > It does have your patch, but just the latest one in this thread. > > Video demonstration: https://youtu.be/xq_JMBO4SyI. > > I'm using Emacs from > > https://alpha.gnu.org/gnu/emacs/pretest/windows/emacs-27/. It does > > have XPM support. > > Thanks for the recipe. I tried everything possible, but still > no bug reproduction. > > Given the above, may I ask you to run some debugging diagnostics: > > 1. load the attached file, e.g. with M-x load-file > 2. M-x global-tab-line-mode > 3. perform all steps from your bug report > 4. after the last step, when the tab selection fails, execute > > M-x test1 RET > > and make a screenshot. The screenshot should look like on the image attached. > > I suspect that the problem comes from the tab-line fontified differently > by core and when fontified manually in the buffer. > ^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#39649: 27.0.60; tab-line doesn't scroll 2020-02-27 21:13 ` João Guerra @ 2020-02-27 22:37 ` Juri Linkov 2020-02-28 18:30 ` João Guerra 0 siblings, 1 reply; 32+ messages in thread From: Juri Linkov @ 2020-02-27 22:37 UTC (permalink / raw) To: João Guerra; +Cc: 39649 > 1. emacs -Q > 2. M-x load-file tab-line-1.el > 3. M-x global-tab-line-mode > 4. M-: (setq tab-line-tabs-function #'tab-line-tabs-mode-buffers) > 5. https://youtu.be/fQlrP0dlBbw Thanks, now it's clear where the problem is: the buffer *Messages* shows that old code is loaded, i.e. first you load the new file tab-line-1.el (the first line in the buffer *Messages*), but later its functions are overridden by old file (the third line in the buffer *Messages*). Only the new command 'test1' remains loaded, all other functions are overridden from old file tab-line.el. I believe this could be solved by changing the loading order: 1. emacs -Q 2. M-x global-tab-line-mode - this will load old file tab-line.el 3. M-x load-file tab-line-1.el - old functions will be overridden by new file tab-line-1.el Please try this. ^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#39649: 27.0.60; tab-line doesn't scroll 2020-02-27 22:37 ` Juri Linkov @ 2020-02-28 18:30 ` João Guerra 2020-02-29 21:49 ` Juri Linkov 0 siblings, 1 reply; 32+ messages in thread From: João Guerra @ 2020-02-28 18:30 UTC (permalink / raw) To: Juri Linkov; +Cc: 39649 Issue no longer exists when I load your file in the end (ie. after enabling the mode and customizing tab-line-tabs-function). On Thu, 27 Feb 2020 at 23:39, Juri Linkov <juri@linkov.net> wrote: > > > 1. emacs -Q > > 2. M-x load-file tab-line-1.el > > 3. M-x global-tab-line-mode > > 4. M-: (setq tab-line-tabs-function #'tab-line-tabs-mode-buffers) > > 5. https://youtu.be/fQlrP0dlBbw > > Thanks, now it's clear where the problem is: > the buffer *Messages* shows that old code is loaded, > i.e. first you load the new file tab-line-1.el > (the first line in the buffer *Messages*), > but later its functions are overridden by old file > (the third line in the buffer *Messages*). > Only the new command 'test1' remains loaded, > all other functions are overridden from old file > tab-line.el. > > I believe this could be solved by changing the loading order: > > 1. emacs -Q > 2. M-x global-tab-line-mode > - this will load old file tab-line.el > 3. M-x load-file tab-line-1.el > - old functions will be overridden by new file tab-line-1.el > > Please try this. ^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#39649: 27.0.60; tab-line doesn't scroll 2020-02-28 18:30 ` João Guerra @ 2020-02-29 21:49 ` Juri Linkov 2020-03-04 17:25 ` João Guerra 2020-09-20 8:41 ` Lars Ingebrigtsen 0 siblings, 2 replies; 32+ messages in thread From: Juri Linkov @ 2020-02-29 21:49 UTC (permalink / raw) To: João Guerra; +Cc: 39649 > Issue no longer exists when I load your file in the end (ie. after > enabling the mode and customizing tab-line-tabs-function). Thanks for checking, fix pushed. If you want, could you try it again after the next Windows pretest will be released (maybe after a few weeks, this is not strictly necessary, but could confirm that there are really no more problems). ^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#39649: 27.0.60; tab-line doesn't scroll 2020-02-29 21:49 ` Juri Linkov @ 2020-03-04 17:25 ` João Guerra 2020-03-04 23:52 ` Juri Linkov 2020-09-20 8:41 ` Lars Ingebrigtsen 1 sibling, 1 reply; 32+ messages in thread From: João Guerra @ 2020-03-04 17:25 UTC (permalink / raw) To: Juri Linkov; +Cc: 39649 [-- Attachment #1: Type: text/plain, Size: 906 bytes --] I came across something that feels a bit odd in tab-line, maybe you can explain it. I've been playing around with tab-line-format and noticed that what gets displayed in the tab-line actually differs based on whether you are using the `tab-line' face or not. See the attached picture. Both Emacs were launched with -Q. Although the face definition is the same in both situations the result is different. Specially the rendered size of the characters. On Sat, 29 Feb 2020 at 22:51, Juri Linkov <juri@linkov.net> wrote: > > > Issue no longer exists when I load your file in the end (ie. after > > enabling the mode and customizing tab-line-tabs-function). > > Thanks for checking, fix pushed. > > If you want, could you try it again after the next Windows pretest will be released > (maybe after a few weeks, this is not strictly necessary, but could confirm > that there are really no more problems). [-- Attachment #2: tab-line.png --] [-- Type: image/png, Size: 49391 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#39649: 27.0.60; tab-line doesn't scroll 2020-03-04 17:25 ` João Guerra @ 2020-03-04 23:52 ` Juri Linkov 2020-03-05 8:04 ` João Guerra 0 siblings, 1 reply; 32+ messages in thread From: Juri Linkov @ 2020-03-04 23:52 UTC (permalink / raw) To: João Guerra; +Cc: 39649 > I came across something that feels a bit odd in tab-line, maybe you > can explain it. > > I've been playing around with tab-line-format and noticed that what > gets displayed in the tab-line actually differs based on whether you > are using the `tab-line' face or not. > > See the attached picture. Both Emacs were launched with -Q. Although > the face definition is the same in both situations the result is > different. Specially the rendered size of the characters. This is how mode-line/header-line/tab-line work - they always use hard-coded faces with names 'mode-line', 'header-line', 'tab-line', so you can override face definitions only by customizing these faces. ^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#39649: 27.0.60; tab-line doesn't scroll 2020-03-04 23:52 ` Juri Linkov @ 2020-03-05 8:04 ` João Guerra 2020-03-05 23:53 ` Juri Linkov 0 siblings, 1 reply; 32+ messages in thread From: João Guerra @ 2020-03-05 8:04 UTC (permalink / raw) To: Juri Linkov; +Cc: 39649 [-- Attachment #1: Type: text/plain, Size: 838 bytes --] Ok, but how does that impact the characters sizes being different? On Thu, 5 Mar 2020, 01:22 Juri Linkov, <juri@linkov.net> wrote: > > I came across something that feels a bit odd in tab-line, maybe you > > can explain it. > > > > I've been playing around with tab-line-format and noticed that what > > gets displayed in the tab-line actually differs based on whether you > > are using the `tab-line' face or not. > > > > See the attached picture. Both Emacs were launched with -Q. Although > > the face definition is the same in both situations the result is > > different. Specially the rendered size of the characters. > > This is how mode-line/header-line/tab-line work - they always use > hard-coded faces with names 'mode-line', 'header-line', 'tab-line', > so you can override face definitions only by customizing these faces. > [-- Attachment #2: Type: text/html, Size: 1246 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#39649: 27.0.60; tab-line doesn't scroll 2020-03-05 8:04 ` João Guerra @ 2020-03-05 23:53 ` Juri Linkov 0 siblings, 0 replies; 32+ messages in thread From: Juri Linkov @ 2020-03-05 23:53 UTC (permalink / raw) To: João Guerra; +Cc: 39649 > Ok, but how does that impact the characters sizes being different? It's hard to see the differences in characters sizes. Do you see the same problem when using colors? For example: (defface tab-line '((t :background "red")) "") (defface my-tab-line '((t :background "blue")) "") (setq tab-line-format (propertize "abcdef" 'face 'tab-line)) (setq tab-line-format (propertize "abcdef" 'face 'my-tab-line)) ^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#39649: 27.0.60; tab-line doesn't scroll 2020-02-29 21:49 ` Juri Linkov 2020-03-04 17:25 ` João Guerra @ 2020-09-20 8:41 ` Lars Ingebrigtsen 2020-10-14 6:16 ` Lars Ingebrigtsen 1 sibling, 1 reply; 32+ messages in thread From: Lars Ingebrigtsen @ 2020-09-20 8:41 UTC (permalink / raw) To: Juri Linkov; +Cc: 39649, João Guerra Juri Linkov <juri@linkov.net> writes: >> Issue no longer exists when I load your file in the end (ie. after >> enabling the mode and customizing tab-line-tabs-function). > > Thanks for checking, fix pushed. This bug report dealt with several somewhat related issues, but skimming it, it seems like the reported bug was fixed. Is there anything more to be done here, or should this bug report be closed? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#39649: 27.0.60; tab-line doesn't scroll 2020-09-20 8:41 ` Lars Ingebrigtsen @ 2020-10-14 6:16 ` Lars Ingebrigtsen 0 siblings, 0 replies; 32+ messages in thread From: Lars Ingebrigtsen @ 2020-10-14 6:16 UTC (permalink / raw) To: Juri Linkov; +Cc: 39649, João Guerra Lars Ingebrigtsen <larsi@gnus.org> writes: > Juri Linkov <juri@linkov.net> writes: > >>> Issue no longer exists when I load your file in the end (ie. after >>> enabling the mode and customizing tab-line-tabs-function). >> >> Thanks for checking, fix pushed. > > This bug report dealt with several somewhat related issues, but skimming > it, it seems like the reported bug was fixed. Is there anything more to > be done here, or should this bug report be closed? No response in three weeks, so I'm closing this bug report. If there's still any issues to be worked out here, perhaps opening a new bug report would be best. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#39649: 27.0.60; tab-line doesn't scroll 2020-02-25 21:20 ` Juri Linkov 2020-02-25 21:49 ` João Guerra @ 2020-02-28 13:16 ` Eli Zaretskii 1 sibling, 0 replies; 32+ messages in thread From: Eli Zaretskii @ 2020-02-28 13:16 UTC (permalink / raw) To: Juri Linkov; +Cc: 39649, joca.bt > From: Juri Linkov <juri@linkov.net> > Date: Tue, 25 Feb 2020 23:20:10 +0200 > Cc: 39649@debbugs.gnu.org > > I see that left/right arrows in your bug report are XPM images. > But I don't understand how this is possible because > (info "(efaq-w32) Image support") says that Emacs has > no built-in support for XPM on Windows. That's not what the w32 FAQ says. It says this: Emacs has built in support for XBM and PBM/PGM/PPM images. This is sufficient to see the monochrome splash screen and tool-bar icons. Since v22.2, the official precompiled binaries for Windows have bundled libXpm, which is required to display the color versions of those images. IOW, XPM support is not built-in, but MS-Windows binaries of all Emacs versions since v22.2 are distributed with the libXpm library, which allows the w32 build to display XPM images. ^ permalink raw reply [flat|nested] 32+ messages in thread
end of thread, other threads:[~2020-10-14 6:16 UTC | newest] Thread overview: 32+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2020-02-17 18:51 bug#39649: 27.0.60; tab-line doesn't scroll João Guerra 2020-02-17 23:03 ` Juri Linkov 2020-02-18 20:27 ` João Guerra 2020-02-18 22:39 ` Juri Linkov 2020-02-19 0:24 ` Juri Linkov 2020-02-19 20:57 ` João Guerra 2020-02-20 23:07 ` Juri Linkov 2020-02-21 1:34 ` Noam Postavsky 2020-02-22 23:52 ` Juri Linkov 2020-02-23 10:35 ` João Guerra 2020-02-23 23:06 ` Juri Linkov 2020-02-24 19:11 ` João Guerra 2020-02-25 21:20 ` Juri Linkov 2020-02-25 21:49 ` João Guerra 2020-02-26 23:16 ` Juri Linkov 2020-02-26 23:33 ` Juri Linkov 2020-02-28 9:12 ` Eli Zaretskii 2020-02-29 21:44 ` Juri Linkov 2020-03-01 16:12 ` Eli Zaretskii 2020-03-01 23:40 ` Juri Linkov 2020-09-20 8:40 ` Lars Ingebrigtsen 2020-02-27 21:13 ` João Guerra 2020-02-27 22:37 ` Juri Linkov 2020-02-28 18:30 ` João Guerra 2020-02-29 21:49 ` Juri Linkov 2020-03-04 17:25 ` João Guerra 2020-03-04 23:52 ` Juri Linkov 2020-03-05 8:04 ` João Guerra 2020-03-05 23:53 ` Juri Linkov 2020-09-20 8:41 ` Lars Ingebrigtsen 2020-10-14 6:16 ` Lars Ingebrigtsen 2020-02-28 13:16 ` Eli Zaretskii
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).
![[-- Attachment #2: screenshot1.png --] [-- Type: image/png, Size: 22200 bytes --]](../../871rqhj5x2.fsf@mail.linkov.net/2-screenshot1.png){kind=link}
![[-- Attachment #2: tab-line.png --] [-- Type: image/png, Size: 49391 bytes --]](../../CAGiBfP2d4K=NMp68V0c+ydTPxGFMrngbFfrAtv=3YSM56sheqQ@mail.gmail.com/2-tab-line.png){kind=link}