[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Texmacs-dev] Re: extern-exec and "further customization"

From: Lionel Elie Mamane
Subject: [Texmacs-dev] Re: extern-exec and "further customization"
Date: Mon, 6 Feb 2006 16:59:30 +0100
User-agent: Mutt/1.5.11

(Moving the discussion to texmacs-dev. Please reply there + CC to me;
a MUA with M-F-T support will do that automatically.)

On Fri, Feb 03, 2006 at 12:02:58PM +0100, Joris van der Hoeven wrote:
> On Fri, Feb 03, 2006 at 12:34:09AM +0100, Lionel Elie Mamane wrote:

>>>> TeXmacs doesn't appreciate plugin foo
>>>> telling it
>>>>  DATA_BEGIN command:(plugin-eval "foo" "default" "bar") DATA_END
>>>> it seems to go into an infinite loop of issuing bar to plugin
>>>> foo.

>>> This is not reasonable: your plug-in might directly execute the
>>> command instead of passing through TeXmacs.

>> This supposes that the command does not depend on the TeXmacs
>> state. I was hoping to get information about the TeXmacs state in
>> this way. Something like:

>>  DATA_BEGIN command:(plugin-eval "foo" "default" (string-append "callback: 
>> pos foo " (object->string (position-get foo)))) DATA_END

> I agree that we might want to send some information back on

>       DATA_BEGIN command: ... DATA_END

> You may try to hack the TeXmacs source code so as to send

>       DATA_BEGIN return: ... DATA_END

> back to your plug-in when the command evaluates to a non-void
> result.  If done correctly, I will include such a hack in the main
> distribution.

What about adding a level of indirection in the communication between
"session" and the plug-in? What I mean is:

 - When the user types a command for the plug-in in a session, instead
   of sending what he typed, call a scheme procedure with arguments:

   * the string the user typed
   * the port used to talk to the child process

   For backwards compatibility (and to keep simple plugins simple),
   the default function would be the composition of "display" and
   "replace newline characters with spaces", that is the current

   The plug-in would declare a different procedure - if any - in its

 - Something adequate for the other direction (communication from the
   child process to TeXmacs).

   For example:

   - A plug-in can install a handler "foo" for
     DATA_BEGIN "foo: " data DATA_END
     that will get data passed as an argument.

     Along with a naming convention that plugin foo should register
     only names starting with (string-append foo "-").

Would such a design seduce you?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]