Help customising the behaviour of the new Tab Line mode

Help customising the behaviour of the new Tab Line mode

[R. Diez]

Hi all:

I have been accumulating frustration with Emacs since many years, but the 27.1 release got me excited again. Specifically:


Feature 1) "Mouse scroll up and down with control key modifier changes font size."

Wow, zoom in, like everybody else!


Feature 2) Tab Line mode

Tabs! Official tabs!!! Finally!!!!!

Could it be that the Emacs developers are actually listening to us, humble users????


I have already written in this mailing list about how important tabs are for me, because they help me use my positional memory to switch 
quickly between documents. The gory details are here:

https://lists.gnu.org/archive/html/help-gnu-emacs/2018-06/msg00289.html

For example, I tend to have source.h to the left and source.cpp to the right, so that I can quickly switch between them. I tend to keep all 
such .h & .cpp files in pairs on the tab bar. I know I could use 'ff-find-other-file' for that, but I use these positional navigation in 
many other situations, like base.h to the left, and derived.h to the right. And so on.

I have been using old package tabbar.el, but it is full of bugs and quirks. There are some variants with other bugs and quirks. I have 
compensated with my poor Lisp. But now, I want to do it "right" with the new Tab Line mode in Emacs 27.1.


Issue 1) The first thing I noticed is that 'compile' creates a window/pane/whatever for the compilation output, and the tab line at the top 
does not show the compilation buffert. In fact, if I call split-window-below, the tab line below only has the current buffer on it. However, 
I would like all Tab Lines to show all buffers (or at least all buffers visited in the whole frame). And I want all those buffers to have 
the same tab order (because my positional memory is useful, but limited). That would match the behaviour of the old tabbar.el package. How 
do I achieve that? Please remember that my Lisp is rather limited. I can tinker, but it won't be pretty. 8-)


Issue 2) The second thing I am missing is the ability to reorder tabs. I actually do not touch the mouse for that. To get an idea of what I 
am looking for, open a few web pages in Firefox or Chromium, and then:

- Press Ctrl+PageUp to move the current view a few pages to the right.
- Press Ctrl+Shift+PageDown to move the current tab to the left, exchanging its position with the previous tab.

With key shortcuts Ctrl+Shift+PageUp and Ctrl+Shift+PageDown, I have got used to reordering tabs very quickly. It is like reordering your 
objects on your physical desktop to your liking, so that you always find everything quickly.

Has anybody written some Lisp to achieve that reordering with Emacs 27.1's Tab Line mode?


Many thanks in advance,
   rdiez

Re: Help customising the behaviour of the new Tab Line mode

[Robert Pluim]

>>>>> On Fri, 14 Aug 2020 15:34:29 +0200, "R. Diez" <rdiezmail-emacs@yahoo.de> said:

    R> Issue 2) The second thing I am missing is the ability to reorder
    R> tabs. I actually do not touch the mouse for that. To get an idea of
    R> what I am looking for, open a few web pages in Firefox or Chromium,
    R> and then:

    R> - Press Ctrl+PageUp to move the current view a few pages to the right.
    R> - Press Ctrl+Shift+PageDown to move the current tab to the left, exchanging its position with the previous tab.

    R> With key shortcuts Ctrl+Shift+PageUp and Ctrl+Shift+PageDown, I have
    R> got used to reordering tabs very quickly. It is like reordering your
    R> objects on your physical desktop to your liking, so that you always
    R> find everything quickly.

    tab-move is an alias for `tab-bar-move-tab' in `tab-bar.el'.

    It is bound to C-x t m.

    (tab-move &optional ARG)

    Move the current tab ARG positions to the right.
    If a negative ARG, move the current tab ARG positions to the left.

Obviously you can come up with your own bindings for this.

Robert

Re: Help customising the behaviour of the new Tab Line mode

[R. Diez]

>      tab-move is an alias for `tab-bar-move-tab' in `tab-bar.el'.
>      It is bound to C-x t m.
>      (tab-move &optional ARG)
>      Move the current tab ARG positions to the right.
>      If a negative ARG, move the current tab ARG positions to the left.

Thanks for your answer, but that is for tab-bar.el, the "Tab Bar mode", with which "you can use tabs to switch between
named persistent window configurations".

However, I want to switch between buffers, not between window configurations, so I need the equivalent for tab-line.el, the "Tab Line mode".

