Release Candidate 1 of new version of CCW
Laurent PETIT
I'm glad to annonce the first public availability of the new version of CCW.
This is mainly the integration of the great work done on CCW by Chas Emerick : a brand new REPL UI, using his clojure.tools.nrepl contribution to clojure-contrib as the back-end server.
You'll find below the "refcard" of the new features for this RC, but first, some important points :
* this version has proven quite stable to me for the past few weeks, but ...
* ... remember that this is still a Release Candidate. If things go wrong, be prepared to go back to the previous version.
How to install ?
* first you need to uninstall your current CCW ( Help > About Eclipse > Installation Detail > [select Counterclockwise] > Clic Uninstall )
* then you install the RC, which is installable from the same update site, but named differently: It's in the "Release Candidate" category, name "Counterclockwise .. REPL UI branch"
You can see the list of new features in the release note (highly recommanded !):
http://code.google.com/p/counterclockwise/wiki/ReleaseNotes#New_REPL_support
Thanks again to Chas for having done a very good job !
--
Laurent
Lee Spector
Very exciting.
A couple of first reactions:
- This seems to have a great deal of promise! Please don't let my critiques below give the impression that I don't see and appreciate that.
- I find it confusing to have no prompt in the REPL. Can that be brought back?
- I'd also like prompts to be shown int the log area; if one cuts/pastes the interactions to someplace else then one loses the ability to distinguish input from output (except by color, which will often go away in the cases in which I do this).
- Can structural editing be turned off in the REPL? I don't like it anywhere ever (really: ever), but I find it particularly problematic in this REPL because it makes me do extra work to get to the end of the line to enter an expression.
- Attempts to "Load file in REPL" when no REPL is running do nothing. One has to Run first. In the most recent prior version of CCW a Load would automatically launch a REPL if one didn't already exist. I considered this a very good feature -- I think it may have been added at my request -- and I'd be sad to see it go. With that feature there's a single method that always works to load a buffer that you're working on; without it there's a distinction between first/subsequent loads that I find to be a nuisance and that I also think is unnecessarily confusing for newbies.
- Output generated during file loading goes to the Console, not to the REPL log. I think it should go to the REPL log (or both, I guess).
- When viewing the REPL one no longer has a Terminate button, which makes it more cumbersome to kill the current launch and re-run. I realize there's a button to get to the console, which does have the Terminate button, but that's another step. In addition, if you click the console button, then the terminate button, and then re-run you'll get a new REPL pane... and the two REPL panes look the same except for the numbers and the fact that one is alive and one is dead (but the liveness/deadness isn't visible from the tab or the contents of the panes until you try to interact with them). Overall I think this will make the kind of run/terminate/re-run cycle in which I often engage quite a bit more cumbersome. I guess my favored solution would be to add a terminate button to the REPL pane and also to make run/load re-use the same pane.
Thanks so much! I look forward to working with this more!
-Lee
> --
> You received this message because you are subscribed to the Google Groups "counterclockwise-users" group.
> To post to this group, send email to clojured...@googlegroups.com.
> To unsubscribe from this group, send email to clojuredev-use...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/clojuredev-users?hl=en.
--
Lee Spector, Professor of Computer Science
Cognitive Science, Hampshire College
893 West Street, Amherst, MA 01002-3359
lspe...@hampshire.edu, http://hampshire.edu/lspector/
Phone: 413-559-5352, Fax: 413-559-5438
Chas Emerick
On Dec 2, 2010, at 11:37 AM, Lee Spector wrote:
>
> Very exciting.
>
> A couple of first reactions:
>
> - This seems to have a great deal of promise! Please don't let my critiques below give the impression that I don't see and appreciate that.
>
> - I find it confusing to have no prompt in the REPL. Can that be brought back?
This will require a rearchitecting of the REPL UI. I would also prefer a prompt, and a unification of the "input" and "log" areas. It's split now so that the input area can reuse the existing Clojure editor bits wholesale (which themselves required a fair bit of work in order to be reused). Unifying the input and log areas will require further changes to allow the Clojure editor components to be applied only to portions of an editor area (StyledText component, for those who know SWT). Definitely possible, and there's plenty of prior art in the Eclipse ecosystem (e.g. Javascript editing, completion, etc when editing javascript embedded in HTML, which is highlighted using a whole different hierarchy of componentry).
> - I'd also like prompts to be shown int the log area; if one cuts/pastes the interactions to someplace else then one loses the ability to distinguish input from output (except by color, which will often go away in the cases in which I do this).
Retaining prompts in the log -- either now or after the above unification is done -- is not something I'd like to see, at least by default. The shift in background highlighting is far more pleasant IMO, and we can make it so that then-current-namespace info (and more, perhaps) are available as a tooltip or somesuch.
Speaking more broadly, I suspect you'll see more and more functionality that might have otherwise been implemented in some text representation be lifted up into the GUI. That's a loss on the accessibility front, but a total win insofar as we can do a lot more with the rich UI that eclipse provides vs. what people are used to in a teletype REPL.
The copy/paste issue is definitely valid. Perhaps we can munge the content being copied before it lands in the clipboard buffer.
> - Can structural editing be turned off in the REPL? I don't like it anywhere ever (really: ever), but I find it particularly problematic in this REPL because it makes me do extra work to get to the end of the line to enter an expression.
Merely an overlooked option, simply because I prefer paredit uniformly.
FYI, you can Control-Enter to send the contents of the input buffer as-is, regardless of cursor position.
> - Output generated during file loading goes to the Console, not to the REPL log. I think it should go to the REPL log (or both, I guess).
That should never happen. If I add a (println "foo") top-level form to a file and load it, I see "foo" printed in the log before the last var in the file is printed.
Are you printing to System/out et al. (as opposed to *out* or *err*) directly? If so, that's a known issue in nREPL (i.e. output to stdout and stderr are not yet available to be multiplexed to connected REPL clients). Coming soon as an option.
> - When viewing the REPL one no longer has a Terminate button, which makes it more cumbersome to kill the current launch and re-run. I realize there's a button to get to the console, which does have the Terminate button, but that's another step. In addition, if you click the console button, then the terminate button, and then re-run you'll get a new REPL pane... and the two REPL panes look the same except for the numbers and the fact that one is alive and one is dead (but the liveness/deadness isn't visible from the tab or the contents of the panes until you try to interact with them). Overall I think this will make the kind of run/terminate/re-run cycle in which I often engage quite a bit more cumbersome. I guess my favored solution would be to add a terminate button to the REPL pane and also to make run/load re-use the same pane.
There will be one or more "terminate" buttons in the REPL panel (at the very least, one for killing the process, and one for simply disconnecting the REPL), as well a hopefully a button on the console to locate a REPL associated with it. That just didn't make it into my dev cycle in favor of more pressing items.
And yes, all feedback is most welcome. :-)
- Chas
Lee Spector
On Dec 2, 2010, at 12:38 PM, Chas Emerick wrote:
>>
>> - I find it confusing to have no prompt in the REPL. Can that be brought back?
>
> This will require a rearchitecting of the REPL UI. I would also prefer a prompt, and a unification of the "input" and "log" areas. It's split now so that the input area can reuse the existing Clojure editor bits wholesale (which themselves required a fair bit of work in order to be reused). Unifying the input and log areas will require further changes to allow the Clojure editor components to be applied only to portions of an editor area (StyledText component, for those who know SWT). Definitely possible, and there's plenty of prior art in the Eclipse ecosystem (e.g. Javascript editing, completion, etc when editing javascript embedded in HTML, which is highlighted using a whole different hierarchy of componentry).
Maybe in the interim the input area could be titled and/or marked in some other way? It's just so blank and inconspicuous as it is, that I didn't know where it was at first (even though I had read the release notes). Usually one gets a prompt OR has input areas designated in some way.
>
>> - I'd also like prompts to be shown int the log area; if one cuts/pastes the interactions to someplace else then one loses the ability to distinguish input from output (except by color, which will often go away in the cases in which I do this).
>
> Retaining prompts in the log -- either now or after the above unification is done -- is not something I'd like to see, at least by default. The shift in background highlighting is far more pleasant IMO, and we can make it so that then-current-namespace info (and more, perhaps) are available as a tooltip or somesuch.
>
> Speaking more broadly, I suspect you'll see more and more functionality that might have otherwise been implemented in some text representation be lifted up into the GUI. That's a loss on the accessibility front, but a total win insofar as we can do a lot more with the rich UI that eclipse provides vs. what people are used to in a teletype REPL.
>
> The copy/paste issue is definitely valid. Perhaps we can munge the content being copied before it lands in the clipboard buffer.
I like the background highlighting too, and I'm all in favor of more info being shown in the GUI, but doing that and keeping the (minimal) information in the text aren't mutually exclusive. You could do exactly what you're doing now but also print the standard prompts, which are both what everyone will expect coming from other REPLs and more compatible with various uses of logs as text. Munging the copy/paste text seems like an ugly way to get back basic functionality that could more simply and elegantly just be retained.
>
>> - Can structural editing be turned off in the REPL? I don't like it anywhere ever (really: ever), but I find it particularly problematic in this REPL because it makes me do extra work to get to the end of the line to enter an expression.
>
> Merely an overlooked option, simply because I prefer paredit uniformly.
Great!
> FYI, you can Control-Enter to send the contents of the input buffer as-is, regardless of cursor position.
I noticed that and it may be handy. It will be better, though, when I can turn off the "incorrectly anticipatory autotyping" (structural editing :-) feature and just end up at the end of the line naturally, and use the return key as usual.
Incidentally, typing ")" by itself to the REPL produces a reverse highlighted ")", because it's unmatched, which is fine since that's what happens in the editors too. But this one can't be deleted with the delete key. I found that I could delete it by selecting it (with a mouse drag) and then hitting delete, but it's weird that you can't back over these to delete them.
>
>> - Output generated during file loading goes to the Console, not to the REPL log. I think it should go to the REPL log (or both, I guess).
>
> That should never happen. If I add a (println "foo") top-level form to a file and load it, I see "foo" printed in the log before the last var in the file is printed.
>
> Are you printing to System/out et al. (as opposed to *out* or *err*) directly? If so, that's a known issue in nREPL (i.e. output to stdout and stderr are not yet available to be multiplexed to connected REPL clients). Coming soon as an option.
I am printing with println. Perhaps you only tried this loading a file into a REPL that was already running? I should have specified that this is the behavior when running code for the first time.... which maybe you're not calling loading... Anyway, when I create a new project, add a single source file containing:
---
(ns empty)
(println :foo)
---
And then hit run I get:
---
:foo
---
in the console window but only:
---
;; Clojure 1.2.0
---
in the log pane of the REPL window.
>
> There will be one or more "terminate" buttons in the REPL panel (at the very least, one for killing the process, and one for simply disconnecting the REPL), as well a hopefully a button on the console to locate a REPL associated with it. That just didn't make it into my dev cycle in favor of more pressing items.
Wonderful.
Thanks,
-Lee
Laurent PETIT
I will not have time to answer it right now (already bed time here in France !), but hope to do so soon!
Such similar feedback from the other very welcome as well !
And please remember that it's still release candidate, not seen by many eyes, so don't apologize for your (constructive !) remarks !
Cheers,
--
Laurent
--
Laurent PETIT
Laurent PETIT
Incidentally, typing ")" by itself to the REPL produces a reverse highlighted ")", because it's unmatched, which is fine since that's what happens in the editors too. But this one can't be deleted with the delete key. I found that I could delete it by selecting it (with a mouse drag) and then hitting delete, but it's weird that you can't back over these to delete them.
Well, in fact you highlighted here a bug that is also present in the editor when in strict mode. Bug now fixed and ready to be integrated !
Chas Emerick
On Dec 2, 2010, at 2:37 PM, Lee Spector wrote:
>
> On Dec 2, 2010, at 12:38 PM, Chas Emerick wrote:
>>>
>>> - I find it confusing to have no prompt in the REPL. Can that be brought back?
>>
>> This will require a rearchitecting of the REPL UI. I would also prefer a prompt, and a unification of the "input" and "log" areas. It's split now so that the input area can reuse the existing Clojure editor bits wholesale (which themselves required a fair bit of work in order to be reused). Unifying the input and log areas will require further changes to allow the Clojure editor components to be applied only to portions of an editor area (StyledText component, for those who know SWT). Definitely possible, and there's plenty of prior art in the Eclipse ecosystem (e.g. Javascript editing, completion, etc when editing javascript embedded in HTML, which is highlighted using a whole different hierarchy of componentry).
>
> Maybe in the interim the input area could be titled and/or marked in some other way? It's just so blank and inconspicuous as it is, that I didn't know where it was at first (even though I had read the release notes). Usually one gets a prompt OR has input areas designated in some way.
Yeah, we can put some gray text in the input area ("Enter Clojure expressions here…"), and wipe it when it gets focus (similar to what's done in many web forms).
>> The copy/paste issue is definitely valid. Perhaps we can munge the content being copied before it lands in the clipboard buffer.
>
> I like the background highlighting too, and I'm all in favor of more info being shown in the GUI, but doing that and keeping the (minimal) information in the text aren't mutually exclusive. You could do exactly what you're doing now but also print the standard prompts, which are both what everyone will expect coming from other REPLs and more compatible with various uses of logs as text. Munging the copy/paste text seems like an ugly way to get back basic functionality that could more simply and elegantly just be retained.
IMO, matching "what people expect" shouldn't be the objective; rather, I'd prefer to find global maxima for user experience and productivity. Copy/paste is the functional determinant AFAICT, so all other things being equal, I'd rather sully the implementation of a relatively infrequent operation than compromise on the user experience of something that's looked at and used constantly.
That said, I'll tinker with some options. Being able to choose between no prompts, =>, and ns.name=> in the log might make sense. Any other opinions/takers on this feature?
>>> - Output generated during file loading goes to the Console, not to the REPL log. I think it should go to the REPL log (or both, I guess).
>>
>> That should never happen. If I add a (println "foo") top-level form to a file and load it, I see "foo" printed in the log before the last var in the file is printed.
>>
>> Are you printing to System/out et al. (as opposed to *out* or *err*) directly? If so, that's a known issue in nREPL (i.e. output to stdout and stderr are not yet available to be multiplexed to connected REPL clients). Coming soon as an option.
>
> I am printing with println. Perhaps you only tried this loading a file into a REPL that was already running? I should have specified that this is the behavior when running code for the first time.... which maybe you're not calling loading... Anyway, when I create a new project, add a single source file containing:
>
> ---
> (ns empty)
>
> (println :foo)
> ---
>
> And then hit run I get:
>
> ---
> :foo
> ---
>
> in the console window but only:
>
> ---
> ;; Clojure 1.2.0
> ---
>
> in the log pane of the REPL window.
OK, I think I have an idea of what's going on. I'll follow up with details if warranted.
- Chas
Laurent PETIT
Yeah, we can put some gray text in the input area ("Enter Clojure expressions here…"), and wipe it when it gets focus (similar to what's done in many web forms).
On Dec 2, 2010, at 2:37 PM, Lee Spector wrote:
>
> On Dec 2, 2010, at 12:38 PM, Chas Emerick wrote:
>>>
>>> - I find it confusing to have no prompt in the REPL. Can that be brought back?
>>
>> This will require a rearchitecting of the REPL UI. I would also prefer a prompt, and a unification of the "input" and "log" areas. It's split now so that the input area can reuse the existing Clojure editor bits wholesale (which themselves required a fair bit of work in order to be reused). Unifying the input and log areas will require further changes to allow the Clojure editor components to be applied only to portions of an editor area (StyledText component, for those who know SWT). Definitely possible, and there's plenty of prior art in the Eclipse ecosystem (e.g. Javascript editing, completion, etc when editing javascript embedded in HTML, which is highlighted using a whole different hierarchy of componentry).
>
> Maybe in the interim the input area could be titled and/or marked in some other way? It's just so blank and inconspicuous as it is, that I didn't know where it was at first (even though I had read the release notes). Usually one gets a prompt OR has input areas designated in some way.
Yeah, would be great.
IMO, matching "what people expect" shouldn't be the objective; rather, I'd prefer to find global maxima for user experience and productivity. Copy/paste is the functional determinant AFAICT, so all other things being equal, I'd rather sully the implementation of a relatively infrequent operation than compromise on the user experience of something that's looked at and used constantly.
>> The copy/paste issue is definitely valid. Perhaps we can munge the content being copied before it lands in the clipboard buffer.
>
> I like the background highlighting too, and I'm all in favor of more info being shown in the GUI, but doing that and keeping the (minimal) information in the text aren't mutually exclusive. You could do exactly what you're doing now but also print the standard prompts, which are both what everyone will expect coming from other REPLs and more compatible with various uses of logs as text. Munging the copy/paste text seems like an ugly way to get back basic functionality that could more simply and elegantly just be retained.
That said, I'll tinker with some options. Being able to choose between no prompts, =>, and ns.name=> in the log might make sense. Any other opinions/takers on this feature?
The essence of my problem is knowing what the current namespace is. Currently, it's in the View title, and it takes time for my eyes to go spot this, and come back to the input area. If the namespace were just above the input area, I think I'd have no problem (so maybe the "goal" is not to have a prompt, but to understand what features we miss from not having a prompt).
What I dislike with the prompt is the fact that it wastes horizontal space on the input area, when it would waste no space at all if set right above the input area.
OK, I think I have an idea of what's going on. I'll follow up with details if warranted.
>>> - Output generated during file loading goes to the Console, not to the REPL log. I think it should go to the REPL log (or both, I guess).
>>
>> That should never happen. If I add a (println "foo") top-level form to a file and load it, I see "foo" printed in the log before the last var in the file is printed.
>>
>> Are you printing to System/out et al. (as opposed to *out* or *err*) directly? If so, that's a known issue in nREPL (i.e. output to stdout and stderr are not yet available to be multiplexed to connected REPL clients). Coming soon as an option.
>
> I am printing with println. Perhaps you only tried this loading a file into a REPL that was already running? I should have specified that this is the behavior when running code for the first time.... which maybe you're not calling loading... Anyway, when I create a new project, add a single source file containing:
>
> ---
> (ns empty)
>
> (println :foo)
> ---
>
> And then hit run I get:
>
> ---
> :foo
> ---
>
> in the console window but only:
>
> ---
> ;; Clojure 1.2.0
> ---
>
> in the log pane of the REPL window.
- Chas
Lee Spector
On Dec 2, 2010, at 4:26 PM, Chas Emerick wrote:
>
> IMO, matching "what people expect" shouldn't be the objective; rather, I'd prefer to find global maxima for user experience and productivity.
Yeah, but if you can do what people expect AND provide a good user experience/productivity then that's even better. Meeting expectations isn't nothing, and making newcomers (or even frequent users who also frequently use other systems) comfortable is worth quite a lot IMO.
> Copy/paste is the functional determinant AFAICT, so all other things being equal, I'd rather sully the implementation of a relatively infrequent operation than compromise on the user experience of something that's looked at and used constantly.
Maybe I'm atypical but I cut/paste REPL text frequently. I do it preparing teaching materials, helping students by email, and documenting what I've done in my own research projects. In other environments I sometimes do some of this via "save" rather than cut/paste, although I don't see how to do that in Eclipse.
Even aside from cut/paste/save I think that the prompt is a positive feature, not a compromise. And I think it'd be weird to have cut/paste produce something other than what was highlighted at the time of the cut. This strikes me as a case of a system trying to be smarter than it can really be, which I usually find causes more trouble in the long run; actually, I guess that feeling is also behind my dislike of the automatic typing in the strict editing mode.
> That said, I'll tinker with some options. Being able to choose between no prompts, =>, and ns.name=> in the log might make sense. Any other opinions/takers on this feature?
I'm not an "other" taker, just the same cranky guy :-), but I'd be happy with that choice. My vote for the default would be ns.name=>, for the sake of consistency and expectations; again, I agree these aren't everything but they're also not nothing.
Thanks Chas!!!!!
-Lee
Chas Emerick
>> The copy/paste issue is definitely valid. Perhaps we can munge the content being copied before it lands in the clipboard buffer.IMO, matching "what people expect" shouldn't be the objective; rather, I'd prefer to find global maxima for user experience and productivity. Copy/paste is the functional determinant AFAICT, so all other things being equal, I'd rather sully the implementation of a relatively infrequent operation than compromise on the user experience of something that's looked at and used constantly.
>
> I like the background highlighting too, and I'm all in favor of more info being shown in the GUI, but doing that and keeping the (minimal) information in the text aren't mutually exclusive. You could do exactly what you're doing now but also print the standard prompts, which are both what everyone will expect coming from other REPLs and more compatible with various uses of logs as text. Munging the copy/paste text seems like an ugly way to get back basic functionality that could more simply and elegantly just be retained.
That said, I'll tinker with some options. Being able to choose between no prompts, =>, and ns.name=> in the log might make sense. Any other opinions/takers on this feature?
The essence of my problem is knowing what the current namespace is. Currently, it's in the View title, and it takes time for my eyes to go spot this, and come back to the input area. If the namespace were just above the input area, I think I'd have no problem (so maybe the "goal" is not to have a prompt, but to understand what features we miss from not having a prompt).
What I dislike with the prompt is the fact that it wastes horizontal space on the input area, when it would waste no space at all if set right above the input area.
Lee Spector
On Dec 2, 2010, at 9:03 PM, Chas Emerick wrote:
>
> I experimented with having the log (temporarily) contain a prompt at the bottom, as one would expect. It just looked bizarre.
Just to be clear I wasn't suggesting this. I was suggesting that when an expression from the input area gets transferred to the log area it shows up there with a prompt (which I'd also like to see in the input area). So you'd end up with stuff like this in the log:
user=> (+ 1 2)
3
user=> (* 3 4)
12
rather than just:
(+ 1 2)
3
(* 3 4)
12
> I wonder if we could always show the namespace in the background of the input area, off to the upper left of it (with similar styling as the "Enter Clojure expressions here…" text).
Sounds reasonable to me (although not as nice as an old-fashioned ns prompt).
-Lee
ka
Here are my opinions about the (going to be awesome) new ccw repl :-)
1. As Lee said, bring back the => in the REPL.
2. Somehow I miss seeing the stdout/stderr in the REPL itself, now I
need to switch windows / or watch two windows.
3. Please enable paredit in the REPL input area!
4. Need easier shortcuts from editor to repl & vice versa. (Ctrl+Alt+Q
R) is too much.
5. Somehow automatic building takes much more time now?
6. *print-length* not working the new REPL.
7. How do I close (shutdown) the nREPL? Little description of the life-
cycle of nREPL and how you guys use it will be nice.
Thanks for the great improvements!
ka
8. clojure.test report output doesn't come in the REPL by default, but
this works: (binding [clojure.test/*test-out* *out*] ...). Is it
possible to unify the console & the REPL output/log window? Currently
it seems *out*, *err* print in the repl log area, whereas System/out,
System/err print in the console.
Chas Emerick
On Dec 3, 2010, at 6:07 PM, ka wrote:
> Here are my opinions about the (going to be awesome) new ccw repl :-)
I'll respond to the points that are within my purview.
> 1. As Lee said, bring back the => in the REPL.
Noted. :-)
> 2. Somehow I miss seeing the stdout/stderr in the REPL itself, now I
> need to switch windows / or watch two windows.
I think Lee mentioned this as well; nREPL does not yet offer the option of multiplexing stdout and stdin to its clients. Coming soon.
> 4. Need easier shortcuts from editor to repl & vice versa. (Ctrl+Alt+Q
> R) is too much.
That is a default to match the eclipse idiom; e.g. just type Ctrl+Alt+Q, and a popup will appear showing all of the different view-switching options.
Of course, you can easily rebind shortcuts to match your preferences (I happen to have switch-to-REPL bound to Cmd-T). At some point, I'd like to set up a binding context for the REPL so that the same binding can be used to switch to the REPL from the editor, and then again be used from the REPL to switch back to the editor.
> 6. *print-length* not working the new REPL.
Good catch. That's an nREPL bug.
> 7. How do I close (shutdown) the nREPL? Little description of the life-
> cycle of nREPL and how you guys use it will be nice.
Lee touched on this as well. The lifecycle is roughly:
1. You launch a Clojure/JVM process, which ccw configures to start a new REPL server (just before loading any files you configure in the launch settings IIRC).
2. The new REPL server acks the port it found to open on to ccw…
3. …which allows ccw to connect to the REPL server, and open a corresponding view.
To:
* kill the underlying process: go to the Console corresponding to the JVM process the REPL view was opened for, and hit the "stop" button as before.
* close ccw's connection to the REPL server: just close the REPL view
* shut down the nREPL server: Hrm, looks like there's no way to do this yet. I'll add it to the todo list.
This is (almost) the same issue as #2. clojure.test (unfortunately IMO) captures the value of *out* when it's loaded. Thus, when you load that namespace (probably transitively as part of loading your code), *test-out* retains an effectively-dead Writer.
FWIW, resolving these stdout/stderr/capturing *out* issues are my #1 priority for nREPL.
- Chas
Zmitro Lapcjonak
> R) is too much.
press and don't release - popup with all views is displayed)
Further, as Chas answered - you may redefine the keys
(as I did: Ctrl+F6 = switch Editors --> Ctrl+Tab)
> 6. *print-length* not working the new REPL.
> 7. How do I close (shutdown) the nREPL? Little description of the life-
and then SELECTed from a db table about 80 thousand of rows :)
One more strange/unclear/unpleasant thing: key navigation/selection
doesn't work in the repl log view, only mouse - any key press set
focus
to repl input area.
Can we already report issues in the bug-tracker? :)
--
Zmi La