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: Mon, 12 Apr 2010 19:58:22 -0700 Message-ID: References: <30298845.656931270806476838.JavaMail.www@wwinf4631><4BBF0C6C.7000909@swipnet.se> <4BC011F5.9010505@swipnet.se><87tyri429l.fsf@uwakimon.sk.tsukuba.ac.jp><203268BCBA374E2CA3097FC84362424A@us.oracle.com> <87wrwcfadg.fsf@mail.jurta.org> 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 1271127527 6075 80.91.229.12 (13 Apr 2010 02:58:47 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 13 Apr 2010 02:58:47 +0000 (UTC) Cc: "'Stephen J. Turnbull'" , =?iso-8859-1?Q?'Jan_Dj=E4rv'?= , 'Stefan Monnier' , "'Emacs Dev \[emacs-devel\]'" To: "'Juri Linkov'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Apr 13 04:58:44 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 1O1WKq-0006hQ-9v for ged-emacs-devel@m.gmane.org; Tue, 13 Apr 2010 04:58:44 +0200 Original-Received: from localhost ([127.0.0.1]:35326 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O1WKp-0007Ui-Ky for ged-emacs-devel@m.gmane.org; Mon, 12 Apr 2010 22:58:43 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O1WKk-0007Ud-VH for emacs-devel@gnu.org; Mon, 12 Apr 2010 22:58:38 -0400 Original-Received: from [140.186.70.92] (port=35012 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O1WKj-0007Tq-BV for emacs-devel@gnu.org; Mon, 12 Apr 2010 22:58:38 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O1WKh-0004pP-3B for emacs-devel@gnu.org; Mon, 12 Apr 2010 22:58:37 -0400 Original-Received: from rcsinet12.oracle.com ([148.87.113.124]:55918) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O1WKg-0004pH-Rj for emacs-devel@gnu.org; Mon, 12 Apr 2010 22:58:35 -0400 Original-Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet12.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o3D2wVll010083 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 13 Apr 2010 02:58:33 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 o3D2wQWK013102; Tue, 13 Apr 2010 02:58:28 GMT Original-Received: from abhmt005.oracle.com by acsmt354.oracle.com with ESMTP id 169117701271127503; Mon, 12 Apr 2010 19:58:23 -0700 Original-Received: from dradamslap1 (/10.175.218.228) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 12 Apr 2010 19:58:23 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <87wrwcfadg.fsf@mail.jurta.org> Thread-Index: Acrao2+UpcD7HTMaSZqRbmqke6pSbgADAo+w 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.0A0B0202.4BC3DDD6.0148: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:123553 Archived-At: > > 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. > > Let's compare how this is implemented in web browsers. Typing C-b in > Firefox opens a left-side pane that indeed looks like a > vertical tab bar. But it has completely different semantics than the > real tab bar. I don't care about "real" tab bars or "real" Firefox bookmarks. I care about what tabs will be in Emcs. > Clicking on a bookmark opens a web page in a new tab. > Clicking on a tab selects a web page in the existing tab. So what? > So bookmarks are not a good example what the tab bar could > be used for. That doesn't follow at all. Anyway, please read what I wrote. I said that I would like to be able to use tabs for the _kinds of things_ I use Emacs bookmarks for - whether or not bookmarks are used as an intermediary. And I gave examples of such diverse uses, which go far beyond the usual use of Emacs bookmarks, not to mention even further beyond what one can use Firefox bookmarks for. I suggested thinking about such things in the interest of keeping the model/design for Emacs tags open, general, flexible. The idea was to foster thinking about what tabs can do and argue for keeping their use completely flexible and general - that is, undefined. In particular, I suggested separating a concern for implementation and user-interaction design (GUI) from what tabs actually _do_, that is, what you can do with them. I do not want Emacs design to hard-couple user-tab interaction (the GUI) with any particular action to be effected by a tab. I want the possibilities for the thingies that are selected or invoked by choosing a tab to remain open and bindable at runtime (in Lisp). I want those thingies to be anything at all: a window configuration, a desktop, a "project", a buffer, a mail, a process invocation, or whatever. I want a tab to be able to invoke any function whatever. Define the GUI, fine (and I said that I probably have next to nothing to say about that), but please let the mapping of tab<->thingie selected/activated/invoked be open, not predefined. As one instance of exploiting such hoped-for openness, I would like to be able to attach/map-to/invoke a arbitrary Lisp function. Stefan spoke of commands - via a keymap. As another instance, I suggested being able to attach an Emacs bookmark. (No, not a Firefox bookmark, but a chunk of Emacs-Lisp that can represent saved state and a handler function.) So there were two different uses/mentions of bookmarks in what I wrote: (1) bookmarks (in bookmark+) as a model or illustration of generality, to point out some of the many different kinds of things one might like to do by clicking a tab, and (2) invocation of existing Emacs bookmarks as one concrete example of attaching a thingie to a tab - that is, bookmarks as one type of attachable thingie. The more important point is #1, by far: tabs should be able to do pretty much anything. If you don't in fact design them in such a way that I can directly map bookmarks to tabs (#2), that's not a big deal. As long as I can hook/map a tab to an arbitrary function, I can invoke a bookmark anyway (or anything else). So perhaps reread my mail, concentrating on #1: bookmark uses as examples of things one might want a tab to do. And forget about #2 if it adds confusion to the discussion. I'm OK with a hook, a handler, a keymap,...whatever (we can get to preferences among those later). The point is simply *not* to hard-design tabs as *only* selectors of window configs (or of any other specific thing). Do not predefine what tabs do. I wrote my mail in response to Jan's proposed implementation that I understand (perhaps incorrectly) to hard-couple tabs to window configs. I do not want Emacs tabs to be like that. I want them to be open. > I think in Emacs the most suitable widget for that is the speed bar. > > Of course, we could allow any action for tabs by design, but > using them for bookmarks is a bad idea. Allow any action by design, yes. That was precisely the point. I used different kinds of bookmarks (in bookmark+) as examples of different kinds of things one might want to use tabs for. They were illustrations of why tabs can be and should be more than simply window-selectors. Apparently, the bookmark model as illustration was not clear. Just please make sure we can attach an arbitrary function to a tab and I'll be a happy camper, no doubt. A keymap, such as Stefan proposed, would be OK. A function might be better. Allowing either would be good. Allowing a function, keymap, or bookmark would be grand, but it's not necessary. What I do not want to see is tabs being dedicated to *only* switching among X's, where X is any single thing such as window configs, prohibiting the use of tabs for Y's, where a Y is not an X. Please do not predefine what tabs can do. Capice?