I looked inside and could find no "move" routine.

Regards,
   rdiez

Re: Help customising the behaviour of the new Tab Line mode

[Michael Heerdegen]

"R. Diez" <rdiezmail-emacs@yahoo.de> writes:

> But now, I want to do it "right" with the new Tab Line mode in Emacs
> 27.1.

One thing first: I don't think your working style is yet covered by the
code.

> Issue 1) The first thing I noticed is that 'compile' creates a
> window/pane/whatever for the compilation output, and the tab line at
> the top does not show the compilation buffert. In fact, if I call
> split-window-below, the tab line below only has the current buffer on
> it. However, I would like all Tab Lines to show all buffers (or at
> least all buffers visited in the whole frame). And I want all those
> buffers to have the same tab order (because my positional memory is
> useful, but limited). That would match the behaviour of the old
> tabbar.el package. How do I achieve that? Please remember that my Lisp
> is rather limited. I can tinker, but it won't be pretty. 8-)

What is included is decided by the `tab-line-tabs-function': "By
default, use function `tab-line-tabs-window-buffers' that returns a list
of buffers associated with the selected window."  You may have a look at
and try the alternative values.

> Issue 2) The second thing I am missing is the ability to reorder
> tabs.

AIAIK, none supports manual reordering.  Tabs are always sorted by some
algorithm, so manual reordering doesn't make sense.

I think it would be best to make a feature request (M-x
report-emacs-bug) and CC Juri Linkov <juri@linkov.net>.  That already
worked very well for me in one case.  I've CC'ed him in this answer.

What you want should not be hard to achieve.  But I wonder if it would
be desirable to have all the time: an Emacs session can have hundreds of
buffers, lots of them internal and helper buffers or irrelevant for the
user.  You definitely want some kind of filtering and maybe also some
way of automatic sorting I think.


Michael.

Re: Help customising the behaviour of the new Tab Line mode

[Juri Linkov]

>> Issue 2) The second thing I am missing is the ability to reorder
>> tabs.
>
> AIAIK, none supports manual reordering.  Tabs are always sorted by some
> algorithm, so manual reordering doesn't make sense.
>
> I think it would be best to make a feature request (M-x
> report-emacs-bug) and CC Juri Linkov <juri@linkov.net>.  That already
> worked very well for me in one case.  I've CC'ed him in this answer.

Thanks for pointing me out to this feature request.

> What you want should not be hard to achieve.  But I wonder if it would
> be desirable to have all the time: an Emacs session can have hundreds of
> buffers, lots of them internal and helper buffers or irrelevant for the
> user.  You definitely want some kind of filtering and maybe also some
> way of automatic sorting I think.

Indeed, it's possible to customize `tab-line-tabs-function' to show
all buffers.  But showing hundreds of buffers should not be a problem
because the tab-line supports scrolling.  Then as you already mentioned
the same function could also do automatic sorting, so e.g. "source.cpp"
comes after "source.h" when sorted by file extension as R. Diez wants.

Re: Help customising the behaviour of the new Tab Line mode

[Juri Linkov]

> For example, I tend to have source.h to the left and source.cpp to the
> right, so that I can quickly switch between them. I tend to keep all such
> .h & .cpp files in pairs on the tab bar.
> [...]
> Issue 1) The first thing I noticed is that 'compile' creates
> a window/pane/whatever for the compilation output, and the tab line at the
> top does not show the compilation buffert. In fact, if I call
> split-window-below, the tab line below only has the current buffer on
> it. However, I would like all Tab Lines to show all buffers (or at least
> all buffers visited in the whole frame). And I want all those buffers to
> have the same tab order (because my positional memory is useful, but
> limited). That would match the behaviour of the old tabbar.el package. How
> do I achieve that? Please remember that my Lisp is rather limited. I can
> tinker, but it won't be pretty. 8-)

Please try this code:

(defun tab-line-tabs-mode-sorted-buffers ()
  "Return a list of buffers sorted by file name and file extension."
  (seq-sort-by #'buffer-name
               (lambda (a b)
                 (cond
                  ((equal (file-name-sans-extension a) (file-name-sans-extension b))
                   (string> (file-name-extension a) (file-name-extension b)))
                  (t
                   (string< a b))))
               (seq-filter (lambda (b) (and (buffer-live-p b)
                                            (/= (aref (buffer-name b) 0) ?\s)))
                           (buffer-list))))

