From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Miles Bader Newsgroups: gmane.emacs.devel Subject: Re: Tabbed buffers Date: Sat, 26 Jan 2008 09:07:16 +0900 Message-ID: <87wspxqwjv.fsf@catnip.gol.com> References: <18330.23354.579245.68671@kahikatea.snap.net.nz> <87ejc5sf4l.fsf@catnip.gol.com> <18330.29609.396872.678539@kahikatea.snap.net.nz> Reply-To: Miles Bader NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1201306058 10979 80.91.229.12 (26 Jan 2008 00:07:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 26 Jan 2008 00:07:38 +0000 (UTC) Cc: emacs-devel@gnu.org To: Nick Roberts Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jan 26 01:07:58 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1JIYaS-0001qr-77 for ged-emacs-devel@m.gmane.org; Sat, 26 Jan 2008 01:07:56 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JIYa1-00034i-Tu for ged-emacs-devel@m.gmane.org; Fri, 25 Jan 2008 19:07:29 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JIYZy-00034a-6K for emacs-devel@gnu.org; Fri, 25 Jan 2008 19:07:26 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JIYZw-00034C-LP for emacs-devel@gnu.org; Fri, 25 Jan 2008 19:07:25 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JIYZw-000349-IW for emacs-devel@gnu.org; Fri, 25 Jan 2008 19:07:24 -0500 Original-Received: from smtp11.dentaku.gol.com ([203.216.5.73]) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JIYZs-0001mg-BB; Fri, 25 Jan 2008 19:07:20 -0500 Original-Received: from 203-216-99-223.dsl.gol.ne.jp ([203.216.99.223] helo=catnip.gol.com) by smtp11.dentaku.gol.com with esmtpa (Dentaku) id 1JIYZq-0002t8-Dv; Sat, 26 Jan 2008 09:07:18 +0900 Original-Received: by catnip.gol.com (Postfix, from userid 1000) id 84EF32F6A; Sat, 26 Jan 2008 09:07:17 +0900 (JST) System-Type: i686-pc-linux-gnu In-Reply-To: <18330.29609.396872.678539@kahikatea.snap.net.nz> (Nick Roberts's message of "Sat, 26 Jan 2008 12:41:29 +1300") Original-Lines: 53 X-Abuse-Complaints: abuse@gol.com X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 3) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:87532 Archived-At: Nick Roberts writes: > > It seems like it would need some thought to work well in Emacs, as > > tabbed user interfaces quickly become unusable if there lots of > > tabs, and Emacs buffer counts are quite often _way_ over that > > threshold. > > I'm sure it will take some work but I'm not suggesting that *all* the > buffers buffers are displayed in tabbed windows, just as currently not > all the buffers are displayed in normal windows. You have to be careful though, as I think typical user-experience is with tools that _do_ put all "buffers" (or whatever term they use) in tabs, so users will expect that they are. Actually though, I suppose using the GUI's existing tab overflow mechanism is probably good enough in many cases (e.g., which limits the number of tabs, and puts remaining stuff in a menu which can be popped up by a "..." button on the far right). My experiences with debuggers that use tabs are (1) Eclipse, which has an aggressive pruning/overflow mechanism. This keeps the number of tabs low, so the tab labels remain easily readable, but I've found that my typical "debugging working set" is larger than the number of tabs shown by default, and it quickly becomes annoying having to select tabs from the menu (you'd think it wouldn't be such a big deal, but for whatever reason I found this very annoying... :-) Still, not that bad... [Of course this is partly due to Eclipse's wonky window layout (let's display all possible types of information crammed into the same display, in small unreadable windows), which makes the space available for the tab display much smaller than in most systems.] (2) VS [whatever version they have at work :-] seems to put far more files in tabs, to the point where the tab labels quickly become completely unreadable. At this point the tabs become almost useless, you'd be better off just selecting from a menu. > In terms of lisp interface, for example, there could be optional extra > argument to display-buffer which gets ignored if Emacs doesn't support > tabbed windows for the toolkit with which it has been built. I don't think any interface that requires calls to display-buffer to know about tabs is workable, there's simply too much code that wouldn't know about them (not to mention we probably don't want to build in dependencies on system-specific GUI features like tabs). -Miles -- Quidquid latine dictum sit, altum viditur.