[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Add morph library to emacs

From: Alin Soare
Subject: Re: Add morph library to emacs
Date: Tue, 6 Mar 2012 03:09:09 +0200

 > 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:


reply via email to

[Prev in Thread] Current Thread [Next in Thread]