From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Add morph library to emacs Date: Mon, 05 Mar 2012 16:22:50 +0900 Message-ID: <87ty23cy0l.fsf@uwakimon.sk.tsukuba.ac.jp> References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: dough.gmane.org 1330932195 27934 80.91.229.3 (5 Mar 2012 07:23:15 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 5 Mar 2012 07:23:15 +0000 (UTC) Cc: Emacs Dev To: Alin Soare Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Mar 05 08:23:13 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1S4SGC-0002Em-71 for ged-emacs-devel@m.gmane.org; Mon, 05 Mar 2012 08:23:08 +0100 Original-Received: from localhost ([::1]:54810 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S4SGB-00071W-EK for ged-emacs-devel@m.gmane.org; Mon, 05 Mar 2012 02:23:07 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:34777) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S4SG8-00071G-1K for emacs-devel@gnu.org; Mon, 05 Mar 2012 02:23:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S4SG6-0001dn-9y for emacs-devel@gnu.org; Mon, 05 Mar 2012 02:23:03 -0500 Original-Received: from mgmt2.sk.tsukuba.ac.jp ([130.158.97.224]:56620) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S4SG5-0001cT-Q4 for emacs-devel@gnu.org; Mon, 05 Mar 2012 02:23:02 -0500 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id 51A7997079B; Mon, 5 Mar 2012 16:22:50 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 1BD0F1A33A1; Mon, 5 Mar 2012 16:22:50 +0900 (JST) In-Reply-To: X-Mailer: VM undefined under 21.5 (beta31) "ginger" e6b5c49f9e13 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 130.158.97.224 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:148893 Archived-At: Long list of CCs nuked; they're all on emacs-devel anyway. Alin Soare writes: > It is evident that the problem of tabs passes beyound the limits of > graphical capabilities of emacs. Not at all. Lack of graphic capability has nothing to do with it; graphically adding tab control widgets is no problem (I'm looking at them in my XEmacs right now), and displaying different content in the same window is Emacs's bread and butter for user multitasking. The problem that you face is that nobody else understands why you think it necessary to add a whole new event processing system to Emacs to support your tabs, or why you think tabs are an appropriate graphical metaphor for subprocess control (beyond what can already be accomplished by attaching the process's stdio channels to a buffer, and switching to that buffer via tabs). > To add morphic objects to the actual structure of emacs it is also beyound > the limits of the system. Again, XEmacs did so a decade ago, by the name of "native widgets". They are not used much (partly because Emacs doesn't have them, so third parties avoid using them, and partly because the developers who introduced them only debugged their itchy applications, so they tend to still have bugs that need serious scratching when you try to use them for other applications), but they are surely proof of concept. > Having such a structure, emacs will have a main working desktop -- main > morph, in which we can drop other kind of morphs -- like buffers, tabs, > etc. (the frames will not be useful any more). I think you need to rethink your basic concept of "morph". Buffers are *not* GUI objects, and should not be. It is important that a buffer be displayable in more than one place, or completely detachable from the UI. It's arguable that a tab control is a generalization of frame, but that's not the only way it can be implemented (for example, in XEmacs the tab control does not have a display area of its own, but borrows an Emacs window instead), and the notion of a multiwindow area with tiled subwindows is essential to good UI design -- in other words, I don't see how you can do without frames (even if you call them "main morphs" -- to the utter confusion of the whole world -- they are still frames, or what X11 calls "top-level windows").