* Add morph library to emacs @ 2012-03-04 3:16 Alin Soare 2012-03-05 7:22 ` Stephen J. Turnbull 0 siblings, 1 reply; 6+ messages in thread From: Alin Soare @ 2012-03-04 3:16 UTC (permalink / raw) To: Nix Cc: Juri Linkov, Emacs Dev, Tom Tromey, martin rudalics, Stefan Monnier, PJ Weisberg, Stephen J. Turnbull [-- 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 --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Add morph library to emacs 2012-03-04 3:16 Add morph library to emacs Alin Soare @ 2012-03-05 7:22 ` Stephen J. Turnbull 2012-03-06 1:09 ` Alin Soare 0 siblings, 1 reply; 6+ messages in thread From: Stephen J. Turnbull @ 2012-03-05 7:22 UTC (permalink / raw) To: Alin Soare; +Cc: Emacs Dev 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"). ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Add morph library to emacs 2012-03-05 7:22 ` Stephen J. Turnbull @ 2012-03-06 1:09 ` Alin Soare 2012-03-06 1:53 ` Óscar Fuentes 2012-03-06 2:31 ` Stephen J. Turnbull 0 siblings, 2 replies; 6+ messages in thread From: Alin Soare @ 2012-03-06 1:09 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: Emacs Dev [-- 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 --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Add morph library to emacs 2012-03-06 1:09 ` Alin Soare @ 2012-03-06 1:53 ` Óscar Fuentes 2012-03-06 2:31 ` Stephen J. Turnbull 1 sibling, 0 replies; 6+ messages in thread From: Óscar Fuentes @ 2012-03-06 1:53 UTC (permalink / raw) To: emacs-devel 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] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Add morph library to emacs 2012-03-06 1:09 ` Alin Soare 2012-03-06 1:53 ` Óscar Fuentes @ 2012-03-06 2:31 ` Stephen J. Turnbull 2012-03-06 2:56 ` Alin Soare 1 sibling, 1 reply; 6+ messages in thread From: Stephen J. Turnbull @ 2012-03-06 2:31 UTC (permalink / raw) To: Alin Soare; +Cc: Emacs Dev 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Add morph library to emacs 2012-03-06 2:31 ` Stephen J. Turnbull @ 2012-03-06 2:56 ` Alin Soare 0 siblings, 0 replies; 6+ messages in thread From: Alin Soare @ 2012-03-06 2:56 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: Emacs Dev [-- 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 --] ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-03-06 2:56 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-03-04 3:16 Add morph library to emacs Alin Soare 2012-03-05 7:22 ` Stephen J. Turnbull 2012-03-06 1:09 ` Alin Soare 2012-03-06 1:53 ` Óscar Fuentes 2012-03-06 2:31 ` Stephen J. Turnbull 2012-03-06 2:56 ` Alin Soare
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).