From: Dan M. <dn...@po...> - 2005-03-22 05:55:04
|
Hi all, Apologies if this goes over a previous feature request or list topic. I didn't see anything similar in a cursory Google search nor a quick peruse through my IMAP mailbox of j-devel mails. Does j have minibuffers, perhaps as an experimental feature, or are they on the docket for a later revision of j? To be clear, I may not need minibuffers in the (X)Emacs sense. All I really want at this stage is a split window which shows me my native command line, in my case either Windows XP's cmd.exe (the usual case for me) or, when I run j on OS X, zsh. I want this primarily so I can use irb, the interactive ruby interpreter, in j as I edit. Ditto for various console Lisps. Bonus points if I can write a function in ABCL that will take the contents of the current buffer and redirect it as stdin to the minibuffer (I already have commands in j to spawn a cmd.exe outside of j and eval either a saved file or selected code). I'm highly suspicious this functionality is already in j, and I just can't find it. Thanks in advance! -- Dan Moniz <dn...@po...> [http://www.pobox.com/~dnm/] |
From: Peter G. <pe...@ar...> - 2005-03-22 16:28:11
|
On Mon, 21 Mar 2005 at 21:54:52 -0800, Dan Moniz wrote: > Hi all, > > Apologies if this goes over a previous feature request or list topic. I= = > didn't see anything similar in a cursory Google search nor a quick = > peruse through my IMAP mailbox of j-devel mails. > > Does j have minibuffers, perhaps as an experimental feature, or are the= y = > on the docket for a later revision of j? > > To be clear, I may not need minibuffers in the (X)Emacs sense. All I = > really want at this stage is a split window which shows me my native = > command line, in my case either Windows XP's cmd.exe (the usual case fo= r = > me) or, when I run j on OS X, zsh. > > I want this primarily so I can use irb, the interactive ruby = > interpreter, in j as I edit. Ditto for various console Lisps. =2E.. > I'm highly suspicious this functionality is already in j, and I just = > can't find it. Sounds like what you want is a shell buffer. Add this line to ~/.j/prefs (or C:\.j\prefs): enableExperimentalFeatures =3D true Then do Alt X, "shell" (or Alt F9, which is its default mapping). On Windows XP this should get you a somewhat functional shell buffer. (If you want a split window, F10 is your friend.) On Unix platforms (inluding OS X), shell buffers require jpty, which you'll need to build from source (jpty.c in the src/jpty directory); you should put the jpty executable somewhere in your PATH. I don't have an OS X machine, so I don't know whether the current version of jpty.c builds or works on OS X. Some years ago I spent a few hours on a borrowed Mac trying to get an earlier version of jpty to work on an earlier version of OS X, without success (but I don't think I had the right development tool setup on that machine). On Windows, cmd.exe should work without jpty. At one point, you could even use bash under Cygwin if you built jpty with Cygwin gcc, but I haven't tried that in a long time. Shell buffers work pretty well on Linux. I like shell buffers, and I use Linux myself, so that combination has had lots of exercise. On the other hand, I use Windows very rarely and OS X not at all, so shell buffer support on those platforms is not nearly as good (and in the case of OS X, possibly nonexistent). Tested patches are always welcome. Theoretically, Tab in a shell buffer does shell-like completion, and Ctrl P and Ctrl N navigate through command history. You can use the shellFileName preference to use a non-default shell: shellFileName =3D zsh There's also a shellPromptPattern preference to let you specify a regexp to match your normal prompt (in case the default regexp isn't smart enough), and a shellOutputLimit preference that controls how many lines the buffer can grow to; the default is 1000 but I normally bump it up a bit: shellOutputLimit =3D 50000 Once you have jpty built and installed, you can also do things like Alt X, "ssh", which gives you a shell buffer on a remote host. Console Lisps are best run in Lisp shells: do Alt X, "lisp [path-to- lisp-executable]", e.g. Alt X, "lisp /usr/bin/lisp" to run cmucl on Linux. If you don't specify a Lisp executable, you'll get ABCL. Lisp shells for Lisps other than ABCL require jpty on Unix platforms. There's also slime-for-j, which is supported for ABCL, SBCL, and Allegro: Alt X, "slime [path-to-lisp-executable]". Lisp shells honor shellOutputLimit, which is why mine is normally set so high. > Bonus points if I can write a function in ABCL that will take the > contents of the current buffer and redirect it as stdin to the > minibuffer (I already have commands in j to spawn a cmd.exe outside > of j and eval either a saved file or selected code). I don't think this exists per se, but it shouldn't be too hard to write such a thing. There might be something vaguely similar in slime.lisp (slime-eval-region, maybe). -Peter |
From: Dan M. <dn...@po...> - 2005-03-22 19:33:05
|
Hi Peter! Peter Graves wrote: > On Mon, 21 Mar 2005 at 21:54:52 -0800, Dan Moniz wrote: [snip] > Sounds like what you want is a shell buffer. > > Add this line to ~/.j/prefs (or C:\.j\prefs): > > enableExperimentalFeatures = true > > Then do Alt X, "shell" (or Alt F9, which is its default mapping). > > On Windows XP this should get you a somewhat functional shell buffer. > (If you want a split window, F10 is your friend.) This worked great. I *knew* it was in there somewhere. Thanks! > On Unix platforms (inluding OS X), shell buffers require jpty, which > you'll need to build from source (jpty.c in the src/jpty directory); > you should put the jpty executable somewhere in your PATH. > > I don't have an OS X machine, so I don't know whether the current > version of jpty.c builds or works on OS X. Some years ago I spent a few > hours on a borrowed Mac trying to get an earlier version of jpty to > work on an earlier version of OS X, without success (but I don't think > I had the right development tool setup on that machine). I'll try this sometime this week and report back. > On Windows, cmd.exe should work without jpty. At one point, you could > even use bash under Cygwin if you built jpty with Cygwin gcc, but I > haven't tried that in a long time. > > Shell buffers work pretty well on Linux. I like shell buffers, and I > use Linux myself, so that combination has had lots of exercise. On the > other hand, I use Windows very rarely and OS X not at all, so shell > buffer support on those platforms is not nearly as good (and in the > case of OS X, possibly nonexistent). Tested patches are always welcome. > > Theoretically, Tab in a shell buffer does shell-like completion, and > Ctrl P and Ctrl N navigate through command history. Tab, C-p, and C-n all work in the Windows (cmd.exe) shell. I notice when I run irb (as an example) with readline completion from a cmd.exe spawned inside a shell buffer, tab isn't recognized, so I think it's not being passed to irb for some reason. Where ought I look in the j code to see if I can diagnose this and hack up a patch? [snip] > Console Lisps are best run in Lisp shells: do Alt X, "lisp [path-to- > lisp-executable]", e.g. Alt X, "lisp /usr/bin/lisp" to run cmucl on > Linux. If you don't specify a Lisp executable, you'll get ABCL. Lisp > shells for Lisps other than ABCL require jpty on Unix platforms. > > There's also slime-for-j, which is supported for ABCL, SBCL, and > Allegro: Alt X, "slime [path-to-lisp-executable]". I notice the j website cautioned "SLIME for j" as being very alpha code; I assume it's further along now given the development on ABCL? I'll try this with ACL and CLISP later today on my Windows machine. [snip] >>Bonus points if I can write a function in ABCL that will take the >>contents of the current buffer and redirect it as stdin to the >>minibuffer (I already have commands in j to spawn a cmd.exe outside >>of j and eval either a saved file or selected code). > > I don't think this exists per se, but it shouldn't be too hard to > write such a thing. There might be something vaguely similar in > slime.lisp (slime-eval-region, maybe). I'll look into it. Sounds good! Thanks for your informative reply, and for your work on j! -- Dan Moniz <dn...@po...> [http://www.pobox.com/~dnm/] |
From: Peter G. <pe...@ar...> - 2005-03-23 00:14:26
|
On Tue, 22 Mar 2005 at 11:32:50 -0800, Dan Moniz wrote: > Tab, C-p, and C-n all work in the Windows (cmd.exe) shell. I notice when > I run irb (as an example) with readline completion from a cmd.exe > spawned inside a shell buffer, tab isn't recognized, so I think it's not > being passed to irb for some reason. Where ought I look in the j code to > see if I can diagnose this and hack up a patch? You're right. The tab isn't being passed on; it's the shell buffer itself that's doing the completion. See shellTab() (Shell.java:626) and the tab() function that does the real work (Shell.java:287). Shell buffers only send input to the actual shell program when you hit Enter. I don't think there's any easy way to fix this. In principle, you could write a version of shellTab() that would send the prefix string and the tab character to the shell program and then gather up the response and do the right thing. It's hard to implement a general version of this for real shells, which have a great deal of diversity in their tab- completion behavior, but maybe you could make it work for the special case of irb. > [snip] > > > There's also slime-for-j, which is supported for ABCL, SBCL, and > > Allegro: Alt X, "slime [path-to-lisp-executable]". > > I notice the j website cautioned "SLIME for j" as being very alpha code; > I assume it's further along now given the development on ABCL? The current version of slime-for-j (in CVS) doesn't try to do very much, compared to the real slime-for-emacs, but it isn't particularly buggy. > I'll try this with ACL and CLISP later today on my Windows machine. Slime-for-j needs a threaded Lisp, so it doesn't support CLISP at all, and I've never tried it with Allegro on Windows (the trial version doesn't seem to offer a blindingly obvious way to run a bare repl). -Peter |