[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Texmacs-dev] Interactive feedback
|
From: |
Joris van der Hoeven |
|
Subject: |
Re: [Texmacs-dev] Interactive feedback |
|
Date: |
Wed, 25 Feb 2004 16:17:09 +0100 (CET) |
On Wed, 25 Feb 2004, David Allouche wrote:
> Nice feedback, I really appreciate it.
>
> On Wed, Feb 25, 2004 at 11:48:26AM +0100, Joris van der Hoeven wrote:
> > (let-interactive ((x "First argument")
> > (y "Second argument"))
> > prg)
> >
> > which should return nothing when executing, but which passes
> > control to the status bar (or a popup widget) and asks for
> > user feedback. Moreover, we keep the "prg" continuation,
> > which is executed when the user is done (except when
> > the user cancels).
>
> If I understand correctly, this should already be feasible using the
> current improved implementation of "interactive", and without actually
> using Scheme continuation, though it is reminiscent of the "continuation
> passing style".
>
> (let-interactive ((x "First")) <body>)
> ==>
> (interactive '("First") (lambda (x) <body>))
>
> Something like (just proof of concept, more syntax checking would be
> needed):
>
> (define-macro (let-interactive prompts . body)
> `(interactive (quote ,(map second prompts))
> (lambda ,(map first prompts) ,@body)))
>
> Continuations are essentially a mechanism for non-local exit, there is
> no need for non-local exit here, so no need for continuations.
OK; that seems fine too.
> > The current way of handling interactive commands can
> > also easily be simulated.
>
> I'd rather take it the other way around. What you propose can be easily
> implemented on top of the improved "interactive" primitive.
Whatever you prefer.
> > It might be a good idea to implement user feedback from
> > popup windows all along with this. Also, the idea may
> > be further extended so as to allow things like
> >
> > (let-interactive
> > ((name "File name" url)
> > (operation "Operation" (enum "Blah" "Hop"))
> > (confirm? "Really do this" bool))
> > prg)
> >
> > and to generate an appropriate widget or footer feedback.
>
> That is a whole different can of worms. A KISS system to build dialog
> windows would indeed be a good thing, but I do not really feel like
> digging in the texmacs toolkit code to do that. I'd really rather just
> tear the whole thing down and put another toolkit in there.
We probably do not need a full-fledged system here.
What would be cool is just a dialogue with a list of
text entry fields with the explaining texts and
"OK" and "Cancel" buttons. Later on, one might slightly
improve this by having addional buttons for browsing file
arguments and checkbuttons for boolean values (the file browser
may be launched automatically if there is only one file argument).
Notice also that the above proposal really contains two parts:
one part is about building a GUI and the second part is about
using typed arguments. This could already be done for the most
important currently used types and this seems much cleaner to
me than the current use of string values everywhere.
Another idea is providing default values.
> On a more incremental perspective, it would be a good thing to provide
> support for tab-completion in the footer. I think the right way would be
> something like:
>
> (interactive `(("Prompt" ,tab-complete-prompt)) proc)
>
> Where tab-complete-prompt would be "string -> (list string)" and return
> a list of possible completions for the current prompt. Tab completion
> would only be enabled when the caret is at the end of the footer input
> text.
I agree.
> Probably something more elaborate would be nice to provide zsh-style
> tab-completion, but this interface might be enough for bash-style
> completion. Actually looking at the interface for defining
> tab-completions in zsh, bash or emacs would also be a good thing, since
> it would save us the trouble of reinventing this wheel.
We almost have (had?) what is needed in the case of file-name completion,
although I have to check where that was exactly.
> > Delayed commands might be implemented in a similar way too.
>
> What are you thinking about? As far as I understand delayed commands, it
> is just a mechanism to postpone the execution of a procedure until the
> next time the main event loop is run.
Yes. In fact, one might also use closures here.
In any case, interactive and delayed commands are the only places where
we do not (systematically) use closures yet. It would be a valuable
contribution to systematically use closures everywhere, so David made
a good start.