Thanks, Yoshiki. Yes, you're right, a lot of what I want to do could be done in elisp using emacs as the platform, but then I have no way to tie in nice gui components, which seems a shame in the 21st century. I've thought about using gnuserv, I don't know if that will be flexible enough to be really usable. "Reimplement the whole thing" -- I'm not sure what you mean. Emacs?

I guess I need to play around w/ squeak and see if I like it enough to want to hack the emacs stuff...

Thanks again.

Yoshiki Ohshima wrote:

Hello,

...

I have noticed several threads in the archives where people ask about integrating emacs into Squeak. The standard answer seems to be: why would you want to do that when the built-in editor is so nice?

Is it really seems the standard answer? :-) I actually think the integration has a good point. I imagine that it would be nice if I don't have to move my hands from the home position of keyboard, yet I still have the full control of all Browsers, Inspectors, Workspaces, etc. (mouse-less Squeak?)

# When Nemacs 3.3.2 (based on GNU Emacs 18.55) was the # latest, I read all of the 'info' and tried to do the # examples in it. It was real "wower" for me.

...

As a pre-newbie thinking about starting up in squeak, here's one reason: I'm looking for a platform where I can develop generic info management tools. The ability to plug in an editor with the power of emacs and the extensive package library of emacs is almost a sine qua non... So I'm wondering... how possible would this be to do? Does it even make sense to think about doing it?

I'm sorry but I don't understand what you want to do well... If I understand correctly, you could implement it in Emacs-lisp:-)

Anyway, I think there are several possibilities to integrate Squeak and Emacs.

0. Implement some basic key combination in ParagraphEditor. ...

