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: Add morph library to emacs Date: Tue, 6 Mar 2012 03:09:09 +0200 Message-ID: References: <87ty23cy0l.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=14dae9340b55b0eac504ba88b073 X-Trace: dough.gmane.org 1330996160 7062 80.91.229.3 (6 Mar 2012 01:09:20 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 6 Mar 2012 01:09:20 +0000 (UTC) Cc: Emacs Dev To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Mar 06 02:09:19 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 1S4itz-0003Z2-Gp for ged-emacs-devel@m.gmane.org; Tue, 06 Mar 2012 02:09:19 +0100 Original-Received: from localhost ([::1]:48448 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S4ity-0005OA-Ew for ged-emacs-devel@m.gmane.org; Mon, 05 Mar 2012 20:09:18 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:33907) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S4itv-0005O5-12 for emacs-devel@gnu.org; Mon, 05 Mar 2012 20:09:16 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S4its-0008Ap-DM for emacs-devel@gnu.org; Mon, 05 Mar 2012 20:09:14 -0500 Original-Received: from mail-iy0-f169.google.com ([209.85.210.169]:58962) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S4its-0008AG-40 for emacs-devel@gnu.org; Mon, 05 Mar 2012 20:09:12 -0500 Original-Received: by iajr24 with SMTP id r24so7681523iaj.0 for ; Mon, 05 Mar 2012 17:09:09 -0800 (PST) Received-SPF: pass (google.com: domain of as1789@gmail.com designates 10.50.179.98 as permitted sender) client-ip=10.50.179.98; Authentication-Results: mr.google.com; spf=pass (google.com: domain of as1789@gmail.com designates 10.50.179.98 as permitted sender) smtp.mail=as1789@gmail.com; dkim=pass header.i=as1789@gmail.com Original-Received: from mr.google.com ([10.50.179.98]) by 10.50.179.98 with SMTP id df2mr8852172igc.32.1330996149607 (num_hops = 1); Mon, 05 Mar 2012 17:09:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oj2o9A6y8EfWdVRpKH8x0nW91/gjcovOKddUHvYuT6w=; b=VRzrXODxfgxeyf9giYduu5bkMcCvN4FC/+TFa/x8CXUBn6JKuXl8GTbOo3kic4zGWi Cy5Xl9QhwdGyNZatePvLdO0CWFNqFsu0KE/C79Tng+qfJ97HOr3Iuh+YD7hxSOzyxpfd RCXeRrSpRugl+qfNks3RB9XdGJKh3R9pgwNIp+yroMdATmveYI9vaHNOdjxl2OKSaOD0 bw04RxnEWmRU/7jmPSDfz58/ff+WP/t2Nf2hnIk5w5DBjrzPLLK5WSmS3j/xzl/AF3Hu 8eVomIo7PAqIqhzZG55i43zDi+ikyYBIXwuF7N5hZNRF9vycaWyQAOSWwWJT83GP2bwR xl8w== Original-Received: by 10.50.179.98 with SMTP id df2mr7349901igc.32.1330996149545; Mon, 05 Mar 2012 17:09:09 -0800 (PST) Original-Received: by 10.231.133.131 with HTTP; Mon, 5 Mar 2012 17:09:09 -0800 (PST) In-Reply-To: <87ty23cy0l.fsf@uwakimon.sk.tsukuba.ac.jp> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.85.210.169 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:148895 Archived-At: --14dae9340b55b0eac504ba88b073 Content-Type: text/plain; charset=UTF-8 > > > > 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 effort you depose to write tabs for emacs can be compared with the effort to add to emacs a real graphical interface -- this require maximum 5 000 lines of C code. And if this is done, we will have a graphical interface of the same power of that one of smalltalk. Or otherwise -- a smalltalk with an editor with editing capabilities of emacs. 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. > > This is a play. This graphical interface is limited to the capabilities of emacs's matrix of glyphs. > > 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 > A buffer could be displayed in 2 morphs , if you want. Just start reading about the basics of oop and the link with graphical interfaces. Seems that you never heard about morphs: http://en.wikipedia.org/wiki/Morphic_(software) --14dae9340b55b0eac504ba88b073 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

=C2=A0> It is evident that the problem of tabs passes beyound the l= imits of
=C2=A0> graphical capabilities of emacs.

Not at all. =C2=A0Lack of graphic capability has nothing to do with i= t;
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 effort you depose to write tabs fo= r emacs can be compared with the effort to add to emacs a real graphical in= terface -- this require maximum 5 000 lines of C code.

And if this is done, we will have a graphical interface of the same po= wer of that one of smalltalk.

Or otherwise -- a sm= alltalk with an editor with editing capabilities of emacs.


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).

=C2=A0> To add morphic objects to the actual structure of emacs it is al= so beyound
=C2=A0> the limits of the system.

Again, XEmacs did so a decade ago, by the name of "native widget= s".
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.


This is a play. This graphical inter= face is limited to the capabilities of emacs's matrix of glyphs.
<= div>

=C2=A0
=C2=A0> Having such a structure, emacs will have a mai= n working desktop -- main
=C2=A0> morph, in which we can drop other kind of morphs -- like buffers= , tabs,
=C2=A0> etc. (the frames will not be useful any more).

I think you need to rethink your basic concept of "morph". = =C2=A0Buffers
are *not* GUI objects, and should not be. =C2=A0It is important that a=C2= =A0
buffer be displayable in more than one place, or completely detachable
from the UI. =C2=A0It's arguable that a tab control is a generalization= of

A buffer could be displayed in 2 mo= rphs , if you want.

Just start reading about the b= asics of oop and the link with graphical interfaces.

Seems that you never heard about morphs:

=



--14dae9340b55b0eac504ba88b073--