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: Mon, 16 Dec 2019 10:11:01 +0100	[thread overview]
Message-ID: <87y2vcmy8q.fsf@len.workgroup> (raw)
In-Reply-To: <87mubt5gtt.fsf@mail.linkov.net>

Hi Juri,
* Juri Linkov <juri@linkov.net> [2019-12-16; 01:06]:
> Most commands (new tab and close tab) already display the message,
> but not when a tab is selected.  Thanks for noticing.  This is now
> improved to show the name of the selected tab in the echo area.

great, thanks!

>> I'd prefer to navigate tabs like buffers via names and completion.
>> This would be like switch-to-buffer, how about "C-X t t" as the default
>> key binding?  This would happen in the echo area, therefore be less
>> visual intrusive and keep the current window configuration visible
>> till I choose the next one, while tab-list blanks the whole frame till I
>> choose the next one from this list.
>
> There is already the command like switch-to-buffer to select a tab by name
> with completion.  The command name is 'tab-bar-select-tab-by-name'
> (alias of 'tab-bar-switch-to-tab').

I didn't know, this is good.

> 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.

>> M-x tab-list creates a temporary tab, which looks like a buffer in a
>> window, but is not shown for instance as a buffer in ibuffer.  Other
>> than ibuffer or list-buffers which split the window and therefore
>> provide some visual context, tab-list destroys this context.
>
> 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).

>> The names of the tabs are somehow centred vertically and horizontally,
>> which irritates me.
>
> They are centered to resemble the window list displayed by window managers
> in the center of the screen when switching windows.  If you don't like this,
> maybe there could be an option to display the list in the top left corner
> of the frame?

This is obviously bike shedding, but I would prefer if it looked
similar to buffer-list or ibuffer.  So yes beinning in the top
left corner, perhaps with ab bit of margin but not much.

>> I would prefer tab-list to create a buffer which mimics list-buffers or
>> better ibuffer.  This could be bound to "C-X t C-t".  Then I would have
>> the choice to have a dedicated tab which shows this buffer or switch to
>> it in a tab.  Perhaps it should be possible or even default to bury this
>> tab list before switching to the next tab, in order to restore the
>> windows configuration in the tab current when calling tab-list.
>
> I don't understand how would use this dedicated tab to switch to it
> from another tab.

This would only be possible if the tab bar is shown.  Then one
could click on the tab for the tab list and go further from
there.  But probably nobody will use so many tabs?  Sorry, forget
this one...

> 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.

>> Then for instance in ibuffer I can kill a line with C-K and yank it in
>> another buffer.  This is not possible with the tab-list.  It only marks
>> the tab on this line for deletion (which is ok) but does not copy it to
>> the kill ring.
>
> tab-list was modeled after list-buffers where C-k marks the buffer
> for deletion.

Oh, I see, I compared it to ibuffer.

> There are so many features in ibuffer, many of them don't exist in
> list-buffers, so I expect people will create packages that would
> provide equivalents of many of them for tabs.

Thanks for your explanation.  And thanks for tab-bar-mode.


Ciao; Gregor
--
 -... --- .-. . -.. ..--.. ...-.-






  reply	other threads:[~2019-12-16  9:11 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 [this message]
2019-12-16 21:46     ` Juri Linkov
2019-12-17 23:53       ` Gregor Zattler
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=87y2vcmy8q.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).