From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alin Soare Newsgroups: gmane.emacs.devel Subject: Re: Fwd: Tabs for console. Date: Fri, 10 Dec 2010 10:15:47 +0200 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=0016367fb67f32a781049709f647 X-Trace: dough.gmane.org 1291968966 22754 80.91.229.12 (10 Dec 2010 08:16:06 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 10 Dec 2010 08:16:06 +0000 (UTC) Cc: Emacs Dev To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 10 09:16:02 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 1PQy92-0001H7-20 for ged-emacs-devel@m.gmane.org; Fri, 10 Dec 2010 09:16:01 +0100 Original-Received: from localhost ([127.0.0.1]:34543 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PQy90-0000Et-Gq for ged-emacs-devel@m.gmane.org; Fri, 10 Dec 2010 03:15:58 -0500 Original-Received: from [140.186.70.92] (port=45271 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PQy8u-0000Ec-On for emacs-devel@gnu.org; Fri, 10 Dec 2010 03:15:54 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PQy8t-0004YS-Ab for emacs-devel@gnu.org; Fri, 10 Dec 2010 03:15:52 -0500 Original-Received: from mail-wy0-f169.google.com ([74.125.82.169]:35255) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PQy8t-0004Y7-06 for emacs-devel@gnu.org; Fri, 10 Dec 2010 03:15:51 -0500 Original-Received: by wyj26 with SMTP id 26so3377151wyj.0 for ; Fri, 10 Dec 2010 00:15:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=x+gpT2dwBLbGHK1aiuLpbyLLZChmENx9FXyPGo4+tq0=; b=p2bHzCBpj6gOrohYQ65ZfEF30+xSQDN6PRAa06t87rZZ9BhPEhQxj3RDSYKNQeYguf rslXvsy9ykT1Nn2g0nP3jXj7xJpF3RRTD0AFkaFgHdhZSR6w7ug05DmrF2PB/sBojruI 2Q6ybWY65XNWQ/v6elY16i27gJv1LsmzAsoG4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=a7rrZYmU8Ir4RKZNAgU+IMfd8b/elqvpGg61FI1oJRJqvcUI5SwypycCN7dw6EjIG7 Zr49yqAW9XYU4K+xm0UyQhY52wCxmFSEQj/id0biSlZHQEWKxU4U0rxxcBKLWQommj5V TmScLmSNfIJSxDwfhTWkAuQ/A2r4wskJM4MmI= Original-Received: by 10.216.172.202 with SMTP id t52mr614045wel.108.1291968947856; Fri, 10 Dec 2010 00:15:47 -0800 (PST) Original-Received: by 10.227.38.162 with HTTP; Fri, 10 Dec 2010 00:15:47 -0800 (PST) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) 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:133566 Archived-At: --0016367fb67f32a781049709f647 Content-Type: text/plain; charset=UTF-8 > > :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. > I agree. It is enough to keep an ordered list of values, and you can know that the car is the value allocated to a given object, the cadr to another value, etc. > > > *** 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. > True. You did I understand what I meant. > > *** 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! > True. > > 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. > True. If you keep the variables, you need not to wonder about the order. With variables you can keep buffer2 on the first position of :data, and buffer2 on the second, or vice versa. Or you can conceive :data as an obarray, as I wanted initially. > >> >> 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. > For me, make-tab adds an element to the list f->tab_bar_items, and display_tab_bar will display the :name of that element on tab-bar. > > 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. > --0016367fb67f32a781049709f647 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
> :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:<= br> 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.

I agree. It is = enough to keep an ordered list of values, and you can know that the car is = the value allocated to a given object, the cadr to another value, etc.
=C2=A0

> *** EXAMPLE1 =C2=A0If I want a tab that keeps a window-configuration, = than we
> need only 1 such variable: a #<window-configuration>. This is us= ed by
> :ACTIVATE-FUNCTION, when one switched to that tab.

That window-config is the :data. =C2=A0It will be passed as argument = to
the :activate-function.

True. You did I understand= what I meant.

=C2=A0
> *** 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 K= IND OF TAB must
> ask you the name of buffer1, the name of buffer2, and keep these value= s into
> a place where these values are accessed ONLY BY :ACTIVATE-FUNCTION, an= d all
> other functions of this tab. So the :ACTIVATE-FUNCTION of the next tab= (that
> probably keeps a window-configuration) MUST NOT SEE the =C2=A0values k= ept 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. =C2=A0So the :activate-function will simply be:

=C2=A0 (lambda (data)
=C2=A0 =C2=A0( delete-other-windows )
=C2=A0 =C2=A0(split-window-vertically)
=C2=A0 =C2=A0(balance-windows)
=C2=A0 =C2=A0(let ((buffer1 (car data))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (buffer1 (cdr data))
=C2=A0 =C2=A0(switch-to-buffer buffer1)
=C2=A0 =C2=A0(other-window)
=C2=A0 =C2=A0(switch-to-buffer buffer2)
=C2=A0 =C2=A0(other-window) )

Look ma! =C2=A0No get-variable mess!

True.=C2=A0
> 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.

True. If you keep the variables, you need not to = wonder about the order. With variables you can keep buffer2 on the first po= sition of :data, and buffer2 on the second, or vice versa. Or you can conce= ive :data as an obarray, as I wanted initially.
=C2=A0
>> >> So it will need to change. =C2=A0But does `make-tab' = create a new tab or
>> >> a tabbar? =C2=A0If 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 o= f every
>> > other thing. =C2=A0A 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 w= ithout
> 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.

For me, make-tab adds an element to= the list f->tab_bar_items, and display_tab_bar will display the :name o= f that element on tab-bar.

=C2=A0

OK, I think I understand how your code is expected to work. =C2=A0Now can someone tell me how this fits in with the x-tabs and the
gtk-tabs branches? =C2=A0We 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<= br> same API, but just that we can create a common API on top of them
without jumping through too many hoops.



<= br>
--0016367fb67f32a781049709f647--