From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Fwd: Tabs for console. Date: Thu, 09 Dec 2010 22:35:50 -0500 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1291957924 16610 80.91.229.12 (10 Dec 2010 05:12:04 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 10 Dec 2010 05:12:04 +0000 (UTC) Cc: Emacs Dev To: Alin Soare Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 10 06:12:00 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 1PQvGt-0002xc-KV for ged-emacs-devel@m.gmane.org; Fri, 10 Dec 2010 06:11:59 +0100 Original-Received: from localhost ([127.0.0.1]:60818 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PQvGm-00021v-F8 for ged-emacs-devel@m.gmane.org; Fri, 10 Dec 2010 00:11:48 -0500 Original-Received: from [140.186.70.92] (port=43405 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PQtvU-0003SF-ML for emacs-devel@gnu.org; Thu, 09 Dec 2010 22:46:12 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PQtlw-00022i-Am for emacs-devel@gnu.org; Thu, 09 Dec 2010 22:35:53 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:23001 helo=ironport2-out.pppoe.ca) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PQtlw-00022e-3y for emacs-devel@gnu.org; Thu, 09 Dec 2010 22:35:52 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As0JADUvAU3O+KIs/2dsb2JhbACiZYEZeb9uhUoEhGSOBQ X-IronPort-AV: E=Sophos;i="4.59,322,1288584000"; d="scan'208";a="85083508" Original-Received: from 206-248-162-44.dsl.teksavvy.com (HELO ceviche.home) ([206.248.162.44]) by ironport2-out.pppoe.ca with ESMTP/TLS/ADH-AES256-SHA; 09 Dec 2010 22:35:51 -0500 Original-Received: by ceviche.home (Postfix, from userid 20848) id D4AE8660DC; Thu, 9 Dec 2010 22:35:50 -0500 (EST) In-Reply-To: (Alin Soare's message of "Thu, 9 Dec 2010 10:26:10 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. 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:133560 Archived-At: > This is a good idea, to clarify first the elisp interface. > * TAB BAR > ** (make-tab-bar PLACE) > for now, suppose that PLACE can be a frame. In what I did, PLACE is only a > frame. OK. > * TAB > ** A TAB can be defined in many ways. Could you mention at least the main ways? > All tabs have in common a :NAME , and > an :ID. :NAME is a string that is displayed on the display on the upperside > of a frame, and :ID is a number that allows to user to easyly access it. > Forget about :ID for now. > ** A TAB also have an :INIT-CODE, a :ACTIVATE-FUNCTION, a > :DEACTIVATE-FUNCTION, :CLOSE-FUNCTION:, hooks, and probably more. > :INIT-CODE must be run to get some values that are useful for > :ACTIVATE-FUNCTION, :DEACTIVATE-FUNCTION, etc. Please throw away the :init-code since it's useless for the tab: by the time the tab is created the init-code has been run already so it doesn't need to be part of the tab. What is needed is a :data element. > *** EXAMPLE1 If I want a tab that keeps a window-configuration, than we > need only 1 such variable: a #. This is used by > :ACTIVATE-FUNCTION, when one switched to that tab. That window-config is the :data. It will be passed as argument to the :activate-function. > *** EXAMPLE2 If I want to create a tab, which divides the frame in 2 > windows: the upper window switches to buffer "xyz", and the second window > switches to buffer "*scratch". Then the INIT-CODE for THIS KIND OF TAB must > ask you the name of buffer1, the name of buffer2, and keep these values into > a place where these values are accessed ONLY BY :ACTIVATE-FUNCTION, and all > other functions of this tab. So the :ACTIVATE-FUNCTION of the next tab (that > probably keeps a window-configuration) MUST NOT SEE the values kept by this > tab. The :ACTIVATE-FUNCTION of this kind of tab must do something like No difference here: the two buffers will be stored in the :data, e.g. as a cons cell. So the :activate-function will simply be: (lambda (data) ( delete-other-windows ) (split-window-vertically) (balance-windows) (let ((buffer1 (car data)) (buffer1 (cdr data)) (switch-to-buffer buffer1) (other-window) (switch-to-buffer buffer2) (other-window) ) Look ma! No get-variable mess! > Here (get-variable "buffer")) looks in tabs' environment, and finds exactly > the value it needs. Right, but luckily we neither want nor need any of that get-variable madness. >> > But the :initcode can be very useful, because a tab should be >> > re-initialized sometimes. >> That sounds odd. When would that be? > It is very useful. Consider that you have a tab (like in EXAMPLE2). > You keep in the upper window the buffer "xyz", and in down window the buffer > "*scratch*" > But 1 hour later, you need to keep in upper window the buffer "abc" and down > "*scratch*". You need to re-initialize the tab, and the :INIT-FUNCTION will > read again the value of "buffer1" and buffer2. > Instead of deleting the tab, and creating a new tab of the same type (that > switches to a buffer), you simply re-initialize the tab. That should not be in the tabbar code, it can easily be handled from outside, by providing a function to modify (rather than add) a tab. Such a function would also be useful/needed in order to do things like "add a * to the tab of a buffer that's been modified". >> >> So it will need to change. But does `make-tab' create a new tab or >> >> a tabbar? If a tab, then I don't understand any more why the init-code >> >> is needed. >> > Yes, tabs must be separate from frames, and keep indepedent of every >> > other thing. A frame/window can subscribe to tabs, and show them when >> > it is activated/etc. >> That doesn't answer my question: does `make-tab' create a new tab or >> a tabbar? > Your idea of (make-tab-bar PLACE) was very good. The tab bar existed without > initialization inside a frame. Not sure why you don't want to answer the question directly, but IIUC you're indirectly here saying that makr-tab indeed creates a tab rather than a tabbar. OK, I think I understand how your code is expected to work. Now can someone tell me how this fits in with the x-tabs and the gtk-tabs branches? We need to come up with an API (at the Elisp level) that works for most/all of those: that doesn't means all 3 provide the same API, but just that we can create a common API on top of them without jumping through too many hoops. Stefan