[climacs-devel] execute-frame-command

[Robert Strandh]

Hello,

Christophe Rhodes writes:
 > 
 > 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: 

OK, sounds good. 

 > and indeed
 > execute-frame-command should not assume that anything has been
 > executed.

I don't understand what you mean here. 

 > 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?

Yes.  I think it was done that way because either McCLIM was not able
to acquire the arguments at all, or it did it in a way that was not
acceptable to Climacs.  Writing our own partial command parser sounds
like the right thing to do (and I believe you have already done this,
at least partially (no pun intended)). 

 > PS: My kingdom for only one copy of ESA...

I agree that it would be nice to break out ESA and turn it into its
own cl.net project.  The problem with this is that someone has to have
the project created, administer the mailing lists, etc.  Furthermore,
it will add another dependency, but I guess that is not too much of a
problem compared to maintaining two copies.

Does anyone want to become the proud owner of a cl.net project?

-- 
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.
---------------------------------------------------------------------