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: Wed, 08 Dec 2010 23:29:36 -0500 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1291913554 15026 80.91.229.12 (9 Dec 2010 16:52:34 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 9 Dec 2010 16:52:34 +0000 (UTC) Cc: Emacs Dev To: Alin Soare Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Dec 09 17:52:28 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 1PQjjH-0000AI-Fs for ged-emacs-devel@m.gmane.org; Thu, 09 Dec 2010 17:52:27 +0100 Original-Received: from localhost ([127.0.0.1]:36774 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PQjjG-0006IN-U6 for ged-emacs-devel@m.gmane.org; Thu, 09 Dec 2010 11:52:26 -0500 Original-Received: from [140.186.70.92] (port=40702 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PQY8R-0003Ay-U5 for emacs-devel@gnu.org; Wed, 08 Dec 2010 23:29:41 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PQY8Q-0007cm-St for emacs-devel@gnu.org; Wed, 08 Dec 2010 23:29:39 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.183]:2739 helo=ironport2-out.pppoe.ca) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PQY8Q-0007ch-MD for emacs-devel@gnu.org; Wed, 08 Dec 2010 23:29:38 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArsHAGPp/0xFpZR3/2dsb2JhbACiUoEWecAxhUkEhGKNfw X-IronPort-AV: E=Sophos;i="4.59,319,1288584000"; d="scan'208";a="84907754" Original-Received: from 69-165-148-119.dsl.teksavvy.com (HELO ceviche.home) ([69.165.148.119]) by ironport2-out.pppoe.ca with ESMTP/TLS/ADH-AES256-SHA; 08 Dec 2010 23:29:36 -0500 Original-Received: by ceviche.home (Postfix, from userid 20848) id 8E4C1661D7; Wed, 8 Dec 2010 23:29:36 -0500 (EST) In-Reply-To: (Alin Soare's message of "Wed, 8 Dec 2010 10:14:01 +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:133547 Archived-At: >> >> Where is it? In the frame's parameters? Or is it accessed via a new >> >> frame-tabs and set-frame-tabs? >> >> >> >> struct frame >> > { >> > ... >> > /* >> > * an alist of the form ((alist_tab_parameters)) >> > */ >> > Lisp_Object tab_bar_items; >> > ... >> > } >> >> So it's not in the frame's parameters: how is it accessible from Elisp? [...] > So far it is accesible via frame-parameters, but in my code this access is > not useful/used. IIUC it is also (write-) accessible via `make-tab', right? > I could separate all tabs parameters into a struct tab, and keep inside > struct frame only 3 fields. > struct frame > { > bool subscribe_to_tabs; > int tab_bar_lines; > char *regexp; > } I don't care about such details for now: I'm concerned about the API it presents to Elisp. > Yes, like this. Or the :initcode is executed from (make-tab, like in my > example, and for my example there is no reason to keep it memorized as a > parameter in tab's alist parameters, because in this example it is not > useful any more). I'm still very far from understanding what you mean. So here's how I imagine things working: - some function to add/control/create a tabbar. (make-tab-bar PLACE) IIUC this function also accepts an INIT-CODE argument, which is run when the user presses the "+" button on the tab-bar. - some function to add a tab to a tabbar (make-tab TABBAR ACTIVATE-FUNCTION DEACTIVATE-FUNCTION) - probably also some function to delete a tab (delete-tab TABBAR TAB) - probably also some deletion-hook in case the user presses the "X" button to delete a tab. Now, all of ACTIVATE-FUNCTION, DEACTIVATE-FUNCTION, and DELETION-HOOK could either be specified in make-tab or in make-tab-bar, depending on whether we want to impose a uniform behavior. If the ACTIVATE-FUNCTION is shared by all tabs, we'll also need each tab to have a DATA argument, which is the equivalent of your environment. > But the :initcode can be very useful, because a tab should be > re-initialized sometimes. That sounds odd. When would that be? > Yes, one can store private data, but if we need more private data than a > variable, we need to name every stored value. That doesn't matter to the tabbar code: the tab only ever needs 1 chunk of private data passed to the activate-function. That chunk can be anything the activate-function needs: a struct, a list, an alist, you name it: the tabbar code has no business looking inside. >> Yes, the symbol `sym' assigned by `setq' above is a global variable. >> It is assigned a value which is itself a symbol and that symbol is >> indeed uninterned, but I'm talking about the symbol `sym' not about the >> value stored into its value cell. > This is a mistake in my code, it should not be . I forgot to call a > (make-unbound 'sym) That doesn't solve the problem: it still affects the global variable `sym'. > ya, in my code I called the symbols tab:activate, and in messages I wrote > :activate. Sorry. No, you didn't write :activate, but :activate-code. Such vagueness makes it very difficult to figure out what you mean. >> The tabbar code doesn't need to care about what that value is, it just >> needs to store it and pass it along; the init-code and (de)activate >> functions will decide what to do with it. >> It can be a window-config or anything else. That should make your >> environment business unnecessary. > Yes, if it is only 1 value, we know that it is on the first position of > private-data list, and can access it via cadr. "we" here would be the activate-function, right? >> 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? Stefan