bug#57848: 29.0.50; Problems with private tab-line-tab-name-function

bug#57848: 29.0.50; Problems with private tab-line-tab-name-function

[Michael Heerdegen]

Hello,

(1) When using `tab-line-mode' together with

#+begin_src emacs-lisp
(setq-local tab-line-tab-name-function
            (lambda (_b &optional _bs) "%b"))
#+end_src

I get tabs that are all named equally - all named after the currently
active tab's buffer.

I didn't know that mode-line format sequences are valid.  Are they?  If
they are (would be nice), could we document this, fix the behavior (I
guess the interpretation is done in the context of a wrong current
buffer), and maybe allow all kinds of mode-line-format values, like
lists?

If the interpretation of mode-line format specs is not intended, the
above example should just lead to a literal "%b" tab name.  We would
need to add according escape characters then.


(2) What I actually had tried was to get nicely named tabs for Info
buffers (including the clones created with M-n).

I tried with something like this:

#+begin_src emacs-lisp
(add-hook 'Info-mode-hook
          (defun my-setup-tab-line-for-Info-mode ()
            (tab-line-mode +1)
            (setq-local
             tab-line-tab-name-function
             (lambda (b &optional _bs)
               (with-current-buffer b
                 (apply
                  #'concat
                  (cdr mode-line-buffer-identification)))))))
#+end_src

but with that the tab names are not updated while browsing Info pages.

The problem here seems to be related to the caching mechanism that
doesn't recognize the need to update; invalidating the cache explicitly
like with this very ugly hack:

#+begin_src emacs-lisp
(add-variable-watcher
 'mode-line-buffer-identification
 (defun my-Info-mode-line-buffer-identification-watcher
     (_symbol _newval _operation where)
   (when (and (eq where (current-buffer))
              (derived-mode-p 'Info-mode))
     (set-window-parameter nil 'tab-line-cache nil))))
#+end_src

makes it work.

It would be nice to provide a way to get cases like this work , e.g. by
allowing to specify buffer-local cache key returning functions.

I didn't try the above stuff with the tab bar, but I guess similar
improvements could be implemented for that as well.

TIA,

Michael.


In GNU Emacs 29.0.50 (build 12, x86_64-pc-linux-gnu, X toolkit, cairo
 version 1.16.0, Xaw scroll bars) of 2022-09-16 built on drachen
Repository revision: 833e80a0ef115a3fdc20a9d9a3190caab3b56621
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: Debian GNU/Linux 11 (bullseye)

bug#57848: 29.0.50; Problems with private tab-line-tab-name-function

[Juri Linkov]

> (1) When using `tab-line-mode' together with
>
> #+begin_src emacs-lisp
> (setq-local tab-line-tab-name-function
>             (lambda (_b &optional _bs) "%b"))
> #+end_src
>
> I get tabs that are all named equally - all named after the currently
> active tab's buffer.
>
> I didn't know that mode-line format sequences are valid.  Are they?  If
> they are (would be nice), could we document this, fix the behavior (I
> guess the interpretation is done in the context of a wrong current
> buffer), and maybe allow all kinds of mode-line-format values, like
> lists?

All mode-line format sequences are valid, but only in the context
of the right buffer.  So you can use such tab-name function:

