[Openmcl-devel] IDE nits
gb at clozure.com
Sat Aug 1 03:53:47 UTC 2009
On Thu, 30 Jul 2009, Doug Currie wrote:
> using Clozure Common Lisp Version 1.4-dev-r12474M-trunk...
> The IDE is much improved; thank you to the contributors.
> A couple nits:
> 1. Using the IDE "Check for Updates..." menu item seemed to hang -- is
> there no timeout? I traced it to CCL using the svn program in /usr/bin
> rather than the newer version I'd installed in /usr/local/bin. Adding
> this to my ccl-init.lisp fixed it for me:
> (setenv "PATH" (concatenate 'string "/usr/local/bin/:" (getenv "PATH")))
GUI applications in OSX inherit their environment from (IIRC) the
"loginwindow" process (or whatever it's called); that environment is
pretty spartan compared to what you typically see in the shell (not
much on $PATH) and your shell init files aren't read.
Apple does have a mechanism for augmenting the environment of all
and this particular issue (telling CCL what "svn" program to use)
can be addressed (in the trunk/1.4 at least) by setting CCL:*SVN-PROGRAM*
to something like "/usr/local/bin/svn".
The last time that I tried this (I think that I renamed /usr/bin/svn,
rather than trying to run a version of svn that'd complain about the
working copy) it quietly failed rather than waiting for something that
was never going to happen; failing more noisily ("couldn't find svn",
"svn ran but complained:" would be better. I wouldn't mind feedback
even if the right version of svn was running, and the ability to
cancel it if there were network problems or something like that.)
> 2. Using incremental search (C-s) extend by word (C-w) command with
> the insert point in front of, e.g., "*code-to-keysym* (make-hash-
> table" the first C-w selects "*code" the second C-w selects "*code-to"
> and the third C-w selects "*code-to-keysym" whereas I would have
> expected "*code-to-keysym*"; the next C-w selects "*code-to-keysym*
> (make" which would have been fine if the third C-w did what I
> expected. Maybe there is an incremental search command to move forward
> a lisp form (like C-M-f) that I am overlooking?
Well, M-F behaves the same way, and both C-W in isearch mode and M-F
behave the same way in the Emacs lisp mode that I use.
Having said that, I think that I'd agree that the behavior you're probably
used to from MCL (apparently, treating #\* as a word constituent rather than
as a word delimeter) is more useful more often.
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
More information about the Openmcl-devel