[texworks] SCRIPTING: global __FILE__ now only available when debugger on?

Stefan Löffler st.loeffler at gmail.com
Mon Jan 16 07:42:35 CET 2012


On 2012-01-12 07:43, Paul A Norman wrote:
> These new properties on TW.script  have made  something worthwhile
> possible for checking for updates on scripts... in fact
> "TW.script.date" may even be worthwhile?

Yes, it may be worthwhile, but not too easy to implement. Which is why
we have TW.script.version. If one uses, e.g., a "MM.NN.PPPP" format, the
PPPP part can be incremented by one each time a new script is made
available publicly (or any time a change is made, or whatever) - call it
"revision number" if you want (or use a version control system to track
your script files).

To elaborate on the (potential) problems with a date field:
For one thing, if it's a date, it should be stored internally in a
QDateTime variable. This could cause problems with accessing it from
scripts (though I haven't checked). What's more, people from different
parts of the world specify dates differently (e.g., MM-DD-YYYY vs.
DD-MM-YYYY). And different time zones etc. would have to be taken into
account. Besides, if anyone ever would make several changes in one day
(e.g., a new feature in the morning, and a bug fix in the evening), we'd
have to include the time in that field as well. So the field would get
quite long and for most (casual) script authors quite tedious to fill
out / update.

So, bottom line, for the moment I think a (well maintained) version
field should provide enough information for all use cases I see right
now. If I overlooked something, please let me know (as always, of course

That said, I really liked your write-up! Maybe it would be beneficial
for some users if you could add (simple) sample JS/php scripts. While
such scripts may be obvious for a script-savvy web-programmer, they may
be complicated to figure out for casual Tw script authors without much
experience in web programming.


More information about the texworks mailing list