GNU bug report logs -
#57848
29.0.50; Problems with private tab-line-tab-name-function
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 57848 in the body.
You can then email your comments to 57848 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57848; Package
emacs.
(Fri, 16 Sep 2022 04:41:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Michael Heerdegen <michael_heerdegen <at> web.de>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Fri, 16 Sep 2022 04:41:03 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57848; Package
emacs.
(Sun, 30 Oct 2022 07:38:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 57848 <at> debbugs.gnu.org (full text, mbox):
> (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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57848; Package
emacs.
(Sun, 30 Oct 2022 12:04:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 57848 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57848; Package
emacs.
(Sun, 30 Oct 2022 17:42:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 57848 <at> debbugs.gnu.org (full text, mbox):
> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57848; Package
emacs.
(Mon, 31 Oct 2022 08:59:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 57848 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57848; Package
emacs.
(Wed, 09 Nov 2022 02:08:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 57848 <at> debbugs.gnu.org (full text, mbox):
Michael Heerdegen <michael_heerdegen <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57848; Package
emacs.
(Wed, 09 Nov 2022 07:46:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 57848 <at> debbugs.gnu.org (full text, mbox):
> | +(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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57848; Package
emacs.
(Wed, 09 Nov 2022 07:46:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 57848 <at> debbugs.gnu.org (full text, mbox):
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 marked as fixed in version 29.0.50, send any further explanations to
57848 <at> debbugs.gnu.org and Michael Heerdegen <michael_heerdegen <at> web.de>
Request was from
Juri Linkov <juri <at> linkov.net>
to
control <at> debbugs.gnu.org.
(Wed, 09 Nov 2022 07:46:03 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57848; Package
emacs.
(Wed, 09 Nov 2022 23:31:01 GMT)
Full text and
rfc822 format available.
Message #31 received at 57848 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57848; Package
emacs.
(Thu, 10 Nov 2022 18:38:02 GMT)
Full text and
rfc822 format available.
Message #34 received at 57848 <at> debbugs.gnu.org (full text, mbox):
>> > | +(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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57848; Package
emacs.
(Sat, 12 Nov 2022 01:53:02 GMT)
Full text and
rfc822 format available.
Message #37 received at 57848 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57848; Package
emacs.
(Sat, 12 Nov 2022 02:45:02 GMT)
Full text and
rfc822 format available.
Message #40 received at 57848 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> linkov.net> writes:
> Thanks for the suggestion, now fixed.
Thanks too,
Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57848; Package
emacs.
(Sat, 12 Nov 2022 18:22:01 GMT)
Full text and
rfc822 format available.
Message #43 received at 57848 <at> debbugs.gnu.org (full text, mbox):
>> [...] 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'.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57848; Package
emacs.
(Sun, 13 Nov 2022 18:05:01 GMT)
Full text and
rfc822 format available.
Message #46 received at 57848 <at> debbugs.gnu.org (full text, mbox):
>> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57848; Package
emacs.
(Mon, 14 Nov 2022 03:50:02 GMT)
Full text and
rfc822 format available.
Message #49 received at 57848 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57848; Package
emacs.
(Mon, 14 Nov 2022 07:55:01 GMT)
Full text and
rfc822 format available.
Message #52 received at 57848 <at> debbugs.gnu.org (full text, mbox):
>> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57848; Package
emacs.
(Tue, 15 Nov 2022 03:44:01 GMT)
Full text and
rfc822 format available.
Message #55 received at 57848 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57848; Package
emacs.
(Fri, 18 Nov 2022 11:50:01 GMT)
Full text and
rfc822 format available.
Message #58 received at 57848 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57848; Package
emacs.
(Thu, 15 Dec 2022 17:40:03 GMT)
Full text and
rfc822 format available.
Message #61 received at 57848 <at> debbugs.gnu.org (full text, mbox):
>> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57848; Package
emacs.
(Sat, 17 Dec 2022 07:37:02 GMT)
Full text and
rfc822 format available.
Message #64 received at 57848 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57848; Package
emacs.
(Sat, 17 Dec 2022 18:07:02 GMT)
Full text and
rfc822 format available.
Message #67 received at 57848 <at> debbugs.gnu.org (full text, mbox):
>> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57848; Package
emacs.
(Sun, 18 Dec 2022 01:17:02 GMT)
Full text and
rfc822 format available.
Message #70 received at 57848 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57848; Package
emacs.
(Sun, 18 Dec 2022 09:13:02 GMT)
Full text and
rfc822 format available.
Message #73 received at 57848 <at> debbugs.gnu.org (full text, mbox):
>> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57848; Package
emacs.
(Tue, 10 Jan 2023 14:07:02 GMT)
Full text and
rfc822 format available.
Message #76 received at 57848 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#57848; Package
emacs.
(Tue, 10 Jan 2023 17:58:02 GMT)
Full text and
rfc822 format available.
Message #79 received at 57848 <at> debbugs.gnu.org (full text, mbox):
>> 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.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Wed, 08 Feb 2023 12:24:06 GMT)
Full text and
rfc822 format available.
This bug report was last modified 1 year and 77 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.