Editor commands and errors
This is a slightly long description for a small problem, but want to
explain what I'm trying to do so that it looks less strange, and also
in case anyone can point at some obvious better way.
I have a system which has an INTERACTIVE-PANE (with attached
ECHO-AREA-PANE) which has in it a little command interpreter. This
understands various commands which expect filenames &c as arguments.
So I can say:
crs select "/project/.../Component.def"
say. If you don't give a filename argument the system prompts in a
stylised way - by calling a prompt-for-file GF on an `interface-type'
object, methods on which control what the actual prompt mechanism is.
This is done because the whole system runs on a tty interface too.
Until recently I was using the normal CAPI file selection dialogue for
the CAPI version, which worked OK, except that on Motif it's horrible
because the motif file selection dialogue just is horrible.
So I thought, heh, I could use the editor file prompting function
(EDITOR:PROMPT-FOR-FILE) and other stuff, which have much nicer
interfaces, and also look like emacs, which is good.
How to do this is not really documented - as far as I can see it's
only documented how to call these functions from editor commands
(where they work fine). For various reasons - mostly to do with
nontrivial argument conventions &c - I don't want to define a lot of
editor commands, I just want to be able to call the functions.
I discovered that CAPI:CALL-EDITOR will accept a function as well as
an editor command name, so you can say
(capi:call-editor e #'(lambda (p) ...))
And this seems to work. However, in order for things to work you have
to be in the right thread, which is not my command interpreter's
thread. So what I ended up doing is something that looks like this,
If E is the INTERACTIVE-PANE:
(execute-with-interface
(element-interface e)
#'(lambda (editor)
(call-editor editor
#'(lambda (prefix)
(declare (ignore prefix))
... code that does PROMPT-FOR-FILE ...)))
e)
In real life this is considerably more complicated, because you need
to handle errors (since half this code runs in some other thread), and
also get the function's results back to the caller (again, complicated
by the thread change). So there's a mailbox, into which the function
stuffs its results, or an indication of what went wrong. And there is
various interlocking to make sure this all actually works.
Amazingly enough this all works, and once it's wrapped in a macro it
even looks nice.
The problem is that, when prompting for a file, if you try to move
back beyond the start of the minibuffer (or forward beyond the end, or
many other illegal things), an error is signalled. This doesn't (seem
to) happen if you use PROMPT-FOR-FILE within an editor command, so
presumably I am somehow failing to set up some needed context. Does
anyone know what I need to do to make it behave the same way as it
would within an editor command?
A second problem (and why I gave all this description): is there an
easier way to do all this? What I'm doing seems to be overcomplex,
and involves undocumented things (CALL-EDITOR accepting a function, at
least). There should be an easier way...
Thanks
--tim