From csr21 at cam.ac.uk Mon Mar 13 13:01:25 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Mon, 13 Mar 2006 13:01:25 +0000 Subject: [climacs-devel] unicode-commands.lisp Message-ID: Hi, Is anyone using the commands in unicode-commands.lisp? If so, under which backend? (It seems impossible to me that they could work under the CLX McCLIM backend, because -- at least for me -- the dead acude keysym is :DEAD-ACUTE (and not :DEAD--ACUTE). Cheers, Christophe From dtc at scieneer.com Tue Mar 14 04:48:40 2006 From: dtc at scieneer.com (Douglas Crosher) Date: Tue, 14 Mar 2006 15:48:40 +1100 Subject: [climacs-devel] Patch: Support for the Scieneer CL implementation. Message-ID: <44164B28.8060502@scieneer.com> * file-commands.lisp: Support for the Scieneer CL implementation. Regards Douglas Crosher -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch-climacs-scl URL: From dtc at scieneer.com Tue Mar 14 04:49:11 2006 From: dtc at scieneer.com (Douglas Crosher) Date: Tue, 14 Mar 2006 15:49:11 +1100 Subject: [climacs-devel] Patch: flip-undo-record slot access ordering. Message-ID: <44164B47.8090507@scieneer.com> * flip-undo-record (insert-record), flip-undo-record (delete-record): reorder the 'slot-value access so that the 'slot-value is not accessed after the object class has changed and the slot is missing. Regards Douglas Crosher -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch-climacs URL: From athas at sigkill.dk Tue Mar 14 14:27:49 2006 From: athas at sigkill.dk (Troels Henriksen) Date: Tue, 14 Mar 2006 15:27:49 +0100 Subject: [climacs-devel] Decoupling ESA from Climacs/Gsharp Message-ID: <871wx514pm.fsf@sigkill.dk> Pretty much everyone believes ESA needs to be turned into a project of itself, partly because it is painful to maintain it in two different repos at the same time, partly because other applications might want to use it. Well, I found that it was actually a completely painless process to perform the separation, so I now have ESA in a Darcs repo: http://sigkill.dk/code/darcsrepos/esa/ It is a drop-in replacement for ESA in Climacs and Gsharp, all it requires is modification of the .asd's. I'm not an ESA maintainer, nor am I very familiar with the code base, so I do not feel I should take it much further than here, but I do believe that the creation of a separate common-lisp.net-based ESA project is a must. -- \ Troels "Athas" Henriksen /\ - Insert witty signature From athas at sigkill.dk Tue Mar 14 14:49:27 2006 From: athas at sigkill.dk (Troels Henriksen) Date: Tue, 14 Mar 2006 15:49:27 +0100 Subject: [climacs-devel] Decoupling ESA from Climacs/Gsharp In-Reply-To: (Christophe Rhodes's message of "Tue, 14 Mar 2006 14:41:15 +0000") References: <871wx514pm.fsf@sigkill.dk> Message-ID: <87wtexytc8.fsf@sigkill.dk> Christophe Rhodes writes: > Does it really need its own project? Can't it live in one or other of > its client repositories for now? Sure, that could work, but which one? I would recommend Climacs, if only because it is probably the application with the closest association with the Emacs metaphor. -- \ Troels "Athas" Henriksen /\ - Insert witty signature From csr21 at cam.ac.uk Tue Mar 14 14:41:15 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Tue, 14 Mar 2006 14:41:15 +0000 Subject: [climacs-devel] Decoupling ESA from Climacs/Gsharp In-Reply-To: <871wx514pm.fsf@sigkill.dk> (Troels Henriksen's message of "Tue, 14 Mar 2006 15:27:49 +0100") References: <871wx514pm.fsf@sigkill.dk> Message-ID: Troels Henriksen writes: > I'm not an ESA maintainer, nor am I very familiar with the code base, > so I do not feel I should take it much further than here, but I do > believe that the creation of a separate common-lisp.net-based ESA > project is a must. Does it really need its own project? Can't it live in one or other of its client repositories for now? Cheers, Christophe From csr21 at cam.ac.uk Tue Mar 14 14:51:57 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Tue, 14 Mar 2006 14:51:57 +0000 Subject: [climacs-devel] unicode-commands Message-ID: Hi, I've just merged changes to unicode-commands which make them work for me, at least partly (there are the usual troubles involving shifted modifiers). Screenshot at ; you might need a bleeding-edge CLX, depending on whether you use dead-modifiers to input latin1 characters or not, and also whether your keyboard layout is similar enough to Robert's. Cheers, Christophe From dtc at scieneer.com Tue Mar 14 03:11:51 2006 From: dtc at scieneer.com (Douglas Crosher) Date: Tue, 14 Mar 2006 14:11:51 +1100 Subject: [climacs-devel] Patch: flip-undo-record slot access ordering. Message-ID: <44163477.60706@scieneer.com> * flip-undo-record (insert-record), flip-undo-record (delete-record): reorder the 'slot-value access so that the 'slot-value is not accessed after the object class has changed and the slot is missing. Regards Douglas Crosher -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch-climacs URL: From strandh at labri.fr Tue Mar 14 16:59:43 2006 From: strandh at labri.fr (Robert Strandh) Date: Tue, 14 Mar 2006 17:59:43 +0100 Subject: [climacs-devel] Decoupling ESA from Climacs/Gsharp In-Reply-To: <871wx514pm.fsf@sigkill.dk> References: <871wx514pm.fsf@sigkill.dk> Message-ID: <17430.63103.294798.19486@serveur5.labri.fr> Troels Henriksen writes: > I'm not an ESA maintainer, nor am I very familiar with the code base, > so I do not feel I should take it much further than here, but I do > believe that the creation of a separate common-lisp.net-based ESA > project is a must. I agree. -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. --------------------------------------------------------------------- From athas at sigkill.dk Tue Mar 14 20:23:57 2006 From: athas at sigkill.dk (Troels Henriksen) Date: Tue, 14 Mar 2006 21:23:57 +0100 Subject: [climacs-devel] Implementation proposal for a Describe Binding command. Message-ID: <87lkvczsf6.fsf@sigkill.dk> ESA has a builtin `describe-key-briefly'-command, but, as the name implies, this only gives a very brief description of the keybinding (and it doesn't work for syntax-specific bindings either). I have written a complementary command inspired by Emacs' `describe-key' (C-h k): (in-package :climacs-gui) (define-command (com-describe-binding :name t :command-table help-table) () "Display documentation for the command invoked by a giving gesture sequence. When invoked, this command will wait for user input. If the user inputs a gesture sequence bound to a command available in the syntax of the current buffer, documentation and other details will be displayed. Otherwise, Climacs will silently wait, and the user will have to press an abort gesture to get out of the gesture reading loop." (let ((command-table (esa:find-applicable-command-table *application-frame*))) (multiple-value-bind (command gestures) (esa::read-gestures-for-help command-table) (let* ((gesture-name (format nil "~{~A~#[~; ~; ~]~}" (mapcar #'esa::gesture-name gestures))) (stream (typeout-window (format nil "~10THelp: Describe binding for ~A" gesture-name))) (command-name (or (command-line-name-for-command (first command) command-table :errorp nil) (first command)))) (princ "The gesture " stream) (with-text-face (stream :italic) (princ gesture-name stream)) (format stream " is bound to the ~:[command~;function~] " (symbolp command-name)) (with-text-face (stream :italic) (princ command-name stream)) (format stream " in ~A.~%" (command-table-name command-table)) (terpri stream) (format stream "~:[Not documented.~;~:*~A~]" (documentation command 'function)))))) (set-key 'com-describe-binding 'help-table '((#\h :control) (#\k))) This command understands syntax-specific keybindings and displays documentation for the given command as well (this is the reason for the rather verbose docstring, I had to test the command on something). I use two internal ESA symbols, though, `esa::read-gestures-for-help' and `esa::gesture-name' - why are these internal? They seem like functions that would be useful for most ESA-derived applications, their interface is simple and they do not expose any internal ESA details AFAICS. This command will only work in Climacs due to the use of a typeout pane, but I think it should somehow be ported to pure ESA, as it is, in my opinion, a necessary part of any Emacs-like application. Finally, if this command is added to Climacs, we'll have new incentive to add docstrings to the public commands. :-) -- \ Troels "Athas" Henriksen /\ - Insert witty signature From athas at sigkill.dk Fri Mar 17 14:16:31 2006 From: athas at sigkill.dk (Troels Henriksen) Date: Fri, 17 Mar 2006 15:16:31 +0100 Subject: [climacs-devel] Decoupling ESA from Climacs/Gsharp In-Reply-To: <17430.63103.294798.19486@serveur5.labri.fr> (Robert Strandh's message of "Tue, 14 Mar 2006 17:59:43 +0100") References: <871wx514pm.fsf@sigkill.dk> <17430.63103.294798.19486@serveur5.labri.fr> Message-ID: <87zmjpma0w.fsf@sigkill.dk> Robert Strandh writes: > I agree. Well, as Christophe Rodes wrote, it might be easier to host it as a module in the Climacs CVS repo for now. As a committer, am I able to create modules? And how (I'm not very experienced with creating and managing CVS modules)? -- \ Troels "Athas" Henriksen /\ - Insert witty signature From strandh at labri.fr Sat Mar 18 17:49:40 2006 From: strandh at labri.fr (Robert Strandh) Date: Sat, 18 Mar 2006 18:49:40 +0100 Subject: [climacs-devel] Decoupling ESA from Climacs/Gsharp In-Reply-To: <87zmjpma0w.fsf@sigkill.dk> References: <871wx514pm.fsf@sigkill.dk> <17430.63103.294798.19486@serveur5.labri.fr> <87zmjpma0w.fsf@sigkill.dk> Message-ID: <17436.18484.452877.5149@serveur5.labri.fr> Troels Henriksen writes: > > As a committer, am I able to > create modules? And how (I'm not very experienced with creating and > managing CVS modules)? Nor am I, so I don't know the answer to the question. If not, I am sure that can be arranged. -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. --------------------------------------------------------------------- From csr21 at cam.ac.uk Fri Mar 24 14:27:24 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Fri, 24 Mar 2006 14:27:24 +0000 Subject: [climacs-devel] execute-frame-command Message-ID: Hi, The CLIM spec allows execute-frame-command to be called on a frame from threads not associated with that frame, apparently to implement cross-application scripting or something along those lines: for instance, a file manager could send a user's request to edit a file to an already-running text editor. This means that execute-frame-command methods should not use special variables such as *application-frame* and *standard-output*, as they could be executed in the wrong thread: and indeed execute-frame-command should not assume that anything has been executed. I think ESA and Climacs get the latter right but not the former; with the following patch, I am able to do things like (sb-thread:make-thread (lambda () (climacs-gui::climacs))) (defvar *foo*) (sb-thread:interrupt-thread * (lambda () (setf *foo* *application-frame*))) (clim:execute-frame-command *foo* `(climacs-gui::com-insert-parentheses 0 nil)) and watch the parens be inserted into the *scratch* buffer. (Warning: I haven't in fact done precisely this -- I have instead been running climacs under the new mcclim "Null" backend and inspecting the data structures themselves). -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: efc.diff URL: -------------- next part -------------- I'm not able to do really interesting things with this yet, because many of the gsharp or esa commands don't take arguments but instead prompt (accept) explicitly. Why was it done this way? My hypothesis is that it's done this way so that we don't overrun the minibuffer: hitting RET doesn't cause some accepting-values dialog to pop up or similar. I mentioned this on IRC to Tim Moore, and he mumbled something about *partial-command-parser*: I think his idea is that we should bind that (and possibly also *command-parser*) to get the minibuffer behaviour we want, and then the commands' arglists should reflect all the information needed from the user. Does that make any sense? Cheers, Christophe PS: My kingdom for only one copy of ESA... From athas at sigkill.dk Sat Mar 25 16:30:48 2006 From: athas at sigkill.dk (Troels Henriksen) Date: Sat, 25 Mar 2006 17:30:48 +0100 Subject: [climacs-devel] External ESA for Climacs Message-ID: <87k6aio5af.fsf@sigkill.dk> As you may have noticed, I have created a module for ESA in the Climacs CVS repository and committed some code. It is a merge of the Climacs and Gsharp ESAs, and, according to my tests, run both programs properly. Attached to this post is a patch that will hopefully make Climacs use an external ESA (the patch is very simple, just remove the ESA bits from climacs.asd and packages.lisp and add a dependency on :esa in the system definition). -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: climacs-external-esa.diff URL: -------------- next part -------------- -- \ Troels "Athas" Henriksen /\ - Insert witty signature From csr21 at cam.ac.uk Sat Mar 25 21:08:19 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Sat, 25 Mar 2006 21:08:19 +0000 Subject: [climacs-devel] execute-frame-command In-Reply-To: (Christophe Rhodes's message of "Fri, 24 Mar 2006 14:27:24 +0000") References: Message-ID: Christophe Rhodes writes: > executed. I think ESA and Climacs get the latter right but not the > former; with the following patch, I am able to do things like > > (sb-thread:make-thread (lambda () (climacs-gui::climacs))) > (defvar *foo*) > (sb-thread:interrupt-thread * (lambda () (setf *foo* *application-frame*))) > (clim:execute-frame-command > *foo* `(climacs-gui::com-insert-parentheses 0 nil)) > > and watch the parens be inserted into the *scratch* buffer. (Warning: > I haven't in fact done precisely this -- I have instead been running > climacs under the new mcclim "Null" backend and inspecting the data > structures themselves). So it turned out that in a backend with actual display this wasn't behaving quite right, in that the panes weren't being redisplayed after a synthetic command event. I turned that on, and then got all sorts of errors, which I think the attached patch resolves. The basic point is that methods on both execute-frame-command and redisplay-frame-panes must not assume that they are being run within the thread of the application; nor must display-functions for panes. I think the attached fixes this for climacs, and involves some ESA modifications. Cheers, Christophe From csr21 at cam.ac.uk Sat Mar 25 21:13:08 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Sat, 25 Mar 2006 21:13:08 +0000 Subject: [climacs-devel] execute-frame-command In-Reply-To: (Christophe Rhodes's message of "Sat, 25 Mar 2006 21:08:19 +0000") References: Message-ID: Christophe Rhodes writes: > I think the attached fixes this for climacs This is the first time in approximately three years that that's happened. contains the detail of what my stupid fingers managed to circumvent... -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: esa.diff URL: -------------- next part -------------- Cheers, Christophe