#+begin_src emacs-lisp
(setq tab-line-tab-name-function
      (lambda (b &optional _bs)
	(format-mode-line "%b" 'tab-line-tab nil b)))
#+end_src

This confirms that all mode-line format sequences can be used:

#+begin_src emacs-lisp
(setq tab-line-tab-name-function
      (lambda (b &optional _bs)
	(format-mode-line mode-line-format 'tab-line-tab nil b)))
#+end_src

> (2) What I actually had tried was to get nicely named tabs for Info
> buffers (including the clones created with M-n).
>
> I tried with something like this:
>
> #+begin_src emacs-lisp
> (add-hook 'Info-mode-hook
>           (defun my-setup-tab-line-for-Info-mode ()
>             (tab-line-mode +1)
>             (setq-local
>              tab-line-tab-name-function
>              (lambda (b &optional _bs)
>                (with-current-buffer b
>                  (apply
>                   #'concat
>                   (cdr mode-line-buffer-identification)))))))
> #+end_src

Using the same as above, this could look like:

#+begin_src emacs-lisp
(add-hook 'Info-mode-hook
          (defun my-setup-tab-line-for-Info-mode ()
            (tab-line-mode +1)
            (setq-local
             tab-line-tab-name-function
             (lambda (b &optional _bs)
               (with-current-buffer b
                 (if (derived-mode-p 'Info-mode)
		     (format-mode-line
		      (apply
		       #'concat
		       (cdr mode-line-buffer-identification))
		      'tab-line-tab nil b)
		   (buffer-name b)))))))
#+end_src

> but with that the tab names are not updated while browsing Info pages.
>
> The problem here seems to be related to the caching mechanism that
> doesn't recognize the need to update; invalidating the cache explicitly
> like with this very ugly hack:
>
> #+begin_src emacs-lisp
> (add-variable-watcher
>  'mode-line-buffer-identification
>  (defun my-Info-mode-line-buffer-identification-watcher
>      (_symbol _newval _operation where)
>    (when (and (eq where (current-buffer))
>               (derived-mode-p 'Info-mode))
>      (set-window-parameter nil 'tab-line-cache nil))))
> #+end_src
>
> makes it work.
>
> It would be nice to provide a way to get cases like this work , e.g. by
> allowing to specify buffer-local cache key returning functions.

A user-defined cache key function is a good idea.
Please send an example of such function for Info,
so I could test the implementation.

bug#57848: 29.0.50; Problems with private tab-line-tab-name-function

[Michael Heerdegen]

Juri Linkov <juri@linkov.net> writes:

> > #+begin_src emacs-lisp
> > (setq-local tab-line-tab-name-function
> >             (lambda (_b &optional _bs) "%b"))
> > #+end_src

> All mode-line format sequences are valid, but only in the context
> of the right buffer.  So you can use such tab-name function:
>
> #+begin_src emacs-lisp
> (setq tab-line-tab-name-function
>       (lambda (b &optional _bs)
> 	(format-mode-line "%b" 'tab-line-tab nil b)))
> #+end_src

I didn't want to ask about `format-mode-line': my example (above)
returns a plain "%b" string - nonetheless a buffer name is being printed
as tab name.  Mode-line format specifiers seem to be handled without
`format-mode-line'.

My question is what the semantics of the return value of
`tab-line-tab-name-function' are.  Or is the above behavior a bug?

> A user-defined cache key function is a good idea.
> Please send an example of such function for Info,
> so I could test the implementation.

I guess something like

  (lambda (b) (buffer-local-value 'mode-line-buffer-identification b))

should do it - a tab's name needs to be changed when the buffer local
binding of `mode-line-buffer-identification' has been modified.


Thanks so far,

Michael.

bug#57848: 29.0.50; Problems with private tab-line-tab-name-function

[Juri Linkov]

> my example (above) returns a plain "%b" string - nonetheless a buffer
> name is being printed as tab name.  Mode-line format specifiers seem
> to be handled without `format-mode-line'.
>
> My question is what the semantics of the return value of
> `tab-line-tab-name-function' are.  Or is the above behavior a bug?

Thanks for finding this issue.  Indeed, currently it has such
weird effect that e.g. `C-x b %s RET' displays the tab name
"no process".

Now this is fixed by using the same solution as used in
`Info-set-mode-line' to escape %-constructs.

>> A user-defined cache key function is a good idea.
>> Please send an example of such function for Info,
>> so I could test the implementation.
>
> I guess something like
>
>   (lambda (b) (buffer-local-value 'mode-line-buffer-identification b))
>
> should do it - a tab's name needs to be changed when the buffer local
> binding of `mode-line-buffer-identification' has been modified.

Now a new function variable `tab-line-cache-key-function' is pushed,
so you can add more cache keys with something like this:

#+begin_src emacs-lisp
(add-hook 'Info-mode-hook
          (defun my-setup-tab-line-for-Info-mode ()
	    (add-function :filter-return (local 'tab-line-cache-key-function)
			  (lambda (cache-keys)
			    (cons mode-line-buffer-identification cache-keys)))
            (tab-line-mode +1)
            (setq-local
             tab-line-tab-name-function
             (lambda (b &optional _bs)
               (with-current-buffer b
                 (if (derived-mode-p 'Info-mode)
		     (format-mode-line
		      (apply
		       #'concat
		       (cdr mode-line-buffer-identification))
		      'tab-line-tab nil b)
		   (buffer-name b)))))))
#+end_src

Then visiting even such nodes as (info "(elisp) %-Constructs")
doesn't have anymore the problem that you found above.

bug#57848: 29.0.50; Problems with private tab-line-tab-name-function

[Michael Heerdegen]

Juri Linkov <juri@linkov.net> writes:

> Now this is fixed by using the same solution as used in
> `Info-set-mode-line' to escape %-constructs.

Thanks.

| +(defvar tab-line-cache-key-function #'tab-line-cache-key-default
| +  "Function that adds more cache keys.
| +It has one argument with a list of tabs, and returns a list of cache keys.
| +You can use `add-function' to add more cache keys.")

There is something wrong with the second sentence of the doc string.

> Now a new function variable `tab-line-cache-key-function' is pushed,
> so you can add more cache keys with something like this:
>
> #+begin_src emacs-lisp
> (add-hook 'Info-mode-hook
>           (defun my-setup-tab-line-for-Info-mode ()
> 	    (add-function :filter-return (local 'tab-line-cache-key-function)
> 			  (lambda (cache-keys)
> 			    (cons mode-line-buffer-identification cache-keys)))
>             (tab-line-mode +1)
>             (setq-local
>              tab-line-tab-name-function
>              (lambda (b &optional _bs)
>              [...]
> #+end_src
>
> Then visiting even such nodes as (info "(elisp) %-Constructs")
> doesn't have anymore the problem that you found above.

Very cool, thanks.  I'll try it out a bit and report back.

Michael.

bug#57848: 29.0.50; Problems with private tab-line-tab-name-function

[Michael Heerdegen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Very cool, thanks.  I'll try it out a bit and report back.

Ok - works perfectly so far!  I think I'm happy with this change.

I have a related question, though: When browsing Info, how would you
configure things so that the tabs in the tab line are ordered similar to
what you get in an Internet browser: new tabs are opened at the
rightmost position (or next to the current tab), and the tabs are
otherwise not sorted automatically in any way.  Can this currently be
achieved?  It seems that there is always some unavoidable hard-coded
sorting happening.

Thanks,

Michael.

bug#57848: 29.0.50; Problems with private tab-line-tab-name-function

[Juri Linkov]

> | +(defvar tab-line-cache-key-function #'tab-line-cache-key-default
> | +  "Function that adds more cache keys.
> | +It has one argument with a list of tabs, and returns a list of cache keys.
> | +You can use `add-function' to add more cache keys.")
>
> There is something wrong with the second sentence of the doc string.

Hmm, I don't see what is wrong.

bug#57848: 29.0.50; Problems with private tab-line-tab-name-function

[Juri Linkov]

close 57848 29.0.50
thanks

>> Very cool, thanks.  I'll try it out a bit and report back.
>
> Ok - works perfectly so far!  I think I'm happy with this change.

Thanks for helping to fix the %-construct bug, and to improve
caching functions.  So I'm closing this bug report.

> I have a related question, though: When browsing Info, how would you
> configure things so that the tabs in the tab line are ordered similar to
> what you get in an Internet browser: new tabs are opened at the
> rightmost position (or next to the current tab), and the tabs are
> otherwise not sorted automatically in any way.  Can this currently be
> achieved?  It seems that there is always some unavoidable hard-coded
> sorting happening.

By default new tabs are opened at the rightmost position because
this is what happens with window-next-buffers/window-prev-buffers.
So the order is not changed as long as you use `C-x <left>'
(previous-buffer) and `C-x <right>' (next-buffer) to navigate
tab buffers.  However, switching to a buffer moves it to the end
of the tab-line corresponding to window-prev-buffers.
If you want, you could create a new tab-line-tabs-function
based on tab-line-tabs-window-buffers, that will sort
window-buffers using their creation order preserved in
some new window-local variable.

bug#57848: 29.0.50; Problems with private tab-line-tab-name-function

[Michael Heerdegen]

Juri Linkov <juri@linkov.net> writes:

> > | +(defvar tab-line-cache-key-function #'tab-line-cache-key-default
> > | +  "Function that adds more cache keys.
> > | +It has one argument with a list of tabs, and returns a list of
> > | cache keys.
> > | +You can use `add-function' to add more cache keys.")
> >
> > There is something wrong with the second sentence of the doc string.
>
> Hmm, I don't see what is wrong.

I meant "It has one argument with a list of tabs" should better be
"It is called with one argument, a list of tabs" or "It accepts one
argument, a list of tabs", or something like that.

Michael.

bug#57848: 29.0.50; Problems with private tab-line-tab-name-function

[Juri Linkov]

>> > | +(defvar tab-line-cache-key-function #'tab-line-cache-key-default
>> > | +  "Function that adds more cache keys.
>> > | +It has one argument with a list of tabs, and returns a list of
>> > | cache keys.
>> > | +You can use `add-function' to add more cache keys.")
>> >
>> > There is something wrong with the second sentence of the doc string.
>>
>> Hmm, I don't see what is wrong.
>
> I meant "It has one argument with a list of tabs" should better be
> "It is called with one argument, a list of tabs" or "It accepts one
> argument, a list of tabs", or something like that.

Thanks for the suggestion, now fixed.

bug#57848: 29.0.50; Problems with private tab-line-tab-name-function

[Michael Heerdegen]

Juri Linkov <juri@linkov.net> writes:

> [...] However, switching to a buffer moves it to the end
> of the tab-line corresponding to window-prev-buffers.
> If you want, you could create a new tab-line-tabs-function
> based on tab-line-tabs-window-buffers, that will sort
> window-buffers using their creation order preserved in
> some new window-local variable.

That would be rather fragile, though.  Image I want to see different
Info tabs in different frames.  Wouldn't it make more sense to save the
creation time in the tabs themselves then, somehow?

Dunno how others think about that...for my usage behavior that would
make sense AFAIU.  WDYT?

Thanks,

Michael.

bug#57848: 29.0.50; Problems with private tab-line-tab-name-function

[Michael Heerdegen]

Juri Linkov <juri@linkov.net> writes:

> Thanks for the suggestion, now fixed.

Thanks too,

Michael.

bug#57848: 29.0.50; Problems with private tab-line-tab-name-function

[Juri Linkov]

>> [...] However, switching to a buffer moves it to the end
>> of the tab-line corresponding to window-prev-buffers.
>> If you want, you could create a new tab-line-tabs-function
>> based on tab-line-tabs-window-buffers, that will sort
>> window-buffers using their creation order preserved in
>> some new window-local variable.
>
> That would be rather fragile, though.  Image I want to see different
> Info tabs in different frames.  Wouldn't it make more sense to save the
> creation time in the tabs themselves then, somehow?

By default, tabs are just buffers.  If you want more complex logic,
then its possible to add any additional properties to tabs,
for example, like in the function tab-line-tabs-buffer-groups.

> Dunno how others think about that...for my usage behavior that would
> make sense AFAIU.  WDYT?

We need more opinions, so that based on popular demand we could add
more available functions to choose from in the customizable option
`tab-line-tabs-function'.

bug#57848: 29.0.50; Problems with private tab-line-tab-name-function

[Juri Linkov]

>> Dunno how others think about that...for my usage behavior that would
>> make sense AFAIU.  WDYT?
>
> We need more opinions, so that based on popular demand we could add
> more available functions to choose from in the customizable option
> `tab-line-tabs-function'.

Actually, I remember questions about how to customize the tab-line
to be similar to some other editors where new file tabs are always
opened at the end.

bug#57848: 29.0.50; Problems with private tab-line-tab-name-function

[Michael Heerdegen]

Juri Linkov <juri@linkov.net> writes:

> > We need more opinions, so that based on popular demand we could add
> > more available functions to choose from in the customizable option
> > `tab-line-tabs-function'.
>
> Actually, I remember questions about how to customize the tab-line
> to be similar to some other editors where new file tabs are always
> opened at the end.

My main problem is that the automatic change of the sorting order
of the tab-line (as a side effect of selecting a buffer or whatever) is
confusing because I can't find the tab later by just remembering its
position.

I use tabs mainly in Firefox, so I'm just used to its tab handling.

Michael.

bug#57848: 29.0.50; Problems with private tab-line-tab-name-function

[Juri Linkov]

>> Actually, I remember questions about how to customize the tab-line
>> to be similar to some other editors where new file tabs are always
>> opened at the end.
>
> My main problem is that the automatic change of the sorting order
> of the tab-line (as a side effect of selecting a buffer or whatever) is
> confusing because I can't find the tab later by just remembering its
> position.

This is because of how window-prev-buffers behaves.  We could fix this
behavior to not change the order of the existing window-prev-buffers
after selecting a buffer that already exists in window-prev-buffers,
or at least to add an option to do so.

bug#57848: 29.0.50; Problems with private tab-line-tab-name-function

[Michael Heerdegen]

Juri Linkov <juri@linkov.net> writes:

> This is because of how window-prev-buffers behaves.  We could fix this
> behavior to not change the order of the existing window-prev-buffers
> after selecting a buffer that already exists in window-prev-buffers,
> or at least to add an option to do so.

Hmm - sounds quite drastic.  Not sure I would want that changed behavior
when I don't use tabs.  Conceptually I would prefer that the tab order
would not depend on such low-level things, things that much more user
visible stuff depends on.

Michael.

bug#57848: 29.0.50; Problems with private tab-line-tab-name-function

[Michael Heerdegen]

Juri Linkov <juri@linkov.net> writes:

> We need more opinions, so that based on popular demand we could add
> more available functions to choose from in the customizable option
> `tab-line-tabs-function'.

I'm currently trying this setting in `Info-mode-hook':

#+begin_src emacs-lisp
(setq-local
 tab-line-tabs-function
 (let ((buf-create-times (make-hash-table :weakness t)))
   (lambda ()
     (seq-sort-by
      (lambda (b)
        (or (gethash b buf-create-times)
            (setf (gethash b buf-create-times)
                  (time-to-seconds (current-time)))))
      #'<
      (seq-filter (lambda (b) (with-current-buffer b
                                (derived-mode-p 'Info-mode)))
                  (funcall tab-line-tabs-buffer-list-function))))))
#+end_src

This works as intended most of the time, but sometimes, rarely, tabs
just "jump around".  I don't yet understand why this happens.

Michael.

bug#57848: 29.0.50; Problems with private tab-line-tab-name-function

[Juri Linkov]

>> This is because of how window-prev-buffers behaves.  We could fix this
>> behavior to not change the order of the existing window-prev-buffers
>> after selecting a buffer that already exists in window-prev-buffers,
>> or at least to add an option to do so.
>
> Hmm - sounds quite drastic.  Not sure I would want that changed behavior
> when I don't use tabs.  Conceptually I would prefer that the tab order
> would not depend on such low-level things, things that much more user
> visible stuff depends on.

I tried to implement the window-local tab-line by using a window-parameter.
But the immediate drawback was that the keys 'C-x <left>' (previous-buffer)
and 'C-x <right>' (next-buffer) can't be used anymore to go to the
previous/next tab that is the same as the buffer in the window-buffers list.

bug#57848: 29.0.50; Problems with private tab-line-tab-name-function

[Michael Heerdegen]

Juri Linkov <juri@linkov.net> writes:

> I tried to implement the window-local tab-line by using a window-parameter.
> But the immediate drawback was that the keys 'C-x <left>' (previous-buffer)
> and 'C-x <right>' (next-buffer) can't be used anymore to go to the
> previous/next tab that is the same as the buffer in the window-buffers
> list.

Thanks for still working on this issue.

Obviously I don't see why that happened without looking at what you did.

Personally I don't like the idea of coupling the tab order with any
existing buffer order.  Why do we need to do that in the general case?
Isn't that calling for side effects?

Thanks,

Michael.

bug#57848: 29.0.50; Problems with private tab-line-tab-name-function

[Juri Linkov]

>> I tried to implement the window-local tab-line by using a window-parameter.
>> But the immediate drawback was that the keys 'C-x <left>' (previous-buffer)
>> and 'C-x <right>' (next-buffer) can't be used anymore to go to the
>> previous/next tab that is the same as the buffer in the window-buffers
>> list.
>
> Obviously I don't see why that happened without looking at what you did.
>
> Personally I don't like the idea of coupling the tab order with any
> existing buffer order.  Why do we need to do that in the general case?
> Isn't that calling for side effects?

By default the tab line displays tabs in the same order as buffers
in the window buffer list.  So switching to the next/previous buffer
with 'C-x left/right' also switches the tab in the same direction.

But then tabs don't correspond to the window buffers then there is
no key to switch to the next/previous tab.

bug#57848: 29.0.50; Problems with private tab-line-tab-name-function

[Michael Heerdegen]

Juri Linkov <juri@linkov.net> writes:

> By default the tab line displays tabs in the same order as buffers
> in the window buffer list.  So switching to the next/previous buffer
> with 'C-x left/right' also switches the tab in the same direction.
>
> But then tabs don't correspond to the window buffers then there is
> no key to switch to the next/previous tab.

That's the reason why you want to couple those things?  Isn't it better
to simply provide separate keys for the tab line?  We already have
separate commands (`tab-line-switch-to-prev-tab',
`tab-line-switch-to-next-tab').

I must say I don't understand your reasoning behind what you say.
Binding those two commands to keys was the one of the first things I did
when setting up my tab-line.  Maybe you are using the tab-line very
differently from how I do.

Michael.

bug#57848: 29.0.50; Problems with private tab-line-tab-name-function

[Juri Linkov]

>> By default the tab line displays tabs in the same order as buffers
>> in the window buffer list.  So switching to the next/previous buffer
>> with 'C-x left/right' also switches the tab in the same direction.
>>
>> But then tabs don't correspond to the window buffers then there is
>> no key to switch to the next/previous tab.
>
> That's the reason why you want to couple those things?  Isn't it better
> to simply provide separate keys for the tab line?  We already have
> separate commands (`tab-line-switch-to-prev-tab',
> `tab-line-switch-to-next-tab').
>
> I must say I don't understand your reasoning behind what you say.
> Binding those two commands to keys was the one of the first things I did
> when setting up my tab-line.  Maybe you are using the tab-line very
> differently from how I do.

The hardest problem is to find free keys where these commands could be bound.
Maybe 'C-c TAB' and 'C-c S-TAB' like used for the tab-bar.

bug#57848: 29.0.50; Problems with private tab-line-tab-name-function

[Michael Heerdegen]

Juri Linkov <juri@linkov.net> writes:

> The hardest problem is to find free keys where these commands could be
> bound.
> Maybe 'C-c TAB' and 'C-c S-TAB' like used for the tab-bar.

Sounds reasonable.

Michael.

bug#57848: 29.0.50; Problems with private tab-line-tab-name-function

[Juri Linkov]

>> The hardest problem is to find free keys where these commands could be
>> bound.
>> Maybe 'C-c TAB' and 'C-c S-TAB' like used for the tab-bar.
>
> Sounds reasonable.

For Emacs 30 I'd like to provide two variants: one that you want
where tabs are separate from the buffer order, and another where
the tab list function will reorder buffers in window-prev-buffers.