unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Gregor Zattler <telegraph@gmx.net>
To: Juri Linkov <juri@linkov.net>
Cc: 38624@debbugs.gnu.org
Subject: bug#38624: 27.0.50; [wish] tab navigation via keyboard should mimic buffer navigation
Date: Wed, 18 Dec 2019 00:53:24 +0100	[thread overview]
Message-ID: <877e2ucxvv.fsf@len.workgroup> (raw)
In-Reply-To: <87immgjd2p.fsf@mail.linkov.net>

Hi Juri,
* Juri Linkov <juri@linkov.net> [2019-12-16; 23:46]:
>>> So you propose to bind it
>>> to the key 'C-x t t'?  This key is the most convenient to type,
>>> so it should be used for the most frequently used tab command.
>>> Do you think 'tab-bar-switch-to-tab' would be the most frequently
>>> used command?
>>
>> I do not have used tabs much, but would assume the most frequent
>> action would switching tabs.  I modeled this key stroke after
>> switch-to-buffer.  And the other one (see below) after buffer-list.
>
> The key sequence for switching tabs doesn't need to be the easiest
> to type, because after running it, the user still needs to type
> the tab name to switch to, that requires more key strokes anyway.

I would assume to use tab switching much more often than creation
or deletion.  Since one has to create a window configuration with
many key strokes before using it, it seems natural to use them for
a relative long time, hence the support in desktop session
saving.
And while one needs to type the name, this will be easier to type
and to remember since the name will presumably a simple word
without the need for modifier keys (e.g. "mail").
Perhaps switching by index is better -- for this I have to figure
out how to use desktop-save-mode along with notmuch (for
email).

>>> Actually, tab-list was designed to not destroy the window configuration.
>>> Unlike ibuffer or list-buffers that split the window, tab-list can't do
>>> the same.  If tab-list will split the window, then after selecting
>>> another tab in the list and later going back to the same tab, will
>>> still display the window with tab-list, and the same window will be
>>> presented in every tab that would be annoying.  Thus tab-list
>>> takes care to not break user's window configurations.
>>
>> Perhaps this window could be buried before switching tabs (see below).
>
> Maybe using quit-window before switching tabs, although this might
> cause other problems.
>
> Another problem is what to do when the user uses the tab list to delete
> the current window configuration (i.e. where the tab list is shown),
> this might have unexpected effect.

For me that would be the logical consequence from closing the
window configuration.

> Neither there is no "*Buffer List*" buffer in the list of buffers
> displayed by 'list-buffers', nor there is no "*Ibuffer*" buffer in
> the list of buffers displayed by 'ibuffer'.

You're right and I never noticed this.

> That's because they
> don't allow killing the same buffer where the buffer list is shown.
> Should the tab list allow deleting the tab where the tab list is shown?

Yup.

>>> Or do you want to use tab-list for other purposes,
>>> not for selecting a tab from the list?
>>
>> I assumed that tab list shows a buffer for managing tabs.
>> Create, delete, perhaps regroup them.  And perhaps users would
>> like to have a dedicated tab (leftmost?) for that.  I personally
>> will use this feater via keyboard and therefore it is not
>> important for me to have a dedicated tab list tab.
>
> Thanks for your explanation, now it's clear what you expected from this,
> so you want an ibuffer-like buffer for managing tabs.
>
> Currently tab-bar.el contains commands for switching tabs,
> not for managing tabs like ibuffer manages buffers.
>
> Since current commands are designed to work like a so-called
> "task switcher" that is used in window managers to switch windows,
> tab-list was a misnomer.  To reduce confusion I will rename
> tab-list to tab-switcher in tab-bar.el.
>
> Then later will create a new ELPA package tab-list.el
> that could be developed and used even after Emacs 27 is released,
> so its development won't delay the pretest of Emacs 27.
>
> I expect many ibuffer-like features will be implemented in this package,
> so it will have the same size as currently the whole tab-bar.el has.
>
> The tab-list.el package could display the tab list using outlines.
> For example:
>
>    - Frame 1
>     - Tab 1.1
>       - Buffer 1.1.1   Size Mode Filename
>       - Buffer 1.1.2   Size Mode Filename
>     - Tab 1.2
>       - Buffer 1.2.1   Size Mode Filename
>       - Buffer 1.2.2   Size Mode Filename
>       - Buffer 1.2.3   Size Mode Filename
> D  - Frame 2
> D   - Tab 2.1
>       - Buffer 2.1.1   Size Mode Filename
> D     - Buffer 2.1.2   Size Mode Filename
>     - Tab 2.2
>  *%   - Buffer 2.2.1   Size Mode Filename
>  *%   - Buffer 2.2.2   Size Mode Filename
>>*%   - Buffer 2.2.3   Size Mode Filename
>
> where typing
>
> RET on the frame line will select that frame;
> RET on the tab line will switch to that tab;
> RET on the buffer line will switch to that tab
>     and select window with that buffer;

the last one seems especially interesting to me.

> D x on the frame line will delete that frame;
> D x on the tab line will close that tab;
> D x on the buffer line will kill that buffer;
>
> C-k or M-w will put the tab into the kill-ring;
> C-y would yank the killed tab to another frame
>     (when point is moved to another frame line)

wow, sounds great.

For now I play with desktop-save-mode

Thanks for your answer, Gregor
--
 -... --- .-. . -.. ..--.. ...-.-






  reply	other threads:[~2019-12-17 23:53 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-15 15:58 bug#38624: 27.0.50; [wish] tab navigation via keyboard should mimic buffer navigation Gregor Zattler
2019-12-15 23:06 ` Juri Linkov
2019-12-16  9:11   ` Gregor Zattler
2019-12-16 21:46     ` Juri Linkov
2019-12-17 23:53       ` Gregor Zattler [this message]
2019-12-19  0:15         ` Juri Linkov
2019-12-19 23:21           ` Juri Linkov
2019-12-20 12:03             ` Gregor Zattler
2019-12-21 23:24               ` Juri Linkov
2019-12-23 20:14                 ` Gregor Zattler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=877e2ucxvv.fsf@len.workgroup \
    --to=telegraph@gmx.net \
    --cc=38624@debbugs.gnu.org \
    --cc=juri@linkov.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).