emacs-devel
[Top][All Lists]
Advanced

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

Add morph library to emacs


From: Stephen J. Turnbull
Subject: Add morph library to emacs
Date: Mon, 05 Mar 2012 16:22:50 +0900

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




reply via email to

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