From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: Gtk tabs in emacs, new branch. Date: Sun, 11 Apr 2010 11:09:18 -0700 Message-ID: <203268BCBA374E2CA3097FC84362424A@us.oracle.com> References: <30298845.656931270806476838.JavaMail.www@wwinf4631><4BBF0C6C.7000909@swipnet.se><4BC011F5.9010505@swipnet.se> <87tyri429l.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1271009540 31311 80.91.229.12 (11 Apr 2010 18:12:20 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 11 Apr 2010 18:12:20 +0000 (UTC) Cc: 'Stefan Monnier' , "'Emacs Dev \[emacs-devel\]'" To: "'Stephen J. Turnbull'" , "=?iso-8859-1?Q?'Jan_Dj=E4rv'?=" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Apr 11 20:12:18 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 1O11dn-0006wz-Sh for ged-emacs-devel@m.gmane.org; Sun, 11 Apr 2010 20:12:16 +0200 Original-Received: from localhost ([127.0.0.1]:37940 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O11dn-0003Zg-67 for ged-emacs-devel@m.gmane.org; Sun, 11 Apr 2010 14:12:15 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O11ck-00036h-EM for emacs-devel@gnu.org; Sun, 11 Apr 2010 14:11:10 -0400 Original-Received: from [140.186.70.92] (port=55901 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O11ci-00034t-73 for emacs-devel@gnu.org; Sun, 11 Apr 2010 14:11:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O11cf-00017S-3q for emacs-devel@gnu.org; Sun, 11 Apr 2010 14:11:08 -0400 Original-Received: from acsinet11.oracle.com ([141.146.126.233]:37370) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O11ce-00017L-RQ for emacs-devel@gnu.org; Sun, 11 Apr 2010 14:11:05 -0400 Original-Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by acsinet11.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o3BIB25W022881 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 11 Apr 2010 18:11:04 GMT Original-Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o3BFAOgn018911; Sun, 11 Apr 2010 18:11:02 GMT Original-Received: from abhmt019.oracle.com by acsmt353.oracle.com with ESMTP id 151825021271009350; Sun, 11 Apr 2010 11:09:10 -0700 Original-Received: from dradamslap1 (/141.144.72.51) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 11 Apr 2010 11:09:10 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <87tyri429l.fsf@uwakimon.sk.tsukuba.ac.jp> Thread-Index: AcrZdHehiBx1Y90/Svic/y9/v8svTQAHhOhw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090208.4BC210B6.0200:SCFMA4539814,ss=1,fgs=0 X-detected-operating-system: by eggs.gnu.org: GNU/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:123487 Archived-At: > Because the tab metaphor involves switching a well-defined area of > screen from one use to another..., one can trivially subsume > all uses into "window configuration management". But the > implementation of changing what's seen onscreen might involve far more > than swapping one GUI widget in in place of another, and it might not > involve swapping GUI widgets at all (where for this purpose I consider > Emacs windows as widgets). > > In use now? Probably not, because of the very limited imaginations of > tab developers (or if you prefer, because of the very limited > imaginations that tab developers attribute to their users). > > But easy to implement given a flexible tab framework? Lots of them. > How about varying font-lock to highlight different aspects of a buffer > using "layers" of font-lock specs controlled by tabs? Many others > that you might classify as "window configuration management", but > other users might not. I have in mind switching "projects", which > might involve piles of behind the scenes machinery such as restoring > undisplayed buffers in the background, querying status of VCS, etc. `Amen' to "flexible tab framework". And Stephen gives good examples of exploiting such generality. My message is in the same vein. I don't really want to get into this thread much - don't have much to offer, especially regarding implementation. I'd just suggest the following about what tabs should be able to _do_, that is, what you should be able to do with them. I have nothing particular to say now about the questions of where tabs are (frame, window, subwindows, whatever), how the user interacts with them (clicking, sorting, whatever), how they should be implemented, etc. A different and at least equally important question is what happens when a tab is selected/clicked: what actions are carried out? what does the tab actually do or control? Emacs gives us the opportunity to do something much more general wrt tabs than might exist elsewhere. Other things being equal, we should not forego generality wrt what a tab selection can do. We should not, for example, decide that tabs should only switch among window configs or only among buffers or desktops or projects or... At the least, we should allow a tab to invoke an arbitrary function. That means at least providing a hook, a handler, or equivalent. One model that can help guide the design is to allow (but of course not require) a tab to be associated with an Emacs bookmark. Not just with the buffer resulting from invoking a bookmark, but with the bookmark itself - that is, with a particular entry in `bookmark-alist'. Again, I'm not at all suggesting that we _limit_ tabs to bookmarks but that we allow tabs to access or map to existing bookmarks. Thinking about bookmarks can help guide the discussion about what tabs can/should do. A bookmark is essentially a (persistent) named collection of info. That info typically includes a destination, which is typically a file location and a position within the file. But although that is typical, a bookmark need not be associated with any destination. A bookmark can record state of any kind (persistently), and invoking a bookmark can restore that state, without necessarily "going to" any destination. The state restored might be entirely invisible, for example. Stephen's example of switching among projects, thus restoring project state, is something that you can do using bookmarks. In my library bookmark+.el[*] for example, there are Desktop bookmarks, Dired bookmarks that restore markings and hidden-subdirs state, del.icio.us-style tags, and other ways to represent and switch among things such as "projects". And more and better such could easily be imagined. (I'm looking forward to restoring window configs once we have their serialization.) But jumping to a bookmark need not even restore anything. "Jumping" can do anything you want it to. A bookmark can include a handler, which is pretty much an arbitrary function that is invoked during "jumping". Users can easily define their own types of bookmarks (e.g. with their own handlers). Bookmark+ offers several examples of additional kinds of bookmarks and out-of-the-ordinary bookmark handling, to give you an idea. The bookmarking and bookmark-jumping mechanisms are very general and are available for any possible kind of bookmark - which means pretty much any (persistent) named collection of info. Being able to have a tab represent (map to) a bookmark would be very useful, IMO. By "represent" I mean just that a tab could have as its name a bookmark name, and clicking (selecting) the tab would invoke ("jump" to) the bookmark. IOW, the tab would just be a shortcut for a jump call, the same way that an entry in the *Bookmark List* buffer (`C-x r l') is such a shortcut. Look at it also from another point of view. In bookmark+ (for example), you can hide or show (in the *Bookmark List*) the bookmarks that satisfy certain properties. You can mark bookmarks and then perform operations on them (as in Dired or Buffer Menu). You can sort the bookmarks that are visible. And so on. I'd like to be able to do the same kinds of things with tabs: hide tabs based on certain criteria, mark tabs, act on the marked tabs (or on all tabs), sort the tabs in a given tab bar, etc. And that includes opening/showing a set of tabs that satisfy some property (whether or not they were shown previously and then hidden). For example, be able to hit a key to open/add (or close/hide) all tabs belonging to a given project. Whatever choices are made for implementing tabs in Emacs, I'd hope that they could trivially be made to accommodate this suggestion (using bookmarks) - among other uses. I mention the example of bookmarks to underline what Stephen T. and others have said wrt letting tabs be general and not forcing them to map only to certain things such as window configurations. Bookmarks serve as a good example, as food for thought. And the fact that bookmarks already offer so many possibilities of switching and restoring state points out an important point: We need not build such functionality into the tabs (design) themselves. We should just _allow_ tabs to leverage other features of Emacs that provide such functionality. It would be a mistake to try to decide the behavior of tabs - what they _do_ in some narrow way. We should define the GUI behavior (user interaction) and design ways to invoke Emacs functions or objects such as bookmarks, but we should not otherwise define what tabs actually do when you click them, beyond invoking some arbitrary (Emacs-Lisp) thingy. In general, I suggest that we look to things like bookmarks for examples of the kinds of things we might want to be able to do with tabs. That will help us avoid limiting the design of Emacs tabs unnecessarily. When looking for models on which to base our design, we should think of other thingies in Emacs (such as bookmarks), and not just think of other uses of tabs in existing applications. Yes, we do want to be able to do with Emacs tabs _at least_ the kinds of things you can do with Eclipse tabs or Firefox tabs. But let's not limit our design thinking to what you can do with tabs in other apps. Dunno whether I was clear, and apologies for rambling a bit. The point is to keep what tabs _do_ very general, regardless of how they're implemented or what the user/GUI interaction will be like. And thinking of what bookmarks can do is not a bad model for such generality. Being able to use existing bookmarks via tabs would be one example of exploiting the generality that I hope tabs will have. [* http://www.emacswiki.org/emacs/BookmarkPlus]