From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.devel Subject: Re: Tabs Date: Mon, 16 Sep 2019 00:17:13 +0300 Organization: LINKOV.NET Message-ID: <87h85db68e.fsf@mail.linkov.net> References: <87a7bpysm8.fsf@mail.linkov.net> <87o903dc2j.fsf@mail.linkov.net> <87y2z6ecuo.fsf@mail.linkov.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="60314"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) Cc: martin rudalics , emacs-devel@gnu.org To: Stefan Kangas Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 16 00:12:18 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 1i9ckk-000FZj-3K for ged-emacs-devel@m.gmane.org; Mon, 16 Sep 2019 00:12:18 +0200 Original-Received: from localhost ([::1]:57448 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i9cki-0005hb-VL for ged-emacs-devel@m.gmane.org; Sun, 15 Sep 2019 18:12:16 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56646) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i9ckZ-0005eZ-VC for emacs-devel@gnu.org; Sun, 15 Sep 2019 18:12:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1i9ckY-0003kG-MY for emacs-devel@gnu.org; Sun, 15 Sep 2019 18:12:07 -0400 Original-Received: from black.elm.relay.mailchannels.net ([23.83.212.19]:48388) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1i9ckY-0003k0-Dw for emacs-devel@gnu.org; Sun, 15 Sep 2019 18:12:06 -0400 X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Original-Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id C2C111A079A; Sun, 15 Sep 2019 22:12:04 +0000 (UTC) Original-Received: from pdx1-sub0-mail-a12.g.dreamhost.com (100-96-38-104.trex.outbound.svc.cluster.local [100.96.38.104]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id C67811A07CB; Sun, 15 Sep 2019 22:11:58 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Original-Received: from pdx1-sub0-mail-a12.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.5); Sun, 15 Sep 2019 22:12:04 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|jurta@jurta.org X-MailChannels-Auth-Id: dreamhost X-Robust-Unite: 6b74b70d2051b909_1568585519036_3723945289 X-MC-Loop-Signature: 1568585519036:2345286761 X-MC-Ingress-Time: 1568585519035 Original-Received: from pdx1-sub0-mail-a12.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a12.g.dreamhost.com (Postfix) with ESMTP id DE41D838A1; Sun, 15 Sep 2019 15:11:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=linkov.net; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=linkov.net; bh=TeRaWDDZkHkS96CUeUMYSXAB6ws=; b= YSqp3nqi7zYHceXZT6UqrW0JiK70xsRGQ7oMFarapGbePpZhMrX+s+N0h814nIwu 4ZzRp11gVALH/5vghT9J7iqQOZ0k4c0tUcotguesHDcKlYliKrT4yg6DvgziN+nm 1jWsfwrVRa4qf6mZF2TP0OXoGGFFNT/iOU7HpgxO+9E= Original-Received: from mail.jurta.org (m91-129-107-243.cust.tele2.ee [91.129.107.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by pdx1-sub0-mail-a12.g.dreamhost.com (Postfix) with ESMTPSA id 087B28389E; Sun, 15 Sep 2019 15:11:50 -0700 (PDT) X-DH-BACKEND: pdx1-sub0-mail-a12 In-Reply-To: (Stefan Kangas's message of "Sun, 15 Sep 2019 18:44:39 +0200") X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedufedruddvgddtjecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvffuohhfffgjkfgfgggtsehttdertddtredtnecuhfhrohhmpefluhhrihcunfhinhhkohhvuceojhhurhhisehlihhnkhhovhdrnhgvtheqnecukfhppeeluddruddvledruddtjedrvdegfeenucfrrghrrghmpehmohguvgepshhmthhppdhhvghlohepmhgrihhlrdhjuhhrthgrrdhorhhgpdhinhgvthepledurdduvdelrddutdejrddvgeefpdhrvghtuhhrnhdqphgrthhhpefluhhrihcunfhinhhkohhvuceojhhurhhisehlihhnkhhovhdrnhgvtheqpdhmrghilhhfrhhomhepjhhurhhisehlihhnkhhovhdrnhgvthdpnhhrtghpthhtohepshhtvghfrghnsehmrghrgihishhtrdhsvgenucevlhhushhtvghrufhiiigvpedt X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 23.83.212.19 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:240059 Archived-At: >> > (FWIW, I find the names tab-bar-mode and global-tab-line-mode >> > confusingly similar. Could we find better and more descriptive names? >> > For example, global-tab-line-mode could be global-buffer-tab-mode.) >> >> Actually it's more related to window than to buffer. But >> global-window-tab-line-mode would be too long and not easy >> to type in e.g. M-x prompt. > > What I'm trying to say is that I find the distinction between "tab > bar" and "tab line" confusing. The name "tab bar" resembles frame-local "tool bar" and "menu bar", whereas "tab line" evokes associations with window-local "header line" and "mode line". > Of course, one could learn the > difference, but I think this will be somewhat frustrating for new > users. Perhaps naming them something like "window tabs" and "buffer > tabs" would be more intuitive to also better explain what they are > used for. "buffer tabs" is a wrong name. Actually there are "frame tab bar" and "window tab line". But adding more prefixes "frame-tab-bar-" and "window-tab-line-" would add more inconvenience, especially in completion. Currently it's easy to complete "tab-" then continue either with "bar-" or "line-". Using "frame-" and "window-" prefixes for tabs would add more confusion with frame and window commands. >> > For example, would feedback similar to "I think the width of the tabs >> > under tab-bar-mode should be fixed" be helpful? >> >> In browsers the width of each tab depends on the number of tabs >> to share tab-bar space proportionally between all tabs. But we could >> add a numeric option for the fixed width. > > In Firefox, the tab is set to a fixed maximum width when there is only > one tab. When there are too many tabs, it shrinks them to fit them. > There is a minimum width, and once that is reached, Firefox adds > arrows to scroll left or right in the tab bar. Perhaps we could do > something similar. I agree. Is the maximum width measured in pixels or characters? >> >> 0. emacs -Q >> >> 1. M-x tab-bar-mode RET >> >> 2. Click on the plus sign to create a new tab >> >> 3. Click on the previous tab >> >> 4. Click on the close icon >> > >> > When saying M-x tab-bar-mode here, the window flickers as if redrawing >> > but no tabs show up. The tabs do show up as soon as I resize the >> > window, or move it to a different workspace. (My window manager is >> > XMonad, a tiling window manager, and the Emacs frame is automatically >> > set to full screen and moved to a particular workspace after launch. >> > Not sure if that helps.) > > I've tested it a bit more, and in addition to the above, I've found > the following cases after running tab-bar-mode: > > 1. As described above: If I move it to another workspace where it is > the only full screen window, the tab bar will immediately show up. > > 2. However, I also have workspaces with window manager tabs. If I > move it to one of these windows after saying M-x tab-bar-mode, I see > the tab bar painted *over* the buffer text. I can move the point to > the line where the tab bar is painted, and moving the point around > will erase the tab bar and show the buffer text instead. I've > attached two screenshots to demonstrate (1) before and (2) after > moving the point. In 2, I moved to the top line in *scratch* and then > moved point to the right a bit. > > (In this case too, if I resize the window, the buffer text will "pop > down" (below the tab bar) and the tab bar works as expected -- I can > no longer move point above the tab bar.) > > 3. I also get the same result (the tab bar painted over the buffer > text) if I put it as the sole window on a full screen workspace, say > M-x tab-bar-mode, and then switch to another workspace and back. Have you had similar problems in the past with this window manager and other Emacs components like menus, tool bars, scroll bars? This might help to debug peculiarities of your window manager. >> Thanks, it seems this is an essential detail that might be specific >> to your window manager. Do you see the same problem when saying >> M-x tool-bar-mode several times to turn the tool-bar on/off? > > If I run tool-bar-mode after tab-bar-mode, the tab bar pops up. If I > run tool-bar-mode to turn it on again, it stays visible. You mean first running of tool-bar-mode disables it? So the tab bar pops up and takes place previously used by tool-bar? This means there is no such problem with tool-bar?