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: Sun, 15 Sep 2019 21:21:21 +0200 Message-ID: References: <87a7bpysm8.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="186120"; mail-complaints-to="usenet@blaine.gmane.org" Cc: emacs-devel@gnu.org To: Juri Linkov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Sep 15 21:22:12 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 1i9a67-000mIJ-VX for ged-emacs-devel@m.gmane.org; Sun, 15 Sep 2019 21:22:12 +0200 Original-Received: from localhost ([::1]:56538 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i9a66-00049v-O7 for ged-emacs-devel@m.gmane.org; Sun, 15 Sep 2019 15:22:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39671) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i9a5W-00048f-Vy for emacs-devel@gnu.org; Sun, 15 Sep 2019 15:21:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1i9a5V-0001JI-OW for emacs-devel@gnu.org; Sun, 15 Sep 2019 15:21:34 -0400 Original-Received: from mail-pl1-f170.google.com ([209.85.214.170]:36661) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1i9a5V-0001JD-JG for emacs-devel@gnu.org; Sun, 15 Sep 2019 15:21:33 -0400 Original-Received: by mail-pl1-f170.google.com with SMTP id f19so15695411plr.3 for ; Sun, 15 Sep 2019 12:21:33 -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=UBpAsGOZg9BbcJWHizXqjDTV5jxafuurOJvqq/jJHVY=; b=D48DhX+yhPSZFv0QE0krNGEfSwTWmlFe+ylVfhOvVerTjAROaq1N0Oqj68rJWvtIdP CHzDypEcD8OEieykPdxyiuCBPFE1PjYBwmeNvmomVWRtlDpPs6fL0/fRCe3aK6esdTdo IFF5MCD9AJ82e3vqd5ducOmdcNpwkHMuUcu2MiMFs0e+B0phhq9IBVGQ51BeJQD4yJh4 z6LiMa1hdFj/vFW6AVirt0xFrkezbFLeQ6MwlO7RT2BjQ5xidyj61QDFIrs03J2M+DX2 92Uq4Aa+xij93uIsnNO96bKS7MKIDT8iuOkGyWz0b9cWx+GMEFIgOevcQdHyir9s9VJ7 idaA== X-Gm-Message-State: APjAAAW4/Yr4MVNAVA6v4ynwKiIywpFworwc1ghTNmrbZDCPpDWAEac4 YD4ppeGwDXT/giADh7IACt7q7aGEipRtMX0+nRc= X-Google-Smtp-Source: APXvYqxLynCcHUfnk6Gq95IStDQmLVcUgcXW4FykfjWGZCPu12p1HTWlGCJWOZdrNGqe1ouAhPoGGxaZZ7O08B4o0gI= X-Received: by 2002:a17:902:bd97:: with SMTP id q23mr14344597pls.259.1568575292436; Sun, 15 Sep 2019 12:21:32 -0700 (PDT) In-Reply-To: <87a7bpysm8.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.214.170 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:240052 Archived-At: Hi Juri, Again, thanks for working on this. I have now tested the tabs branch, and I have some feedback for the tab line (buffer tabs). Juri Linkov writes: > Keybindings for the tab-line: > C-x - switches to the previous window tab; > C-x - switches to the next window tab. 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. 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 3. It would then be good to have key bindings for the above commands. > Clicking on the plus sign adds a new buffer tab to the tab-line. 4. I'm not super fond of that you have to navigate a menu in order to create a new tab. In e.g. Firefox you get a new "empty tab" when clicking the plus to add a new tab. I suppose in Emacs that would correspond to a window with no buffer, but I don't think this makes much sense (if it's even possible). Perhaps the tab could just show the next buffer like C-x and C-x does right now? This behaviour could of course be configurable, so that you optionally display the menu for users who like that. I suggest that the menu is the optional non-default behaviour. ----- 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? 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? 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? 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). 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. 10. Could we make the "+" sign (to add more tabs) more visually distinct from the tabs? For example, it could have no borders. 11. Could we add a tooltip with the name of the buffer to the tabs? 12. The inactive tabs seem to have a shade to the bottom and right. I think that makes them look more like "buttons" than "tabs". Perhaps we could rethink this and just make them one solid color without the shading. 13. It would be nice if the tabs had rounded corners on the top by default. 14. Could we add a vertical line below the tabs to separate it from the buffer? I find that the name of the tab visually melts into the buffer. (This effect would probably be less visible if the tab line was in an even darker color -- I checked some screenshots of Eclipse and that's the solution they seem to have.) Perhaps a vertical bar could be optional. Perhaps we could somehow allow to configure the color of the tab line. Best regards, Stefan Kangas