[texworks] Lua scripting

[Stefan Löffler]

On 2009-06-09 07:31, Jérome Laurens wrote:
> Scripting is sometimes a good candidate to extend the possibilities of
> an application, but care must be taken to provide a good API for that
> purpose.

That's true of course, and we're not even close to it, yet. My patch
only included sort of a "prove the point" implementation, with very
rudimentary API. This will certainly grow if Lua is incorporated into TW.

> In particular, gathering all the scripts in one script menu is not a
> good idea if the scripts become numerous.
> The example given by Hartmut is typically something that should not
> appear in a script menu.

That's true. I didn't want to go into all the details of UI design at
the very first stage, however (and thereby blowing up the code for the
initial patch). So showing scripts in the menu seemed a viable option to
begin with. The GIMP for example has the same approach, although they
are using submenus as well (something that almost certainly gives
problems with translations, btw).
I'm not sure which example you're referring to, but from the rest of
your mail I assume it's about log parsing. Those scripts (which
implement hooks run from the TW core at various stages rather than by
the user) don't appear in the menu, anyway. They are listed (separately)
in the "Manage Scripts" dialog, though.

> More precisely, the parsing of the output log file should be
> automatically initiated once the typesetting process has successfully
> ended.
> In short, there should be an "engine" which only purpose is to typeset
> the current document with latex or texexec or whatsoever and analyze
> the output for possible errors.
> In case of an error, a visible signal should be sent to the user (like
> the red traffic light in textures™).
> There also can be a tiny stop icon in front of each line where an
> error occurred, and when you click or roll over this icon, the reason
> appears in a small note window.
> Eventually a check box in some preference pane could allow to suppress
> the parsing of the log.

As stated above, any hooks (such as output log parsing) will be run
automatically. And while I appreciate nice icons, the problem with this
is designing a proper API to get general access to that (imagine, every
type of error for every type of engine could want its own icon, which
shouldn't be built into TW as they are only necessary for the extension
script). That's the reason why my example script only parses the log
output and extends the built-in mechanism by presenting the user with a
list of filename, line, and error description.
BTW: Showing icons next to the line causing the error is nice, but I for
one would appreciate a list of all errors. This is especially important
if you multiple and/or long files and don't want to scroll through them all.

> Extending TeXWorks with scripts is nothing but a plugin design.
> Unfortunately, scripts won't do everything and other sorts of plugins
> are necessary.
> For example, configuration files used in syntax coloring are also
> plugins.
> There should be a unique plugin design to render
> installation/Uninstallation straightforward.
> The user is not a configure/make fan.

That's right and has been a problem with TW for quite some time -
digging into the configuration folder structure. Unfortunately there is
no such unique design yet, in particular there's no descriptive
packaging format which would enable an (un)installation from within TW.
But I agree that this will be absolutely necessary in the future.
BTW: I've been thinking about being able to (temporarily) disable
scripts. Right now this isn't implemented, so you'd have to move or
rename the script file itself. But this should definitely come as well.

> Finally, lua is powerful but dangerous. TeXWorks should launch scripts
> in a safe environment to avoid viruses and other kinds of malware.

I'd appreciate any information you could give me on that. As said
before, I've only just started experimenting with it seriously, so I
haven't dug into all the details, yet. I suppose you mean that certain
system calls should be deactivated? Or that the user is at least asked
to confirm certain actions? On the other hand, if the user installed the
script (once there is an installation procedure ;)) shouldn't we assume
he did that on purpose rather than constantly ask (something I usually
appreciate on Linux, but then again I may not be the average user -
being a fan of configure/make and all ;)).

-Stefan