From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Nix Newsgroups: gmane.emacs.devel Subject: Re: Tabs are ready? -> Let us give a definition of tabs. Date: Thu, 09 Feb 2012 11:19:55 +0000 Message-ID: <87ehu46yp0.fsf@spindle.srvr.nix> References: <4F2E5D33.6020406@gmx.at> <4F2E8185.4080706@gmx.at> <4F2EC73A.8020905@gmx.at> <4F2FACF8.2040304@gmx.at> <4F3007E8.6090209@gmx.at> <87liofhir9.fsf@spindle.srvr.nix> <4F302D4D.3040307@gmx.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1328786426 17958 80.91.229.3 (9 Feb 2012 11:20:26 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 9 Feb 2012 11:20:26 +0000 (UTC) Cc: Juri Linkov , martin rudalics , Emacs Dev , Drew Adams , Juanma Barranquero To: Alin Soare Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Feb 09 12:20:24 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RvS32-0004ZA-3p for ged-emacs-devel@m.gmane.org; Thu, 09 Feb 2012 12:20:20 +0100 Original-Received: from localhost ([::1]:46188 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RvS31-0000gZ-E1 for ged-emacs-devel@m.gmane.org; Thu, 09 Feb 2012 06:20:19 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:52523) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RvS2t-0000g4-Ns for emacs-devel@gnu.org; Thu, 09 Feb 2012 06:20:17 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RvS2m-00011B-R6 for emacs-devel@gnu.org; Thu, 09 Feb 2012 06:20:11 -0500 Original-Received: from icebox.esperi.org.uk ([81.187.191.129]:43246 helo=mail.esperi.org.uk) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RvS2m-0000yS-7r for emacs-devel@gnu.org; Thu, 09 Feb 2012 06:20:04 -0500 Original-Received: from esperi.org.uk (nix@spindle.srvr.nix [192.168.14.15]) by mail.esperi.org.uk (8.14.5/8.14.5) with ESMTP id q19BJt3R013327; Thu, 9 Feb 2012 11:19:55 GMT Original-Received: (from nix@localhost) by esperi.org.uk (8.14.5/8.14.5/Submit) id q19BJtHY013667; Thu, 9 Feb 2012 11:19:55 GMT Emacs: the road to Hell is paved with extensibility. In-Reply-To: (Alin Soare's message of "Thu, 9 Feb 2012 01:43:41 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.93 (gnu/linux) X-DCC-URT-Metrics: spindle 1060; Body=6 Fuz1=6 Fuz2=6 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 81.187.191.129 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:148398 Archived-At: On 8 Feb 2012, Alin Soare outgrape: > I propose the following [brief/ main steps of a] concrete solution for > changing the color of a hidden tab whose process gave output in the > meantime: > > 1. Every tab has a unique ID that can be read and not modified. This ID is > dubbed by the system at the creation of the tab. This is pointless. Window configurations don't need a 'unique ID', neither does this. Just reify the tab: make it a unique Lisp object type (again, like window-configurations). Now the tab object serves as its own unique ID. > 1' Every tab has an internal state. The tab can be seen as a dispather of > messages (or actor) of scheme. I don't understand. Are you saying that each tab is its own recursive editing loop? Because that seems unnecessary (and likely to be very confusing to users). > 2. When the tab is created , it starts the process, and memorize the > process in its internal state. Tabs surely have nothing to do with processes. I expect most tabs to contain buffers (or window configurations, perhaps). A constraint that they all contain processes is surely impractical. Do you mean that (create-tab ...) returns a 'tab process', much as 'make-network-process' does, and that this 'tab process' is then used to receive events from the tab somehow (such as the user switching to it)? That's reasonable, I suppose, though we'd need to define what that process sentinel does. For network processes this is clear enough: creation of a network connection, its breaking, and the reception of data invoke the sentinel and optionally dump the data into a buffer. This makes conceptual sense because network connections are like processes in that they are things down which asynchronous bytestreams are transmitted in both directions. None of this is true for tabs, as far as I can see, so the process sentinel model isn't such a good fit. (I can't think of anything that is a better fit, except perhaps some hooks called from the C core whenever a tab is switched to. I would strongly advise against any concept of tab-local variables: while they make programming a tiny bit easier they make variable lookup slower and much harder to get right. Frame-local variables have enough ugliness and unfixable bugs that they are being removed. Let's not make it worse. I know nobody has proposed this yet: I thought I'd just shoot it down pre-emptively.) > 3. we use the hooks from process , low level programming. You need a lot more description than that. What does a tab sentinel function do? Processes and network streams send and receive data. What do tabs do? > 4. we add a hook that calls a function like tabs-process-signals. This is > either a function of the internal state of a tab, and in case must be > generated for each tab, using the ID of a tab, or be in global environment, > and loop over each tab. The latter is unscalable, but there's no requirement for something in the global environment to necessarily do any sort of loop. A tabs hook function would probably be called with the tab object as a parameter. > 5. this function (tabs--process-signals) either is generated separately for > each tab, or loops over the list of tabs, and identify the tab whose > process' buffer modified. If you passed the tab object as a parameter, that would be entirely unnecessary. > If emacs had actors, a tab could be implemented directly. If not, the idea > of internal state can be encoded somehow. Er, yeah, quite a lot of things in Emacs have internal state. More internal state than you can shake a stick at. :) -- NULL && (void)