(setq tab-line-tabs-function 'tab-line-tabs-mode-sorted-buffers)

Does it sort tabs in the order that you prefer?

It keeps .h & .cpp files in pairs where source.h is to the left
and source.cpp to the right.

Re: Help customising the behaviour of the new Tab Line mode

[R. Diez]

> [...]
> It keeps .h & .cpp files in pairs where source.h is to the left
> and source.cpp to the right.


Thanks for your answer.

This is however not what I wanted. I want the behaviour from Firefox, Chrome, NetBeans, etc.: I wish to manually decide the tab order.

That with the .h and .cpp files was just an example. When I work on a base class and a derived class, I keep the base class to the left and 
the derived class to the right. If I am working on an HTML page, I keep the CSS file to the left, so that I can switch quickly between them. 
And so forth.

Or would you like Firefox to automatically sort the tabs for you?

Regards,
   rdiez

Re: Help customising the behaviour of the new Tab Line mode

[Juri Linkov]

> That with the .h and .cpp files was just an example. When I work on a base
> class and a derived class, I keep the base class to the left and the
> derived class to the right. If I am working on an HTML page, I keep the CSS
> file to the left, so that I can switch quickly between them. And so forth.

It should not be too hard to write another function for `tab-line-tabs-function'
that will keep the manually sorted list of buffers, and a new command with a name
`tab-line-move-tab' that will move the current tab in the internally maintained
sorted buffer list used to display tabs on the tab-line.

Then the remaining question is where would you prefer a new buffer to appear?
When you visit a new buffer, it should be added to such list of buffers.
One possible place is to put the new buffer to the end of the list, 
but then wouldn't it too inconvenient for you to move its tab from the end
of the list to a more appropriate place where you want it to be?

Re: Help customising the behaviour of the new Tab Line mode

[R. Diez]

> It should not be too hard to write another function for `tab-line-tabs-function'
> that will keep the manually sorted list of buffers, and a new command with a name
> `tab-line-move-tab' that will move the current tab in the internally maintained
> sorted buffer list used to display tabs on the tab-line.

OK, thanks for the hint.

Given my very limited Lisp, I may as well wait a few months in the hope that someone more adept has a go at it. O8-)

There probably are other things not directly related to Lisp. For example, how does the new routine learn that there is a new buffer and the 
tab bar needs to repaint? I already mentioned that a new compilation output buffer does not appear on the tab list, but more such things 
will undoubtedly come up. I haven't looked much, but I could not see any documentation in tab-line.el or elsewhere about how tabs work in 
such detail.

Yes, it would be nice to hide the tab for some buffers, but that would be the exception. It could also get tricky, because, if such a buffer 
is currently selected, it should then suddenly show up as a tab. Otherwise, it is confusing to be in no tab at the moment, if you are used 
to always being on a tab.

This is the related code I have been using for years with the old tabbar.el:

-------8<-------8<-------8<-------8<-------