1. Inferior-Squeak mode. (This doesn't mean that Squeak is inferior:-) By Using OSProcess, use stdin/stdout as a log of a Workspace. This one itself doesn't make much sense.

2. text fragment by text fragment editing in Emacs. Run gnuserv in Emacs and Squeak "asks" the Emacs to edit a certain fragment of text. If the method is lengthy, or you want to perform some decent operation such as query-replace-regexp or dabbrev-expand, having this *option* is a plus. One downside is you cannot evaluate code fragment while you're writing the code, but 1. would help it.

The above three should be not so difficult to do.

3. Write a Lisp interpreter in Squeak. This would be a smooth approach, although there would be lots of labor if you want to run pretty large part of emacs-lisp libraries.

4. Reimplement everything in Squeak. more labor will be needed than 3. but more cleaner implementation. (I wish someone would do this:-)

-- Yoshiki

Phil Mitchell wrote:

Thanks, Yoshiki. Yes, you're right, a lot of what I want to do could be done in elisp using emacs as the platform, but then I have no way to tie in nice gui components, which seems a shame in the 21st century. I've thought about using gnuserv, I don't know if that will be flexible enough to be really usable. "Reimplement the whole thing" -- I'm not sure what you mean. Emacs?

I think he meant reimplementing all of the functionality of Emacs by rewriting it in Squeak/Smalltalk. Of course, this would be an enormous task. (Yoshiki's Option #4, that is.)

But more realistically, you could just implement (in Squeak/Smalltalk) some of the most important text editor features that you want, one at a time, which is much more do-able. For example, just implementing the basic cursor navigation controls would be fairly easy... (I think someone has probably already done this at some point). (I guess this is Option #0.) And many common lisp text processing commands probably already have equivalents in Smalltalk.

Option #3 (truly "plugging in an emacs editor") is probably nearly as huge a task as #4, if you really want to get the various lisp-emacs libraries working. (This is no fault of Squeak's... it would be no easier to, say, try to get a X-based CAD package to run inside a lisp-emacs environment.) But, on the other hand, someone (Nishihara Satoshi) has already written a simple Lisp interpreter in Squeak, which you could play around with and try to build off of. See http://minnow.cc.gatech.edu/squeak/1410 .

(I actually don't consider myself an emacs or lisp guru, although I've used emacs quite a bit. Perhaps there is some magical way to plug an emacs editor into an ST browser that I'm not thinking of. Besides, as a general rule there isn't much need for a powerful text-processing editor when editing Smalltalk source code, since you're nearly always dealing with shortish methods, and you have the power of various browser commands.)

One other thing Yoshiki mentioned was a mouse-less Squeak in which all development tools could be used from the keyboard. This probably wouldn't be too-too difficult, certainly a lot easier than trying to plug a full emacs editor into a browser. (I mean just using the browsers, inspectors, workspaces, menus from the keyboard... not morph manipulation or drawing or anything that really begs for a mouse.) You'd need to have a mechanism for switching focus between windows with the keyboard (someone already did this awhile ago), and a mechanism for switching focus between panes within a window (including buttons, I guess), and then a key-command for popping up menus in a pane, and arrow keys to go through the menu items. I think that would pretty much cover it. Actually, that doesn't sound too bad, anyone up for it? :) (I'm perfectly happy to use a mouse, myself.)

- Doug Way dway@riskmetrics.com

I guess I need to play around w/ squeak and see if I like it enough to want to hack the emacs stuff...

Thanks again.

Yoshiki Ohshima wrote:

...

Hello,

...

I have noticed several threads in the archives where people ask about integrating emacs into Squeak. The standard answer seems to be: why would you want to do that when the built-in editor is so nice?

Is it really seems the standard answer? :-) I actually think the integration has a good point. I imagine that it would be nice if I don't have to move my hands from the home position of keyboard, yet I still have the full control of all Browsers, Inspectors, Workspaces, etc. (mouse-less Squeak?)

# When Nemacs 3.3.2 (based on GNU Emacs 18.55) was the # latest, I read all of the 'info' and tried to do the # examples in it. It was real "wower" for me.

...

As a pre-newbie thinking about starting up in squeak, here's one reason: I'm looking for a platform where I can develop generic info management tools. The ability to plug in an editor with the power of emacs and the extensive package library of emacs is almost a sine qua non... So I'm wondering... how possible would this be to do? Does it even make sense to think about doing it?

I'm sorry but I don't understand what you want to do well... If I understand correctly, you could implement it in Emacs-lisp:-)

Anyway, I think there are several possibilities to integrate Squeak and Emacs.

0. Implement some basic key combination in ParagraphEditor. ...

1. Inferior-Squeak mode. (This doesn't mean that Squeak is inferior:-) By Using OSProcess, use stdin/stdout as a log of a Workspace. This one itself doesn't make much sense.

2. text fragment by text fragment editing in Emacs. Run gnuserv in Emacs and Squeak "asks" the Emacs to edit a certain fragment of text. If the method is lengthy, or you want to perform some decent operation such as query-replace-regexp or dabbrev-expand, having this *option* is a plus. One downside is you cannot evaluate code fragment while you're writing the code, but 1. would help it.

The above three should be not so difficult to do.

3. Write a Lisp interpreter in Squeak. This would be a smooth approach, although there would be lots of labor if you want to run pretty large part of emacs-lisp libraries.

4. Reimplement everything in Squeak. more labor will be needed than 3. but more cleaner implementation. (I wish someone would do this:-)

-- Yoshiki

Lex Spoon wrote:

Doug Way dway@riskmetrics.com wrote:

...

Option #3 (truly "plugging in an emacs editor") is probably nearly as huge a task as #4, if you really want to get the various lisp-emacs libraries working. (This is no fault of Squeak's... it would be no easier to, say, try to get a X-based CAD package to run inside a lisp-emacs environment.) But, on the other hand, someone (Nishihara Satoshi) has already written a simple Lisp interpreter in Squeak, which you could play around with and try to build off of. See http://minnow.cc.gatech.edu/squeak/1410 .

Can you say why you think this would be such a huge task?

Mostly gut feeling :), and the sheer size of the standard Emacs distribution, which includes a fair amount of C code (as Randal said). I'm not enough of a lisp guru to know exactly where the biggest problems would be... I mostly wanted to dispel the naive idea that Squeak is some sort of lower-level graphics library that you could fairly easily plug an emacs editor into. (not that anyone was seriously arguing that point)

Also, Smalltalk and Lisp are both similarly high level languages, so it doesn't really seem that practically useful to try to integrate the two (as opposed to using Smalltalk with C, which is very useful), although I agree it would be interesting. (Probably a better idea to reimplement important aspects of emacs in Smalltalk, such as the text-editing aspects that Bijan mentioned...)

I was also sort of hoping to spur discussion on this, by getting someone to refute my claim with a simple solution that none of us had thought of, if one existed. :) Anyway, I did say "nearly as huge", not impossible. Your breakdown below sounds like a reasonable starting point. Probably "very large" would be a reasonable assessment. :)

- Doug Way dway@riskmetrics.com

E-lisp has the advantage of being a very simple language. It seems the "only" big tasks required are:

    1. Map Emacs's data structures such as "buffers" and "frames" into

something relevant for Squeak.

    2. Implement all the primitives (which requires a good solution to #1).

I don't have a feel for how large these tasks are, but it doesn't seem like it should be *that* bad. The really hard part seems to be the mapping in #1. Eg, perhaps there could be one Squeak window per buffer, and the "mini buffer" could accept commands via pop-up windows, and the messages window is Transcript. One has to come up with parallels like this for all of Emacs's fundamental data structures.

-Lex

PS -- one can also think about what one misses from emacs. For example, it seems harder in Squeak to script key strokes (except in Genie!). Also, there is no support for editting foreign textual formats -- every text pane is optimized for editting Smalltalk code.