Add morph library to emacs

Add morph library to emacs

[Alin Soare]

[-- Attachment #1: Type: text/plain, Size: 769 bytes --]

It is evident that the problem of tabs passes beyound the limits of
graphical capabilities of emacs.

Trying to give a solution for tabs will not bear anything nice -- it would
rise a lot of confusion.

To add morphic objects to the actual structure of emacs it is also beyound
the limits of the system.

I consider that all the work in the direction of tabs is loss of time.

I would like to open the question whether emacs can be completed with a
morphic module .

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 do not consider it is impossible.

But it is bad to invest energy into the actual direction, which is dead.

[-- Attachment #2: Type: text/html, Size: 989 bytes --]

Add morph library to emacs

[Stephen J. Turnbull]

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

Re: Add morph library to emacs

[Alin Soare]

[-- Attachment #1: Type: text/plain, Size: 2508 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 3659 bytes --]

Re: Add morph library to emacs

[Óscar Fuentes]

Alin Soare <as1789@gmail.com> 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 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 how much work would require to adapt the current display code to
that real graphical interface?

(being there, tried that, ran away in horror)

[snip]

Re: Add morph library to emacs

[Stephen J. Turnbull]

Alin Soare writes:

 > The effort you depose to write tabs for emacs can be compared with
 > the effort to add to emacs a real graphical interface

Once again, you're talking to yourself, making us guess what you mean.

Your words make little sense to me.  I have two guesses, neither of
which seems to be what you mean.  Either Emacs already has a "real
graphical interface" (though limited in some ways), or making a "real
graphical interface" will require rewriting thousands of lines of code
spread over millions of lines of code to reorient Emacs from its TTY
roots to a modern (but not necessarily better!) graphical mode.

 > And if this is done, we will have a graphical interface of the same
 > power of that one of smalltalk.

I don't use Smalltalk, and nobody I hack with does.  Would you like to
try an example that the people you are addressing might understand?

 > >  > 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,
 > >
 > This is a play. This graphical interface is limited to the
 > capabilities of emacs's matrix of glyphs.

You haven't looked closely enough.  It's true that XEmacs's
capabilities are limited, but it is capable of managing arrays of
widgets either horizontally or vertically, including arrays of widget
arrays.  In practice that's sufficient for any editor I need.  If you
need a canvas, I don't have one but on GTK+ I'm sure there's something
more or less usable that can be linked in.

More generally, on the X11 family of platforms, one can connect
directly to the X server via xlib.el (that's something developed by
one of the SXEmacs guys, but should work on Emacs as well as the
*XEmacsen), or on platforms where GCC supports FFI, use FFI to access
toolkits on the client side.

lwlib stands for "Lucid Widget Library" after the company that
developed it, but it could just as easily be named the "Lispy Widget
Library", as internally structures of widgets are built out of singly
linked lists.  It would be reasonably straightforward in XEmacs to
finish the work and have real widget objects in Lisp, and then build
up the whole user interface from there, in Lisp.  (I say "XEmacs"
because I suspect that the result would be too heavyweight both in
space and time, and the use of opaque types too great to pass Emacs
filters, but you could hope I'm wrong!)

 > Just start reading about the basics of oop and the link with
 > graphical interfaces.

I did that 20 years ago.  Boring stuff, to my taste.

Please understand: I have no interest in doing the work to implement
your ideas.  I don't find them attractive (not that the ideas are
unattractive, but they don't attract *me*).  All I want out of this
thread is for *you* to learn that Emacs is a very large, stable piece
of software, with all the capabilities you need to do what you want to
do.  However, if you want to take advantage of the unique capabilities
of Emacs in editing and as a workspace, you're going to need to work
within the framework of Emacs, which is not optimized for your GUI
purposes.

 > Seems that you never heard about morphs:

That's true, I haven't.  I have a teenage daughter and live in a
country full of lightweight politicians and frivolous journalists who
feed me more fads than I can stomach.  For me, Emacsen are a haven
from such froth.

Re: Add morph library to emacs

[Alin Soare]

[-- Attachment #1: Type: text/plain, Size: 898 bytes --]

>
>
>
>  > The effort you depose to write tabs for emacs can be compared with
>  > the effort to add to emacs a real graphical interface
>
> Once again, you're talking to yourself, making us guess what you mean.
>
>
here is a video to see what I am talking.

http://www.youtube.com/watch?v=Rr-GzmvW35w

In this video you can imagine that the workspace is a frame or buffer or
window of emacs.

I can write a minimal smalltalk system in less than 4000 lines of code ,
and it supports minimal graphics.

Emacs does not have millions of lines of code as you say : just run a
command like 'cat *.c *.h | wc ' in ./src to convince yourself.

No lisp line of code needs be changes, and all functionality would maintain
as now.

Once you have the tendency to say that you use widgets , you have the
tendency to use graphics, so you need a graphical interface.


I bow out of this thread definitively now.

[-- Attachment #2: Type: text/html, Size: 1409 bytes --]