From alok.bisani+climacs-devel at gmail.com Sun Jul 9 11:54:32 2006 From: alok.bisani+climacs-devel at gmail.com (Alok) Date: Sun, 9 Jul 2006 12:54:32 +0100 Subject: [climacs-devel] highlight expression region in cursor Message-ID: <7710db080607090454h4a68e76bw2ee270b10a420e90@mail.gmail.com> Hello there, Don't know if there is a Climacs user group and hence my post here. I have a question about a possible feature in Climacs (Also see Google groups - http://tinyurl.com/f9rdp ) 1. Is it possible in Climacs to highlight the current Lisp expression (in the region of the cursor position) with a slightly different background shade? 2. Further, is it also possible to show the current nested Lisp expression with a slightly progressive difference in background shade, with each increasing nesting level of the expression displayed in an increased shade of the background colour? Its just eye candy, but a huge difference to readability to Lisp code. I don't know of any way to do this in Vim or Emacs yet. Alok From athas at sigkill.dk Sun Jul 9 16:59:39 2006 From: athas at sigkill.dk (Troels Henriksen) Date: Sun, 09 Jul 2006 18:59:39 +0200 Subject: [climacs-devel] highlight expression region in cursor In-Reply-To: <7710db080607090454h4a68e76bw2ee270b10a420e90@mail.gmail.com> (Alok's message of "Sun, 9 Jul 2006 12:54:32 +0100") References: <7710db080607090454h4a68e76bw2ee270b10a420e90@mail.gmail.com> Message-ID: <87bqry1zpg.fsf@sigkill.dk> Alok writes: > Hello there, > > Don't know if there is a Climacs user group and hence my post > here. I have a question about a possible feature in Climacs (Also see > Google groups - http://tinyurl.com/f9rdp ) There is no Climacs user group, mostly because so very few people use Climacs. I hope you are aware that Climacs is nowhere near complete - if you can use it (or hack on it!), then that's great, but don't expect a complete Emacs replacement just yet. :-) Alok writes: > 1. Is it possible in Climacs to highlight the current Lisp expression > (in the region of the cursor position) with a slightly different > background shade? > > 2. Further, is it also possible to show the current nested Lisp > expression with a slightly progressive difference in background shade, > with each increasing nesting level of the expression displayed in an > increased shade of the background colour? No, not out-of-the-box, but no 1. should be pretty trivial to hack up. No 2. will be slightly more difficult to do properly, though. I'll take a swing at it once I get access to a Lisp system. -- \ Troels "Athas" /\ Henriksen From alok.bisani at gmail.com Sun Jul 9 11:46:50 2006 From: alok.bisani at gmail.com (Alok Bisani) Date: Sun, 9 Jul 2006 12:46:50 +0100 Subject: [climacs-devel] highlight expression region in cursor Message-ID: <7710db080607090446s7a6afc27r6195e0940856e198@mail.gmail.com> Hello there, Don't know if there is a Climacs user group and hence my post here. I have a question about a possible feature in Climacs (Also see Google groups - http://tinyurl.com/f9rdp ) 1. Is it possible in Climacs to highlight the current Lisp expression (in the region of the cursor position) with a slightly different background shade? 2. Further, is it also possible to show the current nested Lisp expression with a slightly progressive difference in background shade, with each increasing nesting level of the expression displayed in an increased shade of the background colour? Its just eye candy, but a huge difference to readability to Lisp code. I don't know of any way to do this in Vim or Emacs yet. Alok. From alok.bisani+climacs-devel at gmail.com Sun Jul 9 22:42:02 2006 From: alok.bisani+climacs-devel at gmail.com (Alok) Date: Sun, 9 Jul 2006 23:42:02 +0100 Subject: [climacs-devel] highlight expression region in cursor In-Reply-To: <87bqry1zpg.fsf@sigkill.dk> References: <7710db080607090454h4a68e76bw2ee270b10a420e90@mail.gmail.com> <87bqry1zpg.fsf@sigkill.dk> Message-ID: <7710db080607091542m376924efm7c363e7b0530f863@mail.gmail.com> On 7/9/06, Troels Henriksen wrote: > Alok writes: > > 1. Is it possible in Climacs to highlight the current Lisp expression > > (in the region of the cursor position) with a slightly different > > background shade? > > > > 2. Further, is it also possible to show the current nested Lisp > > expression with a slightly progressive difference in background shade, > > with each increasing nesting level of the expression displayed in an > > increased shade of the background colour? > > No, not out-of-the-box, but no 1. should be pretty trivial to hack > up. No 2. will be slightly more difficult to do properly, though. I'll > take a swing at it once I get access to a Lisp system. Some one replied on the Google groups thread with this for Emacs, its pretty close to what I wanted. http://www.foldr.org/~michaelw/emacs/color-box.png Maybe I would reduce the shade difference from the inner most deeper shade from the lighter outer shade to a few. This would allow the few inner most nested s-expressions to not look out of the world. > > -- > \ Troels "Athas" > /\ Henriksen > From gimmal at gmail.com Wed Jul 19 16:37:27 2006 From: gimmal at gmail.com (Sean Champ) Date: Wed, 19 Jul 2006 09:37:27 -0700 Subject: [climacs-devel] finding esa:with-minibuffer-stream Message-ID: <200607190937.29118.gimmal@gmail.com> Hello, I was endeavoring to compile a fresh checkout of McCLIM, but I ran into an issue: ------- ; compiling (DEFUN DISPLAY-ARGLIST-TO-STREAM ...) compilation aborted because of fatal error: READ failure in COMPILE-FILE: READER-ERROR at 139635 (line 3494, column 31) on #: Symbol "WITH-MINIBUFFER-STREAM" not found in the ESA package. ------- On a 'grep' across the ESA sources, I've found no macro WITH-MINIBUFFER-STREAM, so it appears to not be a matter of it being in the source but not in the image. Google can find two references to it, but cannot seem to find a definition for the macro. So, might anyone happen to know where a macro ESA:WITH-MINIBUFFER-STREAM would happen to be defined? Thank you -- Sean Champ From gimmal at gmail.com Wed Jul 19 19:39:52 2006 From: gimmal at gmail.com (Sean Champ) Date: Wed, 19 Jul 2006 12:39:52 -0700 Subject: [climacs-devel] onto CVS, Re: finding esa:with-minibuffer-stream [rescinded] In-Reply-To: <200607190937.29118.gimmal@gmail.com> References: <200607190937.29118.gimmal@gmail.com> Message-ID: <200607191239.53674.gimmal@gmail.com> Having used google to find an 'esa' codebase, before reading the INSTALL file, I had ran a 'darcs get' from http://sigkill.dk/code/darcsrepos/esa/ In esa.lisp in that codebase, there was no with-minibuffer-stream defined I looked into the INSTALL file, then, and noticed that a CVS module was mentioned for 'esa'. In the source code from that module, with-minibuffer-stream is defined. The original question is rescinded. My CL session can find that macro's definition, now. -- Sean On Wednesday 19 July 2006 09:37 am, Sean Champ wrote: > Hello, > > I was endeavoring to compile a fresh checkout of McCLIM, but I ran into an > issue: > ------- > ; compiling (DEFUN DISPLAY-ARGLIST-TO-STREAM ...) > compilation aborted because of fatal error: > READ failure in COMPILE-FILE: > READER-ERROR at 139635 (line 3494, column 31) on # "file /usr/local/common-lisp/climacs/cvs-src/lisp-syntax.lisp" {D22F631}>: > Symbol "WITH-MINIBUFFER-STREAM" not found in the ESA package. > ------- > > On a 'grep' across the ESA sources, I've found no macro > WITH-MINIBUFFER-STREAM, so it appears to not be a matter of it being in the > source but not in the image. Google can find two references to it, but > cannot seem to find a definition for the macro. So, might anyone happen to > know where a macro ESA:WITH-MINIBUFFER-STREAM would happen to be defined? > > > Thank you > > > -- > Sean Champ > _______________________________________________ > climacs-devel mailing list > climacs-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/climacs-devel From gimmal at gmail.com Thu Jul 20 12:12:16 2006 From: gimmal at gmail.com (Sean Champ) Date: Thu, 20 Jul 2006 05:12:16 -0700 Subject: [climacs-devel] Encountering a bug after C-x C-f Message-ID: <200607200512.17254.gimmal@gmail.com> I've built climacs, using a recent checkout of the codebaess for all of the components to climacs. The build has been made on SBCL 0.9.11. I'm using telent CLX. There appears to occur a bug after I type the key sequence "C-x C-f" into the climacs window/pane. It appears to be a matter of a symbol being provided where a file-designator is expected. Along in the backtrace, the symbol occasioning the error is provided as the first and only argument to a list-format climacs command expression for CLIMACS-GUI::COM-FIND-FILE I am not familiar with the codebase, am uncertain of how to proceed about trying to resolve the bug. Following is the text of a backtrace from a SLIME session that had come to experience the bug. The backtrace is copied, up to the point of the execution of (climacs-gui::climacs), with the lines for all frames having been expanded. -- Sean The value #:UNSUPPLIED-ARGUMENT-MARKER3321 is not of type (OR (VECTOR CHARACTER) (VECTOR NIL) BASE-STRING PATHNAME FILE-STREAM). [Condition of type TYPE-ERROR] Restarts: 0: [RETURN-TO-ESA] ESA::RETURN-TO-ESA 1: [RESET-ESA] ESA::RESET-ESA 2: [ABORT-REQUEST] Abort handling SLIME request. 3: [TERMINATE-THREAD] Terminate this thread (#) Backtrace: 0: (PATHNAME-NAME #:UNSUPPLIED-ARGUMENT-MARKER3321) Locals: SB-DEBUG::ARG-0 = 1 SB-DEBUG::ARG-1 = #:UNSUPPLIED-ARGUMENT-MARKER3321 1: (CLIMACS-GUI::DIRECTORY-PATHNAME-P #:UNSUPPLIED-ARGUMENT-MARKER3321) Locals: CLIMACS-BASE:NAME = : CLIMACS-GUI::PATHSPEC = #:UNSUPPLIED-ARGUMENT-MARKER3321 TYPE = : Catch-tags: #:SB-DEBUG-CATCH-TAG 2: (CLIMACS-GUI::FIND-FILE #:UNSUPPLIED-ARGUMENT-MARKER3321 NIL) Locals: CLIMACS-BUFFER:BUFFER = : #:COUNT545 = : CLIMACS-PANE:FILEPATH = #:UNSUPPLIED-ARGUMENT-MARKER3321 #:G539 = : #:KEEPER-570 = : #:NEXT543 = : CLIM:PANE = : CLIMACS-GUI::READONLYP = NIL #:START544 = : STREAM = : Catch-tags: #:SB-DEBUG-CATCH-TAG 3: (CLIMACS-GUI::COM-FIND-FILE #:UNSUPPLIED-ARGUMENT-MARKER3321) Locals: CLIMACS-PANE:FILEPATH = #:UNSUPPLIED-ARGUMENT-MARKER3321 Catch-tags: #:SB-DEBUG-CATCH-TAG 4: ((SB-PCL::FAST-METHOD CLIM:EXECUTE-FRAME-COMMAND (CLIM:APPLICATION-FRAME T)) # # # (CLIMACS-GUI::COM-FIND-FILE #:UNSUPPLIED-ARGUMENT-MARKER3321)) Locals: CLIM:COMMAND = (CLIMACS-GUI::COM-FIND-FILE #:UNSUPPLIED-ARGUMENT-MARKER3321) CLIM-INTERNALS::FRAME = # Catch-tags: #:SB-DEBUG-CATCH-TAG 5: ((LAMBDA (SB-PCL::.PV-CELL. SB-PCL::.NEXT-METHOD-CALL. SB-PCL::.ARG0. SB-PCL::.ARG1.)) # # # (CLIMACS-GUI::COM-FIND-FILE #:UNSUPPLIED-ARGUMENT-MARKER3321)) Locals: SB-DEBUG::ARG-0 = : SB-DEBUG::ARG-1 = : SB-DEBUG::ARG-2 = # SB-DEBUG::ARG-3 = (CLIMACS-GUI::COM-FIND-FILE #:UNSUPPLIED-ARGUMENT-MARKER3321) 6: ((FLET CALL-NEXT-METHOD)) Locals: SB-PCL::.ARGS. = : SB-PCL::.CM-ARGS. = : SB-PCL::.FUNCTION. = : SB-PCL::.NEXT-METHOD-CALL. = : CLIM:COMMAND = : CLIMACS-GUI::FRAME = : #:G1040 = : SB-C::OBJECT = : Catch-tags: #:SB-DEBUG-CATCH-TAG 7: ((SB-PCL::FAST-METHOD CLIM:EXECUTE-FRAME-COMMAND :AROUND (CLIMACS-GUI:CLIMACS T)) # #S(SB-PCL::FAST-METHOD-CALL :FUNCTION # :PV-CELL NIL :NEXT-METHOD-CALL NIL :ARG-INFO (2)) # (CLIMACS-GUI::COM-FIND-FILE #:UNSUPPLIED-ARGUMENT-MARKER3321)) Locals: SB-PCL::.NEXT-METHOD-CALL. = #S(SB-PCL::FAST-METHOD-CALL :FUNCTION # :PV-CELL NIL :NEXT-METHOD-CALL NIL :ARG-INFO (2)) CLIMACS-BUFFER:BUFFER = : CLIM:COMMAND = (CLIMACS-GUI::COM-FIND-FILE #:UNSUPPLIED-ARGUMENT-MARKER3321) #:COUNT1061 = : CLIMACS-GUI:CURRENT-WINDOW = # CLIMACS-GUI::FRAME = # #:G1053 = # #:LOOP-LIST-1067 = : #:NEXT1059 = : #:START1060 = : Catch-tags: #:SB-DEBUG-CATCH-TAG 8: (ESA::PROCESS-GESTURES-OR-COMMAND # #) Locals: CLIM:COMMAND = (CLIMACS-GUI::COM-FIND-FILE #:UNSUPPLIED-ARGUMENT-MARKER3321) CLIM:COMMAND#1 = : CLIM:COMMAND-TABLE = # ESA::FRAME = # #:G217 = : #:G224 = : ESA::GESTURES = (# #) ESA::ITEM = # ESA::NUMARG = : ESA::NUMARGP = : SB-C::OBJECT = : ESA::OBJECT#1 = : ESA::OBJECT#2 = : Catch-tags: #:SB-DEBUG-CATCH-TAG #:SB-DEBUG-CATCH-TAG 9: (ESA:ESA-TOP-LEVEL # :COMMAND-PARSER # :COMMAND-UNPARSER # :PARTIAL-COMMAND-PARSER # :PROMPT #) Locals: CLIM:COMMAND-TABLE = # ESA::FRAME = # #:G378 = NIL Catch-tags: #:SB-DEBUG-CATCH-TAG 10: ((LAMBDA (#:FRAME-ARG70)) #) Locals: #:FRAME-ARG70 = # Catch-tags: #:SB-DEBUG-CATCH-TAG 11: ((SB-PCL::FAST-METHOD CLIM:RUN-FRAME-TOP-LEVEL (CLIM:APPLICATION-FRAME)) # # # #) Locals: #:COUNT986 = : CLIM-INTERNALS::FRAME = # #:G978 = : #:G980 = : #:NEXT984 = : #:START985 = : Catch-tags: #:SB-DEBUG-CATCH-TAG 12: ((FLET CALL-NEXT-METHOD)) Locals: SB-PCL::.ARGS. = : SB-PCL::.CM-ARGS. = : SB-PCL::.FUNCTION. = : SB-PCL::.NEXT-METHOD-CALL. = : SB-PCL::.REST-ARG. = : CLIM-INTERNALS::FRAME = : #:G1039 = : SB-C::OBJECT = : Catch-tags: #:SB-DEBUG-CATCH-TAG 13: ((SB-PCL::FAST-METHOD CLIM:RUN-FRAME-TOP-LEVEL :AROUND (CLIM:APPLICATION-FRAME)) # #S(SB-PCL::FAST-METHOD-CALL :FUNCTION # :PV-CELL NIL :NEXT-METHOD-CALL NIL :ARG-INFO (1 . T)) # NIL) Locals: SB-PCL::.NEXT-METHOD-CALL. = #S(SB-PCL::FAST-METHOD-CALL :FUNCTION # :PV-CELL NIL :NEXT-METHOD-CALL NIL :ARG-INFO (1 . T)) SB-PCL::.REST-ARG. = NIL #:COUNT1051 = : #:COUNT1067 = : CLIM-INTERNALS::FRAME = # #:G1044 = : #:NEXT1049 = : #:NEXT1065 = : #:OLD-STREAM1061 = NIL CLIM-INTERNALS::ORIGINAL-STATE = :DISOWNED CLIM-INTERNALS::QUERY-IO = # #:START1050 = : #:START1066 = : Catch-tags: #:SB-DEBUG-CATCH-TAG 14: ((FLET CLIMACS::RUN)) Locals: CLIMACS::FRAME = : Catch-tags: #:SB-DEBUG-CATCH-TAG 15: (CLIMACS-GUI:CLIMACS :NEW-PROCESS NIL :PROCESS-NAME "Climacs" :WIDTH 900 :HEIGHT 400) Locals: CLIMACS::FRAME = # #:HEIGHT-DEFAULTING-TEMP = 400 #:NEW-PROCESS-DEFAULTING-TEMP = NIL #:PROCESS-NAME-DEFAULTING-TEMP = "Climacs" #:WIDTH-DEFAULTING-TEMP = 900 Catch-tags: #:SB-DEBUG-CATCH-TAG From csr21 at cam.ac.uk Thu Jul 20 12:52:49 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Thu, 20 Jul 2006 13:52:49 +0100 Subject: [climacs-devel] Encountering a bug after C-x C-f In-Reply-To: <200607200512.17254.gimmal@gmail.com> (Sean Champ's message of "Thu, 20 Jul 2006 05:12:16 -0700") References: <200607200512.17254.gimmal@gmail.com> Message-ID: Sean Champ writes: > I am not familiar with the codebase, am uncertain of how to proceed about > trying to resolve the bug. It seems likely to me that you are using inconsistent sources. Have you checked out CVS HEAD of both ESA and Climacs? If not, try that combination. Cheers, Christophe From athas at sigkill.dk Fri Jul 21 06:11:03 2006 From: athas at sigkill.dk (Troels Henriksen) Date: Fri, 21 Jul 2006 08:11:03 +0200 Subject: [climacs-devel] onto CVS, Re: finding esa:with-minibuffer-stream [rescinded] In-Reply-To: <200607191239.53674.gimmal@gmail.com> (Sean Champ's message of "Wed, 19 Jul 2006 12:39:52 -0700") References: <200607190937.29118.gimmal@gmail.com> <200607191239.53674.gimmal@gmail.com> Message-ID: <87d5bztrm0.fsf@sigkill.dk> Sean Champ writes: > I had ran a 'darcs get' from > http://sigkill.dk/code/darcsrepos/esa/ I know you have solved your problem, but I just want to comment on that repo for anyone finding this thread via a search engine - that Darcs repository is old and outdated, and was used by me before the ESA module was added to Climacs' CVS repository. It should not be used for anything. -- \ Troels "Athas" /\ Henriksen From gimmal at gmail.com Fri Jul 21 20:44:35 2006 From: gimmal at gmail.com (Sean Champ) Date: Fri, 21 Jul 2006 13:44:35 -0700 Subject: [climacs-devel] Encountering a bug after C-x C-f In-Reply-To: References: <200607200512.17254.gimmal@gmail.com> Message-ID: <200607211344.37588.gimmal@gmail.com> On Thursday 20 July 2006 05:52 am, Christophe Rhodes wrote: > > It seems likely to me that you are using inconsistent sources. Have > you checked out CVS HEAD of both ESA and Climacs? If not, try that > combination. The build in which I'd encountered the issue had been made with most-recent checkouts from the HEAD for each of McCLIM, ESA, Climacs, and felxichain. I had built Climacs before updating my local copy of ESA. After checking-out the CVS head, then I restarted the image, and had ASDF build Climas with the new ESA Though I had not watched the compilation process, but I am sure that ASDF would have ensured that Climacs was fully rebuilt, then, on top of the new ESA codebase. Looking at climacs.asd, it looks like there should be nothing that wasn't rebuilt on the new ESA. I'll have to clear-off my desktop, dig into a session of walking back along how it happend. --- I suppose that this would belong in a different thread of mesages, but it is related, on that I will certainly be getting familiar with the McCLIM codebase, while trying to find out how that issue came to be. The matter, I mean: Upon noticing that CONS typed values are used in part to a represent of Climacs minibuffer commands, and while I am not bothered at that, whatsoever -- a specially formatted CONS works, as a data structure -- I hope to propose: The possibility that funcallable instances might be considered, as for how such might be applicable for the representation and execution of CLIM commands. (I know, it's an abject suggestion, there. After I'll be more familiar with the codebase, I might be able to determine, to more certainty, if and how it may be feasible.) Like, maybe in something of an analogue to the Emacs #'interactive function: Given anything (e.g. a CLIM gadget? - and I am not yet much familiar with CLIM - or the minibuffer) any interface objects that would be used for 'reading' input (i.e. parameter, argument) values to a minibuffer command , some objects for the facilitation of such might be referenced from within an interactive-command object. (I'm not yet enough familiar with CLIM, either, as to make an example, there, but it seems that it could be posisble.) (Maybe it could be actuated on command-function argument types, the means whereby an input value would be read for a CLIM command, or a means whereby a defaulted, input interface would be selected. e.g. if the parameter would have to be of type PATHNAME, then a file-selection dialogue could be presented. To implement this, it might involve some implementation-specific code, e.g. using the CMUCL/SBCL CTYPE mechanism) Continuing with this proposal: Once the input interface (?) would be referenced in an interactive-command object, then, There could be defined a mechanism in climacs, as for how the input interface would be activated on an interactive-command object, and how, parameters extracted from that interface, as upon the execution of the actual 'command function'. (I would like to reiterate, I'm not sure of how the proposal would be worked, in the code. I hope that I will have managed to have become more sure about it, as after I'll be more familiar with the McCLIM and Climacs codebases. I consider that it could be worth it, to have brought the matter to suggestion, firstly.) I'd be glad to hear of any responses on the proposals, above. Thank you, -- Sean From athas at sigkill.dk Fri Jul 21 21:41:15 2006 From: athas at sigkill.dk (Troels Henriksen) Date: Fri, 21 Jul 2006 23:41:15 +0200 Subject: [climacs-devel] Encountering a bug after C-x C-f In-Reply-To: <200607211344.37588.gimmal@gmail.com> (Sean Champ's message of "Fri, 21 Jul 2006 13:44:35 -0700") References: <200607200512.17254.gimmal@gmail.com> <200607211344.37588.gimmal@gmail.com> Message-ID: <87u05a1vr8.fsf@sigkill.dk> Sean Champ writes: > The build in which I'd encountered the issue had been made with most-recent > checkouts from the HEAD for each of McCLIM, ESA, Climacs, and felxichain. The problem is definitely an old version of ESA being loaded - doublecheck your asds and remove your old fasls, also check the value of asdf:*central-registry* to make sure that you are loading what you think you are loading. Remove all traces of previous ESAs and make sure that your climacs.asd is not outdated (ESA was once completely integrated with the Climacs system, if you haven't done clean CVS checkouts there might be some residue left). Also, because I screwed up when originally creating the ESA module in the Climacs repo, you should get "start" instead of "HEAD" (I don't know exactly when this applies, my CVS-fu is weak). > I suppose that this would belong in a different thread of mesages, but it is > related, on that I will certainly be getting familiar with the McCLIM > codebase, while trying to find out how that issue came to be. IIRC, McCLIM is not what handles unsupplied arguments to commands - ESA is. Reading the McCLIM source is still a good idea, of course! > The matter, I mean: Upon noticing that CONS typed values are used in part to a > represent of Climacs minibuffer commands, and while I am not bothered at > that, whatsoever -- a specially formatted CONS works, as a data structure -- > I hope to propose: The possibility that funcallable instances might be > considered, as for how such might be applicable for the representation and > execution of CLIM commands. Climacs uses CLIM, and the CLIM specification defines a command as a cons of a symbol bound to the command function, and a list of operands to the command. It's very intuitive, really. If you want such a command to be funcallable, just do (apply (first command) (rest command)). Or use the CLIM function `execute-frame-command'. > (Maybe it could be actuated on command-function argument types, the means > whereby an input value would be read for a CLIM command, or a means whereby a > defaulted, input interface would be selected. e.g. if the parameter would > have to be of type PATHNAME, then a file-selection dialogue could be > presented. To implement this, it might involve some implementation-specific > code, e.g. using the CMUCL/SBCL CTYPE mechanism) You are talking about prompting for command parameters, right? CLIM already supports this - you can define "accept" methods for presentation types, specialized on "views", so you can have, say, a traditional text-based file selection facility, or a fancy, graphical file selector. I'm not sure the Emacs application paradigm is well-suited to this kind of gadgets, though. If you wish to attempt to implement such a file selector, you would be very welcome, though! > (I would like to reiterate, I'm not sure of how the proposal would be worked, > in the code. I hope that I will have managed to have become more sure about > it, as after I'll be more familiar with the McCLIM and Climacs codebases. I > consider that it could be worth it, to have brought the matter to suggestion, > firstly.) I think CLIM already provides hooks for (or directly implements) what you want - it's merely a matter of fleshing out the implementation. A weakness of Climacs in particular is that only a single line is available for entering input values for command arguments, but this could change, of course. -- \ Troels "Athas" /\ Henriksen From gimmal at gmail.com Sun Jul 23 02:26:16 2006 From: gimmal at gmail.com (Sean Champ) Date: Sat, 22 Jul 2006 19:26:16 -0700 Subject: [climacs-devel] Encountering a bug after C-x C-f In-Reply-To: <87u05a1vr8.fsf@sigkill.dk> References: <200607200512.17254.gimmal@gmail.com> <200607211344.37588.gimmal@gmail.com> <87u05a1vr8.fsf@sigkill.dk> Message-ID: <200607221926.17686.gimmal@gmail.com> On Friday 21 July 2006 02:41 pm, Troels Henriksen wrote: > Sean Champ writes: > > The build in which I'd encountered the issue had been made with > > most-recent checkouts from the HEAD for each of McCLIM, ESA, Climacs, and > > felxichain. > The problem is definitely an old version of ESA being loaded Indeed. I would like to aplogize for that it was made as an issue to the list. You know, if I had read, firstly the INSTALL file, rather than relying on Google to find the source repository, then I should have fetched the correct batch of sources, originally. N.B, if the 'start' module is what should be checked-out on ESA, then perhaps that may be mentioned in the INSTALL file. > > > (Maybe it could be actuated on command-function argument types, the means > > whereby an input value would be read for a CLIM command, or a means > > whereby a defaulted, input interface would be selected. e.g. if the > > parameter would have to be of type PATHNAME, then a file-selection > > dialogue could be presented. To implement this, it might involve some > > implementation-specific code, e.g. using the CMUCL/SBCL CTYPE mechanism) > > You are talking about prompting for command parameters, right? CLIM > already supports this - you can define "accept" methods for > presentation types, specialized on "views", so you can have, say, a > traditional text-based file selection facility, or a fancy, graphical > file selector. Thank you. I should be glad to have known so, when endeavoring to learn of the CLIM standard. -- Sean From gimmal at gmail.com Sun Jul 23 02:42:27 2006 From: gimmal at gmail.com (Sean Champ) Date: Sat, 22 Jul 2006 19:42:27 -0700 Subject: [climacs-devel] Any tips on making the Climacs GUI more responsive? Message-ID: <200607221942.28625.gimmal@gmail.com> I am aware that this would be a matter, firstly, of the processor on the computer I am using. I consider that there is still grounds for that this may be addressed as an issue to attention, as in interest of Climacs development. I am glad to have been able to have launched the Climacs GUI. It looks very nice. I am wondering, however, if it will be possible to do aything in particular, as to ensure that the GUI might be more responsive. In comparison of GUI responosiveness, XEmacs is fairly prompt, in response, even on this 366 MHz box. Comparatively, the Climacs GUI -- as it was activated, on the code and libraries, here[1] -- the GUI not quite as responsve as I would want that a text editor will be. In what I mean by it not being responsive: 1) text typed into the scratch buffer does not appear quite as readily as I mght hope 2) on refresh/redraw, the GUI is not rendered as quickly as I would hope. While I mean no affront on this, but to address the matter in attempte at accuracy: I am not certain if it may be a matter contingent as on CLIM and the CLIM implementation. (Considering: At the stuff about coordinate-system adjustment in CLIM, and while I know that is but one part to the CLIM standard, and I do not know how crucial that it is to the rendering of the Climacs GUI, but I wonder if it might, in however, serve as to occasion any lag of the visual interface.) (I am certain that it is not the CLX-X interface. Though what code that I had made for the prototypes has suffered from some bit-rot, but in all prior sessions, Garnet applications have been farily responsive, here) I am sure that I could re-compile CLIM and the companion source-code to Climacs, recompiling it as under a less intensive debug policy, but I am not aware about how much strength of debugging I would have lost, then. Regardless, I hope to have addressed my concern on this, without leaving it blindly aside. I realize, this might ocasion more involvement directly about CLIM. I hope to have addressed my concern about it, firstly, to whom would be more aware of the system than I may be. Thank you --- Sean [1] I'm using a recent build of X.org from debian/sid, and the recent Common Lisp sources for the components to CLIM, running in SBCL 0.9.11 From athas at sigkill.dk Sun Jul 23 09:05:52 2006 From: athas at sigkill.dk (Troels Henriksen) Date: Sun, 23 Jul 2006 11:05:52 +0200 Subject: [climacs-devel] Any tips on making the Climacs GUI more responsive? In-Reply-To: <200607221942.28625.gimmal@gmail.com> (Sean Champ's message of "Sat, 22 Jul 2006 19:42:27 -0700") References: <200607221942.28625.gimmal@gmail.com> Message-ID: <87ac70k7wv.fsf@sigkill.dk> Sean Champ writes: > From: Sean Champ > > I am wondering, however, if it will be possible to do aything in particular, > as to ensure that the GUI might be more responsive. Unfortunately not, there is no "magic solution" - as far as I know, the problem lies in the Climacs redisplay routines, that are basically just too slow (I don't think the problem lies with McCLIM - Goatee, for example, has fast redraw). You can try recompiling Climacs with other optimization settings, but that's not guaranteed to have much of an effect. The only real solution to this problem is to rewrite the redisplay routines and make them faster, but I don't how exactly how this should be done - I'll admit that I don't even know why redisplay is so slow. However - do note that some syntaxes (AFAIK every syntax but Basic and Lisp) are inherently slow due to the implementation of the algorithm they use to parse their buffer contents. They are not indicative of the speed of Climacs as a whole. -- \ Troels "Athas" /\ Henriksen From amoroso at mclink.it Sun Jul 23 15:39:57 2006 From: amoroso at mclink.it (Paolo Amoroso) Date: Sun, 23 Jul 2006 08:39:57 -0700 Subject: [climacs-devel] Any tips on making the Climacs GUI more responsive? Message-ID: <200607230839.58499.amoroso@mclink.it> Sean Champ writes: > While I mean no affront on this, but to address the matter in attempte at > accuracy: I am not certain if it may be a matter contingent as on CLIM and > the CLIM implementation. (Considering: At the stuff about coordinate-system > adjustment in CLIM, and while I know that is but one part to the CLIM > standard, and I do not know how crucial that it is to the rendering of the > Climacs GUI, but I wonder if it might, in however, serve as to occasion any > lag of the visual interface.) Within the past few months there has been a McCLIM performance regression: drawing a very large class graph with the CLIM Listener takes about 15X longer than it used to. With guidance from Christophe Rhodes I did some benchmarking and tried to locate the possible cause, but I didn't get any useful results. I don't know whether your Climacs responsiveness problems are related to this. > [1] I'm using a recent build of X.org from debian/sid, and the recent > Common Lisp sources for the components to CLIM, running in SBCL 0.9.11 You might try using CMUCL instead. A few years ago CMUCL produced code twice as fast as SBCL's. SBCL has been greatly improved since then, but on your slow machine using CMUCL might still make a difference. Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log From csr21 at cam.ac.uk Sun Jul 23 20:48:07 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Sun, 23 Jul 2006 21:48:07 +0100 Subject: [climacs-devel] Any tips on making the Climacs GUI more responsive? In-Reply-To: <200607230839.58499.amoroso@mclink.it> (Paolo Amoroso's message of "Sun, 23 Jul 2006 08:39:57 -0700") References: <200607230839.58499.amoroso@mclink.it> Message-ID: Paolo Amoroso writes: > Sean Champ writes: >> While I mean no affront on this, but to address the matter in attempte at >> accuracy: I am not certain if it may be a matter contingent as on CLIM and >> the CLIM implementation. (Considering: At the stuff about coordinate-system >> adjustment in CLIM, and while I know that is but one part to the CLIM >> standard, and I do not know how crucial that it is to the rendering of the >> Climacs GUI, but I wonder if it might, in however, serve as to occasion any >> lag of the visual interface.) > > Within the past few months there has been a McCLIM performance > regression: drawing a very large class graph with the CLIM Listener > takes about 15X longer than it used to. With guidance from Christophe > Rhodes I did some benchmarking and tried to locate the possible cause, > but I didn't get any useful results. I thought we established that this was because McCLIM now creates output records for arcs, to support repositioning nodes and having the arcs in a graph redraw themselves (as in the graph drag and drop demo)? > I don't know whether your Climacs responsiveness problems are related > to this. I doubt it. One factor that does matter, at least to first startup, is the fact that generic functions are generated (when a defgeneric or defmethod is loaded from a fasl file) in a pristine state, with no information about any effective methods, which are generated on demand. Since McCLIM is extremely CLOS-heavy (using generic functions in all layers of the various protocols), at application startup many, many generic functions are run for the first time, at which point lots of caches are generated, activated and filled. To see this effect, measure the time to start climacs up from a clean load, close it, and start climacs again. >> [1] I'm using a recent build of X.org from debian/sid, and the recent >> Common Lisp sources for the components to CLIM, running in SBCL 0.9.11 > > You might try using CMUCL instead. A few years ago CMUCL produced > code twice as fast as SBCL's. SBCL has been greatly improved since > then, but on your slow machine using CMUCL might still make a > difference. For what it's worth, I consider this unlikely. Cheers, Christophe From athas at sigkill.dk Mon Jul 24 18:50:16 2006 From: athas at sigkill.dk (Troels Henriksen) Date: Mon, 24 Jul 2006 20:50:16 +0200 Subject: [climacs-devel] Climacs Progress Report, July 2006 Message-ID: <878xmisuqf.fsf@sigkill.dk> Dear list members, Welcome to another installment of an exciting Climacs progress report? In the three months since the last progress report was posted, a lot of work has been done on Climacs - many bugs have been fixed, a lot of refactoring has been performed and a large amount of features, even some pretty major ones, have been added. Some notable changes are: * Highlighting of operators in Lisp syntax based on whether they are special operators or macros, instead of just having a list of symbols that should be highlighted (as Emacs does). * A generic on-line help/documentation facility has been added to ESA and integrated with Climacs - we now have basic documentation commands like GNU Emacs (C-h f, C-h k, etc). * Backup files are now version numbered. * A Visible Region command has been added. * Keyboard macros now support numeric arguments. * A new command parser has been developed for ESA, with the result that unsupplied arguments are now supported (through *unsupplied-argument-marker*), making it possible to define commands that take arguments (as opposed to just calling `accept' in the body) and still have them be invokable through gestures. * A host of new search/replace commands: Multiple Query Replace, Query Exchange, Multiple Query Replace From Buffer, String Search, Reverse String Search, Word Search and Reverse Word Search. * Incremental search has been improved, making it more comparable to the one in GNU Emacs. * The Lisp syntax has been drastically improved, it can now indent many more forms than it used to, and it has SLIME-like handling of in (in-package) forms. Of course, the major addition is probably the merging of Swine (from CLIM-Desktop) with the Lisp-syntax - Climacs, by itself, is now a reasonable tool for hacking Common Lisp code. The Swine-parts have also been improved since the merge, and has very intelligent parameter hinting and intelligent completion of keywords for keyword arguments (ie., when you symbol-complete at a point where only a keyword symbol would make sense, the possible completions will be chosen from among the relevant keyword arguments.). * There has been a lot of refactoring, for example implementation of Taylor Campbell's proposal for a uniform motion/editing function signature. Motion and editing commands can now be found in the files motion.lisp and editing.lisp, where the bulk of the functions are autogenerated (by macros) from basic building blocks. Also, almost all commands have been moved to a new CLIMACS-COMMANDS package, where they are implemented utilizing functionality exported by other packages. Syntaxaware-yet-not-GUI-oriented functions have been moved to the new CLIMACS-CORE package, and the CLIMACS-BASE package has had a fairly large amount of functions moved to other packages. * The main entry point(s) have been moved to a new CLIMACS package, so Climacs can now be invoked by running (climacs:climacs) instead of (climacs-gui:climacs). This is for consistency with other CLIM applications (notably Beirc and Gsharp). The GUI code itself still lives in CLIMACS-GUI. * Documentation has been added to the user guide (Doc/climacs-user.texi) for the new help and search/replace commands. Personally, I (Troels Henriksen) was not aware of this user guide until just recently, and thus had not updated it with my own work. If you add, or change, new commands, please consider adding them to this user guide - while it is unlikely that anyone actually uses Climacs, and need this guide, I think it is easier to keep it reasonably updated at all times, than to rewrite a lot of it from scratch at some point in the future. * I also hadn't paid much notice to the test suites - I'm probably the only one who has broken these tests, but if you are mucking around with the stuff tested by these suites, please run them before committing. :) They have recently been updated to work with the major changes to Climacs. Also, there has been a large amount of bugfixes and additions of minor functionality. Climacs' design is now reasonably clean, with clear boundaries between the various subsystems, which should make it easier for newcomers to understand the code and make contributions. There is no overarching plan that defines what will happen to Climacs next, but personally, I have been looking at implementing a "group" facility (like the one in Hemlock, but with more features) and improving the non-Lisp syntaxes, almost all of which need drastic improvements (speed-wise as well as functionality-wise). As always, integration with other CLIM applications is an interesting idea, but work like this is probably more suited for projects like CLIM-Desktop than Climacs proper. Climacs is still alive, and it is still a promising project. -- \ Troels "Athas" /\ Henriksen