; I find the default "grouping" behaviour annoying, so display all buffers in the same tab group.
(defun tabbar-buffer-all-in-one-group ()
   "Return the list of group names BUFFER belongs to. Return only one group for each buffer."
   (list "AllInOneGroup")
)
(setq tabbar-buffer-groups-function 'tabbar-buffer-all-in-one-group)

(setq *tabbar-ignore-buffers* '("*Messages*" "*Completions*" "*Ediff Registry*" "*Ibuffer*" "*etags-select*" "*xref*" "TAGS"))

(setq tabbar-buffer-list-function 'my-tabbar-buffer-list)

(defun my-tabbar-buffer-list ()
   (cl-remove-if
     (lambda (buffer)
       (and (not (eq (current-buffer) buffer)) ; Always include the current buffer.
            (or (string-starts-with (buffer-name buffer) " ")  ; Possible alternative: (char-equal ?\  (aref ((buffer-name buffer) b) 0))
                (loop for name in *tabbar-ignore-buffers*  ; Remove buffer name in this list.
                  thereis (string-equal (buffer-name buffer) name))
            )
       )
    )
    (buffer-list)
   )
)


(defun my-tabbar-move-tab-left nil ""
   (interactive)
   (let* (
       (tabset (tabbar-current-tabset my-tabbar-request-new-tabset))
       (selected-tab (tabbar-selected-tab tabset))
       (tabs-in-tabset (tabbar-tabs tabset))
       (pos-from-right (length (memq selected-tab tabs-in-tabset)))
       new-tablist)
     (when (tabbar-tab-next tabset selected-tab t)
       (setq new-tablist (append
           (butlast tabs-in-tabset (+ pos-from-right 1))
           (list selected-tab)
           (list (nth (- (length tabs-in-tabset) pos-from-right 1) tabs-in-tabset))
           (last tabs-in-tabset (- pos-from-right 1))))
       ; (setq tabbar-window-cache nil)  ; didn't help
       (set tabset new-tablist)
       (tabbar-set-template tabset nil)
       ; If the tab moves out of view, calling tabbar-click-on-tab did not help.
       ; I tried all combinations, before and after tabbar-display-update.
       ; (tabbar-click-on-tab selected-tab)
       (tabbar-display-update)))
)

(defun my-tabbar-move-tab-right nil ""
   (interactive)
   (let* (
       (tabset (tabbar-current-tabset my-tabbar-request-new-tabset))
       (selected-tab (tabbar-selected-tab tabset))
       (tabs-in-tabset (tabbar-tabs tabset))
       (pos-from-right (length (memq selected-tab tabs-in-tabset)))
       new-tablist)
     (when (tabbar-tab-next tabset selected-tab nil)
       (setq new-tablist (append
           (butlast tabs-in-tabset pos-from-right)
           (list (nth (- (length tabs-in-tabset) pos-from-right -1) tabs-in-tabset))
           (list selected-tab)
           (last tabs-in-tabset (- pos-from-right 2))))
       ; (setq tabbar-window-cache nil)  ; didn't help
       (set tabset new-tablist)
       (tabbar-set-template tabset nil)
       ; If the tab moves out of view, calling tabbar-click-on-tab did not help.
       ; I tried all combinations, before and after tabbar-display-update.
       ; (tabbar-click-on-tab selected-tab)
       (tabbar-display-update)))
)

-------8<-------8<-------8<-------8<-------

Half of the code is not actually mine, and the other half is very old and could probably be greatly improved.

tabbar.el is not very well documented, so the code above does not always work well in all scenarios, but my Emacs skills are too limited to 
fix it.


> Then the remaining question is where would you prefer a new buffer to appear?
> When you visit a new buffer, it should be added to such list of buffers.
> One possible place is to put the new buffer to the end of the list,
> but then wouldn't it too inconvenient for you to move its tab from the end
> of the list to a more appropriate place where you want it to be?

I'm actually OK with the end of the list. That is what Firefox and co do when you press Ctrl+T to create a new tab.

If you right-click on a link on Firefox, and choose "Open Link in New Tab", Firefox is kind of smart about where it places the new tab. The 
first one opens next to the current tab, to its right, but a second one from the same page opens further to the right, next to the first tab 
opened this way. That kind of behaviour would be nice for functions like 'ff-find-other-file'. But that would be comfort in the luxury 
class, reserved for expensive, top-of-the-line software like web browsers, and we don't want to spoil Emacs users, do we??? ;-)


By the way, I tried once package tabbar-ruler, which allows the user to reorder the tabs on the old tabbar.el by dragging them with the 
mouse. Unfortunately, I had to disable it because it had too many bugs. But is supporting mouse users morally acceptable in Emacs? 8-D

Regards,
   rdiez

Re: Help customising the behaviour of the new Tab Line mode

[Juri Linkov]

> There probably are other things not directly related to Lisp. For example,
> how does the new routine learn that there is a new buffer and the tab bar
> needs to repaint?

This is the easiest part of the task - `tab-line-tabs-function' is called
when a new buffer is created, and it will find the new buffer by comparing
the cached list of previous buffers and the current list of all buffers
(that also includes the new buffer).

> By the way, I tried once package tabbar-ruler, which allows the user to
> reorder the tabs on the old tabbar.el by dragging them with the
> mouse. Unfortunately, I had to disable it because it had too many bugs. But
> is supporting mouse users morally acceptable in Emacs? 8-D

Everything that doesn't violate the GPL is morally acceptable. ;-)

I invite you to create a new feature request on bug-gnu-emacs
where all details could be discussed further.

Re: Help customising the behaviour of the new Tab Line mode

[Stefan Monnier]

> But is supporting mouse users morally acceptable in Emacs? 8-D

As long as they respect the Universal Declaration of Mouse Rights, we'd
have no problem with it,


        Stefan