From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Gtk tabs in emacs, new branch. Date: Tue, 13 Apr 2010 11:42:00 +0900 Message-ID: <87d3y43wg7.fsf@uwakimon.sk.tsukuba.ac.jp> References: <30298845.656931270806476838.JavaMail.www@wwinf4631> <4BBF0C6C.7000909@swipnet.se> <87ljcwaxfv.fsf@mail.jurta.org> <4BC016DA.60400@swipnet.se> <87d3y63gzt.fsf@mail.jurta.org> <4BC1EAB2.6080900@harpegolden.net> <87zl18fadw.fsf@mail.jurta.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1271127805 7041 80.91.229.12 (13 Apr 2010 03:03:25 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 13 Apr 2010 03:03:25 +0000 (UTC) Cc: Jan =?iso-8859-1?Q?Dj=E4rv?= , "Emacs Dev \[emacs-devel\]" , David De La Harpe Golden To: Juri Linkov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Apr 13 05:03:23 2010 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.69) (envelope-from ) id 1O1WPI-0008M8-D3 for ged-emacs-devel@m.gmane.org; Tue, 13 Apr 2010 05:03:22 +0200 Original-Received: from localhost ([127.0.0.1]:43831 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O1WP7-0000y4-O6 for ged-emacs-devel@m.gmane.org; Mon, 12 Apr 2010 23:03:09 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O1WP1-0000xp-SC for emacs-devel@gnu.org; Mon, 12 Apr 2010 23:03:03 -0400 Original-Received: from [140.186.70.92] (port=47298 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O1WOy-0000mn-2c for emacs-devel@gnu.org; Mon, 12 Apr 2010 23:03:02 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O1WOT-00059s-BH for emacs-devel@gnu.org; Mon, 12 Apr 2010 23:02:31 -0400 Original-Received: from mtps01.sk.tsukuba.ac.jp ([130.158.97.223]:55083) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O1WOS-000590-TB for emacs-devel@gnu.org; Mon, 12 Apr 2010 23:02:29 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mtps01.sk.tsukuba.ac.jp (Postfix) with ESMTP id 796F51535A8; Tue, 13 Apr 2010 11:43:31 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id D9BB51A292E; Tue, 13 Apr 2010 11:42:00 +0900 (JST) In-Reply-To: <87zl18fadw.fsf@mail.jurta.org> X-Mailer: VM 8.0.12-devo-585 under 21.5 (beta29) "garbanzo" a03421eb562b XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) 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:123554 Archived-At: Juri Linkov writes: > > Cnsider the GIMP's tab docks - You can have a layers window, channels > > window and paths window (not the gimp terminology, they actually call each > > window a "tab") docked into a tab group or a brushes window, layers window > > and palette window. Or whatever. And rearrange them as you see fit. > > I don't think it's right to call these things "windows". That depends on the implementation. Almost certainly, though, each of these is actually a GUI widget, which is more or less equivalent in Emacs terms to a window dedicated to a buffer. > A "window" in Emacs is the physical area of the screen in which a > buffer is displayed. That's a restriction of Emacs, not of the concept of window, though. Emacs is effectively a tiling window manager (within each frame). > So they are rather a layers buffer, channels buffer and paths > buffer. This on the other hand is definitely not the case. The GIMP's tabs are indeed tightly bound to screen regions, whatever you want to call them. They are not conceptually independent of the screen, as Emacs buffers are. > Another variant is to call them "window-subtrees", The use of the word "call", suggesting that the underlying implementation is the same, is misleading. As you and others have pointed out, in Emacs there are at least four different ways to implement the usual tab behavior: (1) one Emacs window, clear and rewrite the content of the associated buffer (eg, the echo area/ minibuffer); (2) one window, move point in the associated buffer (bookmarks); (3) one window, switch associated buffers; and (4) multiple windows, delete a window and restore another in its place. (Here I use "Emacs window" in its general sense of a window tree, which may be split horizontally or vertically.) So far the only interesting argument I've seen against a general callback implementation supporting any and all of the above, as well as others my marginal imagination is insufficient to contain, is Jan's claim that it results in flashing and a race condition. In XEmacs, which implements its tab control widget with a generic callback into Lisp, I admit that I do see flashing in builds with Lucid toolkit and a homegrown tab control widget (based on Edward Falk's free widget set available on the 'net, but heavily modified; don't blame Ed!) However I claim that this is a bug in our redisplay; if you have a sufficiently slow X connection, you can see the tabs (in fact the whole window) being redrawn multiple times as the result of a single tab press. In the ten years that we've had the tab control, I can't recall a bug that was diagnosed as a race condition in the tab control. So maybe that's a problem for GTK builds, but GTK getting in the way of the app's design is nothing new.