On May 17, 2011, at 4:57 AM, Ken Wesson wrote: > * There's no easy way to restart a REPL or close one; one must close > the REPL tab and also find and kill a java process using ps/kill or > Windows Task Manager or whatever tool, depending on OS.
Cleaning up a REPL involves closing the REPL interaction view, and then stopping the corresponding JVM process via its console (which will be brought to the front if you click the corresponding button in the REPL view — which oddly does not have the right icon in the latest 0.2.1 release…). Note that there are two views because there are 2+ things to manage: the JVM process, and N REPL sessions you have to that JVM. We'll probably add a button to the REPL view itself for sessions connected to VMs started explicitly for REPL interaction (vs. sessions that are connected to an arbitrary network REPL) to close the REPL view and kill the corresponding process in one action. > * There seems to be no right click menu option to (re)load a source > file (either from the open file in the editor, or from the file's > listing in the package explorer) in an open REPL. Run... will start a > new REPL for each file/reload; to (re)load in an existing REPL seems > to require select all, copy, paste, enter, which will clutter up the > REPL history with (possibly very long) blocks of code. Drag and drop > from editor to either pane of REPL does not accomplish anything > either. You certainly can load sources from open editors with one keystroke -- the default is Ctrl-L (maybe Cmd-L on Macs). The contextual menu item (if you right-click in the editor itself) is under Clojure > Load File in REPL (you'll see the current keybinding for your environment there as well). There are also shortcuts for loading only the current top-level expression, and switching to the current file's namespace in the current REPL. > * No separate option to start a project-classpath'd REPL without > loading any files initially. Not true. Right click a project's icon in either the Package Explorer or Project Explorer views, and you'll find a Run As > Clojure Application menu item that will start a VM and connect a REPL to it. This is roughly the only way I ever start REPLs (I dislike having run configurations set up that automatically load files on startup, etc). > * Namespace Browser is nifty, appearing to introspect on the open REPL > to maintain a set of defined symbols; similarly, autocomplete "sees" > your REPL-defined functions and vars. However, it won't update if a > var is redef'd with changed metadata; e.g. if you define a function > without a docstring, then redefine it with a docstring, the docstring > won't get added to the tooltip for its symbol in the Namespace > Browser. In fact, under some circumstances (I'm not sure what), it > won't update promptly to reflect a new function definition at all. > Oddly, it will update eventually but I'm not sure what triggers it. On > the other hand, it has a handy incremental search box at the top. I believe the namespace browser currently only updates on a focus change. Perhaps not ideal, but we also don't want to constantly be polling the process for namespace info either… > * Editor doesn't seem to have an option to reindent a block of code; > going line by line and hitting tab seems to be the only method > provided, short of fully-manual reindentation. This is a much-requested item, and I think is blocked by some of the underlying parser bits. The issue to watch: http://code.google.com/p/counterclockwise/issues/detail?id=139 > * There seems to be no easy way to get the REPL to use the -server vm. > Eclipse seems to only look for JRE runtimes, not JDK runtimes, and if > manually pointed to a JDK directory, it says it can't recognize the > runtime library, whereas if pointed to the JDK /bin subdirectory, it > says it can't recognize the java executable. So it doesn't seem to > provide a way to use the JDK's java runtime instead of the JRE's, and > the JRE's does not recognize the -server flag, at least not on > Windows, for whatever reason. The only apparent workaround is to > manually launch the JDK's java.exe with a manually-set classpath and > appropriate arguments to run the REPL server in it, and then manually > connect to that server to get a REPL pane in Eclipse. This is very easy to set up. First, the JVM stuff is all eclipse-land, and definitely supports using JDKs. Perhaps the relevant documentation would help? http://help.eclipse.org/helios/topic/org.eclipse.jdt.doc.user/tasks/tasks-JREs.htm The Java > Installed JREs panel in the Eclipse preferences is wanting JDK home directories, not /bin directories or any other. You can set -server (or any other VM argument) for any REPL configuration by going to the Run > Run Configurations menu item. In the Run Configurations window, you'll see all of the configs associated with REPLs you've started in the past; clicking on any of them will allow you to modify command line args, VM args, make manual modifications to the classpath used only for that configuration, and so on. This is one reason why I always start my REPLs from the project itself -- I know I'll be re-running the REPL configuration for the project, on which I'll have already set -server, a better heap, etc. If I were to use a random file load as the trigger for starting new REPLs, then I wouldn't be sure as to what sort of VM configuration I'd be getting. (That disconnect is probably a source of confusion we should address, but it is what it is at the moment.) > Please do not take this the wrong way. No "bashing" of either IDE is > intended here. Rather, I would like to see both IDEs improve, and > believe that providing constructive feedback after using both of them > is one way of assisting in that process; and that the maturation of > these tools is crucial while Clojure is still young, lest it get > perceived as having "perpetually" poor tool support or something (by > the non-emacs user contingent, anyway). At this point, it's to be > expected that the IDEs and other tools are still maturing; the > language is what, four years old? If that. But Clojure adoption may be > getting close to hitting the knee of the curve, and if the tools > aren't just a *bit* more polished by then, it may begin to > significantly hinder adoption. No, this sort of side-by-side is great. Hopefully the above points address some of the perceived deficiencies. > Furthermore, I acknowledge the possibility that one or more of the CCW > "missing" features (e.g. restart REPL) is actually present, but if so, > it is not easily discovered within the interface by menu-browsing, > examining toolbar buttons, and similar methods. It may be documented > somewhere else and, say, accessible only via shortcut key; IMO that is > not enough. As has already been discussed once, it is a fact, if an > unfortunate one, that installing the plugin via the Marketplace does > not cause the user to be presented with documentation or links to > same; and it is a general industry standard these days for commands > that exist in a GUI application to be in *some* menu *somewhere*, > usually in a right-click menu on the appropriate target in particular, > and any shortcut key documented there, as in the common example of an > Edit menu including the item "Copy Ctrl+C". If such is the case > for one or more of the features I noted as "missing" from CCW that > Enclojure has, consider the lack of a menu option/toolbar button for > that feature to be the missing feature instead; it is still a problem, > and not much less serious -- but a lot easier to fix! I agree that documentation is simply not there, and I suspect both of these IDE environments require a fair bit of adjustment for those that have never used them. One thing to keep in mind: both CCW and Enclojure try pretty hard to be good citizens on the Eclipse and Netbeans platforms, respectively. That means that (in CCW) rather than having a top-level Clojure item in projects' contextual menus, you'll find the start-a-REPL action as an item in the Run As… submenu, and REPL configurations end up being just a slight twist on standard Java application run configurations instead of being elevated into an area that might be easier to find. These sorts of things should be natural for someone that knows Eclipse, but I can absolutely see how it could make things difficult if you're running Eclipse only to use CCW and Clojure. I don't have any good UI ideas at the moment to address that without really running afoul of Eclipse norms. That said, I think a couple of short screencasts that do a feature walkthrough would probably resolve 90% of the where-can-find-X problem. Cheers, - Chas -- 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 Note that posts from new members are moderated - please be patient with your first post. 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
