From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Kangas Newsgroups: gmane.emacs.devel Subject: Re: Tabs Date: Sat, 28 Sep 2019 19:06:57 +0200 Message-ID: References: <87a7bpysm8.fsf@mail.linkov.net> <87muf56wwf.fsf@mail.linkov.net> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="2858"; mail-complaints-to="usenet@blaine.gmane.org" Cc: Emacs developers To: Juri Linkov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Sep 28 19:08:36 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iEGCy-0000bv-3b for ged-emacs-devel@m.gmane.org; Sat, 28 Sep 2019 19:08:36 +0200 Original-Received: from localhost ([::1]:33994 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iEGCw-0001cq-Mx for ged-emacs-devel@m.gmane.org; Sat, 28 Sep 2019 13:08:34 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35990) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iEGBf-0001cS-2g for emacs-devel@gnu.org; Sat, 28 Sep 2019 13:07:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iEGBc-0008Li-24 for emacs-devel@gnu.org; Sat, 28 Sep 2019 13:07:13 -0400 Original-Received: from mail-pf1-f181.google.com ([209.85.210.181]:43467) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iEGBb-0008CW-SI for emacs-devel@gnu.org; Sat, 28 Sep 2019 13:07:12 -0400 Original-Received: by mail-pf1-f181.google.com with SMTP id a2so3232914pfo.10 for ; Sat, 28 Sep 2019 10:07:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IAMI+avcF/pxv6YIPh/uzWFNcwEJo7MaZtro1BaMx5Q=; b=CpMuTY6Vw+DyiKKA1RiPpwRoXZAgnFSk+/rvNG5+LuktZ9bvfRefE06keqHyedCBbO /QVSUGvPbim9ToVudNpa52JXZlx2XYuJDaZHc5tvuOjt8mlY/zIFBw6klHKfJX7pTzlg Iy0THtO4GJiUthoLbrX1yEvXeDr4pgc/6eRBSZev+fPYOisoCovZAvTl16vE2jlo7q2i /BvdjxffV47IOp6LFarg5GzxyqgXJTvyKyB+3/rLvf3R2vZvxUWlrkwkyROPZvzWff58 wOM22qt9YIAB94e+t1Vg9nB/zmXIMlGNw1CAxNVJNn7QK6YqS1qKhi1rLl8haGLSQh3y mO4g== X-Gm-Message-State: APjAAAVPUA6mXCz7Dq6FdCD0VbL0ULM4ULS6dGs6jhXhkS5J9HpDFGZT DCrvcHGAuyyONYHPDZLwh1MxDH7bQB5PGAjTT77dfPHv X-Google-Smtp-Source: APXvYqxRg59gTHaui9jiOfs7vHT5P2JrpXbswAeU2h0+AO/8R3ZatfEHeSdRCRHc2pMzIjuVuK1Pq7sLVjwwbvWPsA4= X-Received: by 2002:a17:90a:cc08:: with SMTP id b8mr17085272pju.119.1569690429385; Sat, 28 Sep 2019 10:07:09 -0700 (PDT) In-Reply-To: <87muf56wwf.fsf@mail.linkov.net> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 209.85.210.181 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:240370 Archived-At: Juri Linkov writes: > > 1. When I run C-x or C-x , it automatically creates a new tab with > > the next buffer. I'd rather it switched between the open tabs, and have a > > separate command to create a new tab. I believe this would be more in line with > > how tabs work in other software, and therefore more intuitive. > > If an inactive tab is displayed to the left from the currently active tab, > do you mean that 'C-x ' doesn't switch to it but instead creates a new tab? When I do: 0. emacs -Q 1. M-x global-tab-line-mode 1. C-x I see a new tab open up with the *Messages* buffer. I would expect it to not open up a new tab when I just ask to see the next or previous tab. > > 2. None of these interactive commands work when run with M-x: > > > > command-execute: tab-line-add-tab must be bound to an event with parameters > > command-execute: tab-line-close-tab must be bound to an event with parameters > > command-execute: tab-line-select-tab must be bound to an event with parameters > > command-execute: tab-line-switch-to-next-tab must be bound to an event > > with parameters > > command-execute: tab-line-switch-to-prev-tab must be bound to an event > > with parameters > > Mouse commands don't work with M-x. For example, try M-x Buffer-menu-mouse-select True. > but we could declare the EVENT arg optional for these commands, > and perform non-mouse logic when it's nil. This is what I would prefer. I think users will naturally try to use these commands and be surprised when they don't work. > > 3. It would then be good to have key bindings for the above commands. > > tab-line-switch-to-prev-tab is already the same as 'C-x ' > tab-line-switch-to-next-tab is already the same as 'C-x ' > tab-line-add-tab is the same as 'C-x b' or any other buffer switching command > tab-line-close-tab is the same as bury-buffer or quit-window (`q') Interesting. Could the doc strings for the tab-line-* commands refer to the corresponding functions? I think that would help lessen the confusion. > only tab-line-select-tab could have a keybinding for referring tab by its > absolute position. That would be good, yes. > > I suggest that the menu is > > the optional non-default behaviour. > > I agree this should be configurable, like in e.g. Firefox a new tab page > is configurable. Fair enough. > > Here are some suggestions that are less fundamental, listed in no particular > > order. > > > > 5. When I hover inactive tabs with the mouse, only the name of the tab is > > highlighted. Can we get the entire tab highlighted instead, including the > > section where the close button is? > > This is fixed now in the branch. Looks great. It might look even better if there is an "extra" highlight on just the button when hovering only that. That would provide the feedback that there is something clickable there. The same goes for the active tab, where I see no highlight when I hover the close button. > > 6. When I hover the close button on the currently active tab, I get a grey line > > between the tab name and the button. Could we get rid of that line? > > This is fixed now. Looks great. > > 7. The active tab seems to be the same color in both the currently active window > > and in other windows. Could we perhaps color the active tab differently > > depending on if it's in the active window or not? > > This is an interesting suggestion, I'd never thought about such distinction, > but it could be useful for additional indication of the currently selected > window, like different faces of the mode-line indicate the selected window. Indeed. > > 8. In Firefox, the close tab button is not visible unless that tab is selected. > > Perhaps that behaviour makes more sense, especially if we also implement the > > "fixed size tabs that shrinks to fit" behaviour discussed elsewhere (because > > smaller tabs make it too easy to accidentally click the close button). > > This Firefox behaviour is very inconvenient - to be able to close > several tabs in a row I have first to switch to each of them that starts > loading the page, so browser hangs for a while - very frustrating experience. > Chromium close buttons on every tab are much better. However, you can set > the close button variable to nil to disable close buttons. In my experience, there is rarely any significant loading time when switching buffer in Emacs. In my opinion, removing the close buttons makes it easier to quickly select tabs without worrying about accidentally closing them. Setting tab-bar-close-button to nil gets rid of them altogether; what I want is to only have a close button on the currently active tab. Perhaps we could add a separate defcustom to make my preferred behaviour optional? That makes me wonder how we can best track these feature suggestions for this branch? Wait until it lands on master and then file wishlist bugs? > > 9. It would probably look better if there was a couple of pixels of padding > > between the tab name and the edge of the tab. > > Is this possible in Emacs? Could you please show an example of a text property > that would put e.g. 5 pixels between characters in string. Sorry, I don't know how to do that. Is it possible to use variable-pitch-mode for the tab-bar only? In that case C-x 8 RET THIN SPACE RET would probably do the trick. In any case, having a variable width font for the tabs in my opinion would be a fantastic feature to have, and will probably go a long way to make it look more polished and professional. > > 10. Could we make the "+" sign (to add more tabs) more visually > > distinct from the tabs? For example, it could have no borders. > > This is fixed now in the branch. Sorry to nit-pick so much, but I suggest to make it a bit bigger, to make the background the same color as the surrounding tab bar, and to make the lines thicker. (I also think that the close buttons could be a bit bigger and thicker, too.) > > 14. Could we add a vertical line below the tabs to separate it from the buffer? [...] > > This is fixed now in the branch, please try it. Yes, this looks good. I also see some other areas where you could perhaps look over the behaviour: A) 0. emacs -Q 1. C-x b *Messages* RET 2. M-x global-tab-bar-mode I now see two tabs -- but I would expect to see only one. B) 0. emacs -Q 1. M-x global-tab-bar-mode 2. Create new tab using "+" (add tab button). 3. Run C-x The two tabs now switches places. I would expect them to stay where they are unless I ask to move them. C) 0. emacs -Q 1. M-x global-tab-bar-mode 2. Click "+" (add tab button) In the menu, I now see the "*scratch*" buffer as an option. If I click it, nothing happens. Expected: I only see the other available but not open buffer. D) 0. emacs -Q 1. M-x global-tab-bar-mode 2. Click "+" (add tab button) 3. Click "*Messages*" 4. Click "+" (add tab button) (BTW, here I would expect to see an error message that there are no more buffers to select or something...) 5. Click "*scratch" Now I'm in the "*scratch*" buffer -- and the buffers switch places. I suppose this is a result of the behaviour I've described above. E) Finally, and I understand this could potentially be a lot of work, but it would be fantastic if one could drag and drop tabs to have them switch places (bonus points if one can drag them to other windows or frames!). Great to see that this feature is progressing so well! Best regards, Stefan Kangas