>I might look at the JEdit plugin though - JEdit is nice, for simple >editing, which might be good enough for me for now.
I similarly haven't had time to relearn emacs and have used jedit quite sucessfully with jedit-mode. I keep one or more terminal window tabs open each with a REPL launched with rlwrap and then just copy and paste from the associated jedit tab/buffer. With up_arrow and dn_arrow bound to "back_history" and "forward_history" in rlwrap, it's easy to try stuf in the REPL, recall/edit previous lines, etc, and copy/paste back to jedit when necessary. The main advantage for me is this works identically when I have an ssh session open to a server with REPL/rlwrap. I can similarly copy/paste from jedit and do very interactive development directly on the server as well as on my local machine, switching between everything with one or two keystrokes. I'm just about down to a pure keystroke driven dev environment with almost never touching the mouse. Primiive and a bit messy, but it works well. [Footnote to the above - I also have a terminal tab open just for compiles. Using ant (build.xml's adapted from clojure's build), the full cycle includes then tabbing to the ant terminal, recalling/running the build and using rsync to copy changed classes to the server. I can then immediately switch to the server/ssh tab and reload/work with the newly built code.] On Mon, Jan 12, 2009 at 5:28 AM, Korny Sietsma <ko...@sietsma.com> wrote: > > I have had similar problems with enclojure. But having gone through > similar IDE pain working in Ruby on Rails, the Netbeans support ended > up being way ahead of most IDEs, so I have hopes that enclojure will > get there in time. (My biggest annoyance? The fact that you can't > open existing code as a new project - I want to browse > clojure-contrib, but I can only do it by creating a new "hello world" > project first!) > > I'd kind-of like to re-learn emacs - many years ago I was a keen emacs > user - my biggest problem is that I'm on a Mac, and I have to keep > switching between IDEs and PCs (my work desktop is Linux) not to > mention languages. I don't have the spare brain cells to learn > another set of key bindings! I need an IDE with easy built-in help, > and while "M-x slime-cheatsheet" is handy, it doesn't spare me the > world-o-pain when I hit "Alt-w" (one of the few keystrokes my fingers > remember from last time) and my emacs window closes! Argh! > > So I try to stick with IDEs that have everything on menus, so when I > forget the "open file anywhere in project" command for a particular > IDE, I can look it up. (Does Emacs have this, by the way? It doesn't > really have a "project" concept... ) > > I might look at the JEdit plugin though - JEdit is nice, for simple > editing, which might be good enough for me for now. > > Incidentally, if you want a language with an editor built in, why not > look at Smalltalk? I vaguely recall that was a big part of the > original language concept. I haven't ever played with it myself, but > the most popular current flavour seems to be Squeak: > http://www.squeak.org/ > > - Korny > > > On Sun, Jan 11, 2009 at 1:18 PM, e <evier...@gmail.com> wrote: >> >> seems like enclosjure addresses a bunch of my problems/questions. It >> also seems to work like we wanted SLIME to work, more or >> less . . .where you attach to the vm that's used for execution . . . >> only you attach to the REPL, I think, which still accomplishes the >> goal of keeping the editor separate from the memory, but what about >> having the REPL being able to attach to the vm it is managing. Then >> it wouldn't be something that NetBeans/enclosure is doing . . . rather >> something that's part of the language. >> >> So, yeah. enslojure sets up a HelloWorld that you can play with right >> away. In fact, when you click on "build" it even tells you how you >> could run your application from the command line using a java >> command. It jars up you whole clojure project and everything. Nice. >> On the other hand, I couldn't figure out how to use NetBeans' run >> button. it couldn't find main or something. So I also couldn't debug >> using NetBeans' debugger because of this. Also, it isn't clear how to >> get different clojure files to work together. Do you use the (load) >> function? If so, I don't know how the project thinks of relative file >> locations. It's not as clean/clear as java (for a beginner, at least) >> where you just import classes you want to use . . and make >> packages. . . . or modules in python. I don't know what the notion of >> "path" is in clojure. I see the namespace stuff but have no clue how >> to make it work yet. Are you just supposed to use one giant file for >> all your work? That wouldn't be good for teams, for sure. . . only >> for hacking. Also the REPL errors are USELESS to a beginner. >> something about iSeq all the time. The moral for me there was no to >> make an error. Better than where I was before enclojure. Again, I >> contend that a language is only as good as the IDE that has been >> written for it, which is why it's cool to see enclojure coming along >> (even though it means learning NetBeans instead of Eclipse). >> >> >> On Jan 10, 5:31 pm, Paul Mooser <taron...@gmail.com> wrote: >>> If I'm not mistaken, this is fairly close to how SLIME works, when >>> connected to a remote VM. The remote VM is running some server code >>> which allows it to communicate with SLIME, which is running inside of >>> emacs. >>> >>> On Jan 10, 2:15 pm, e <evier...@gmail.com> wrote: >>> >>> > exactly. . . .but I bet a lot of people would just reply that this is >>> > not possible to address since the REPL is the one and only vm. >>> > Disclaimer, I'm only guessing at that, too. I don't understand any of >>> > this, yet. But if that's the case, fix that. Have the REPL send >>> > messages to the vm that's running the program . . . instead of the >>> > REPL being the program. >>> >>> > On Jan 10, 5:00 pm, Paul Mooser <taron...@gmail.com> wrote: >>> >>> > > Yeah, I'm not really sure how I think the problem would be ideally >>> > > solved. It would just be nice for an interactive programming >>> > > environment to be able to recover from all exceptions that happen at a >>> > > higher level than the VM itself. >>> >>> > > On Jan 10, 12:20 pm, "Christian Vest Hansen" <karmazi...@gmail.com> >>> > > wrote: >>> >>> > > > I don't think it is possible to define a way to deal with heap >>> > > > saturation that is general enough to cover all programs written in >>> > > > Clojure, and therefor I don't think this is something that the Clojure >>> > > > runtime should deal with at all. >>> >>> > > > Personally, I only know of two ways to handle OutOfMemoryErrors: 1) >>> > > > let the program blow up and hope someone notices or 2) look at your >>> > > > body, pick the limb you are least likely to be needing pretty soon and >>> > > > cut it off (aka. free some memory) and _then_ yell for help through >>> > > > some hopefully reliable channel. >> > >> > > > > -- > Kornelis Sietsma korny at my surname dot com > kornys at gmail dot com on google chat -- kornys on skype > "Every jumbled pile of person has a thinking part > that wonders what the part that isn't thinking > isn't thinking of" > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
