From: Alin Soare <as1789@gmail.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: Emacs Dev <emacs-devel@gnu.org>
Subject: Re: Fwd: Tabs for console.
Date: Fri, 10 Dec 2010 10:15:47 +0200 [thread overview]
Message-ID: <AANLkTikPcF4CaT2b-VxJ-Bu2pJ2buiYnHGX-2r=n8AV_@mail.gmail.com> (raw)
In-Reply-To: <jwv39q68gbh.fsf-monnier+emacs@gnu.org>
[-- Attachment #1: Type: text/plain, Size: 3662 bytes --]
> > :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 #<window-configuration>. 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.
>
[-- Attachment #2: Type: text/html, Size: 5249 bytes --]
next prev parent reply other threads:[~2010-12-10 8:15 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <AANLkTim8zuFRh2L81g9KgtDon=U5Mvr+QO+HWGE1nqXP@mail.gmail.com>
2010-10-27 16:39 ` Fwd: Tabs for console Alin Soare
2010-11-08 19:22 ` Stefan Monnier
2010-11-08 19:51 ` Alin Soare
[not found] ` <AANLkTim8BoGpECQUUNfPidbn2k_HP77sykR=HYqw9BOE@mail.gmail.com>
[not found] ` <AANLkTinPBfV8OC7d9qOBWGW6130D2nXjg+=Nv2rKqMr1@mail.gmail.com>
[not found] ` <jwvhbewqnjj.fsf-monnier+emacs@gnu.org>
2010-12-02 22:43 ` Alin Soare
2010-12-02 22:45 ` Alin Soare
2010-12-03 8:19 ` martin rudalics
2010-12-03 9:37 ` Andreas Schwab
2010-12-04 21:48 ` Alin Soare
2010-12-03 9:52 ` Andreas Schwab
2010-12-03 11:11 ` Alin Soare
2010-12-03 12:29 ` Dimitri Fontaine
2010-12-04 21:42 ` Alin Soare
2010-12-04 21:55 ` Alin Soare
2011-03-11 8:52 ` A Soare
[not found] ` <AANLkTikwua2bfyvJkt+sn2vR_CzTZA6Hs0Lw=NJSVwT4@mail.gmail.com>
[not found] ` <jwvd3peoig0.fsf-monnier+emacs@gnu.org>
[not found] ` <AANLkTikPRKbvq0mg2X1Huio1z5sF3UvF6+cpT10mH-H-@mail.gmail.com>
[not found] ` <jwvzksilkfd.fsf-monnier+emacs@gnu.org>
[not found] ` <AANLkTi=MiubmGJ_Gk9OVzHY7uc+DOkHHpj5Ht+j7uNx8@mail.gmail.com>
[not found] ` <jwvtyiqk2al.fsf-monnier+emacs@gnu.org>
[not found] ` <AANLkTi=0g00xn2P_yKE0gGkH-ZaZSvz+8yY=yy2=-6W=@mail.gmail.com>
[not found] ` <jwvsjyai7lv.fsf-monnier+emacs@gnu.org>
2010-12-07 4:47 ` Fwd: " Alin Soare
2010-12-07 4:50 ` Alin Soare
2010-12-07 17:06 ` Stefan Monnier
2010-12-08 8:14 ` Alin Soare
[not found] ` <AANLkTikaXr_4bVR2_v7HVFfPB93Sw10e63cKqTRwOunS@mail.gmail.com>
2010-12-08 11:16 ` Alin Soare
2010-12-09 4:29 ` Fwd: " Stefan Monnier
2010-12-09 8:26 ` Alin Soare
2010-12-10 3:35 ` Stefan Monnier
2010-12-10 8:15 ` Alin Soare [this message]
2010-12-10 20:13 ` Stefan Monnier
2010-12-10 21:09 ` Alin Soare
2010-12-10 21:23 ` Davis Herring
2010-12-10 21:34 ` Alin Soare
2010-12-12 20:02 ` Alin Soare
2010-12-13 17:23 ` Stefan Monnier
2010-12-13 21:01 ` Alin Soare
2010-12-14 15:25 ` Alin Soare
2010-10-27 20:34 ` Alin Soare
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='AANLkTikPcF4CaT2b-VxJ-Bu2pJ2buiYnHGX-2r=n8AV_@mail.gmail.com' \
--to=as1789@gmail.com \
--cc=emacs-devel@gnu.org \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).