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: Sun, 22 Sep 2019 01:45:51 +0300 Organization: LINKOV.NET Message-ID: <87blvdxpr0.fsf@mail.linkov.net> References: <87a7bpysm8.fsf@mail.linkov.net> <875zlnu9ds.fsf@web.de> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="207445"; 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: emacs-devel@gnu.org To: Michael Heerdegen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Sep 22 01:06:26 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 1iBoSP-000rpk-HT for ged-emacs-devel@m.gmane.org; Sun, 22 Sep 2019 01:06:25 +0200 Original-Received: from localhost ([::1]:44148 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iBoSM-00027m-Mw for ged-emacs-devel@m.gmane.org; Sat, 21 Sep 2019 19:06:22 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51735) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iBoSC-00027M-W3 for emacs-devel@gnu.org; Sat, 21 Sep 2019 19:06:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iBoSB-00033W-Ge for emacs-devel@gnu.org; Sat, 21 Sep 2019 19:06:12 -0400 Original-Received: from egyptian.birch.relay.mailchannels.net ([23.83.209.56]:7926) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iBoSB-00031V-44 for emacs-devel@gnu.org; Sat, 21 Sep 2019 19:06:11 -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 41B6B6A1A2F; Sat, 21 Sep 2019 23:06:08 +0000 (UTC) Original-Received: from pdx1-sub0-mail-a60.g.dreamhost.com (100-96-91-4.trex.outbound.svc.cluster.local [100.96.91.4]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id B25D16A1E66; Sat, 21 Sep 2019 23:06:07 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Original-Received: from pdx1-sub0-mail-a60.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); Sat, 21 Sep 2019 23:06:08 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|jurta@jurta.org X-MailChannels-Auth-Id: dreamhost X-Company-Celery: 3325b2286d88672b_1569107168003_530494469 X-MC-Loop-Signature: 1569107168003:3910481329 X-MC-Ingress-Time: 1569107168002 Original-Received: from pdx1-sub0-mail-a60.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a60.g.dreamhost.com (Postfix) with ESMTP id 6F7737FE93; Sat, 21 Sep 2019 16:06:02 -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=+/K/42YZ/LFwxzD9IZRt34ODrcg=; b= pRHktltLzbQgruxBDNZNSkoT42wtyNBCPMPhXT0uSWidk0o4hcmZBHx4LrJHD5pA U/bPvZWxrWSJgRBvEgW6vugjAJQVvWPYs4EUGHqAQXFYSRHApncwQs4RkUQBbuwg rrWdDIdEoMJIypeD+ipMJ0jcR8j63+gS1Wk6sGzdIcQ= Original-Received: from mail.jurta.org (m91-129-103-139.cust.tele2.ee [91.129.103.139]) (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-a60.g.dreamhost.com (Postfix) with ESMTPSA id 612BE7FE9A; Sat, 21 Sep 2019 16:05:59 -0700 (PDT) X-DH-BACKEND: pdx1-sub0-mail-a60 In-Reply-To: <875zlnu9ds.fsf@web.de> (Michael Heerdegen's message of "Fri, 20 Sep 2019 01:57:51 +0200") X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedufedrvdehgddukecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvffuohhfffgjkfgfgggtsehttdertddtredtnecuhfhrohhmpefluhhrihcunfhinhhkohhvuceojhhurhhisehlihhnkhhovhdrnhgvtheqnecukfhppeeluddruddvledruddtfedrudefleenucfrrghrrghmpehmohguvgepshhmthhppdhhvghlohepmhgrihhlrdhjuhhrthgrrdhorhhgpdhinhgvthepledurdduvdelrddutdefrddufeelpdhrvghtuhhrnhdqphgrthhhpefluhhrihcunfhinhhkohhvuceojhhurhhisehlihhnkhhovhdrnhgvtheqpdhmrghilhhfrhhomhepjhhurhhisehlihhnkhhovhdrnhgvthdpnhhrtghpthhtohepmhhitghhrggvlhgphhgvvghruggvghgvnhesfigvsgdruggvnecuvehluhhsthgvrhfuihiivgeptd X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 23.83.209.56 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:240230 Archived-At: > My usage is like this: I want tabs in w3m, for w3m buffers, tabs for > eww buffers in a frame "dedicated" to browsing with eww (like a firefox > window), tabs in *info* showing *info* buffers, etc. I don't want > tabs always and everywhere, I want tabs only for certain modes and then > they should only show related buffers. And I don't (necessarily) want > to save any desktop file or frame configurations or so. I just want to > have missing tab support for e.g. eww or info, preferably without losing > the header line. > > Does your implementation cover such a user behavior? Yes, it's already customizable enough to cover many different needs. At the core it provides a new place at the top of the frame for the frame-local tab-bar, and also places for window-local tab-lines at the top of each window. So authors of many existing packages that currently had no choice other than taking space from the header-line, now can adapt packages to use new locations reserved specially for tabs. If you are already using one of these packages you might want to continue using them with the new tabs locations that doesn't conflict with the header-line. These packages provide dozens of user options, and it makes no sense to copy all them to the core. Instead of trying to cover an infinite set of possible customization preferences, the core should be general to allow adapting to the customization needs easily. The current implementation is already flexible enough, so for example, what you asked for *info* buffers, is possible to do with the current implementation with just a few lines: (advice-add 'tab-line-tabs :around (lambda (orig-fun &optional window) (if (derived-mode-p 'Info-mode) (mapcan (lambda (b) (with-current-buffer b (when (derived-mode-p 'Info-mode) (list b)))) (buffer-list)) (funcall orig-fun window)))) Later this could be generalized to provide e.g. an option for the list of modes where to enable this behavior. Also I already implemented more features such as tab close undo, tab history back, etc. But it would be better to add them later after merging the branch to master, so merging will be easier with minimal set of changes. Thus perhaps now I should start preparations for merging the feature/tabs branch to master that includes mostly writing documentation for the Info manual.