[texworks] SCRIPTING: global __FILE__ now only available when debugger on?
Paul A Norman
paul.a.norman at gmail.com
Mon Jan 16 13:21:42 CET 2012
Here is a TeXworks script that does a prof of concept for the thread here.
Temporarily it points at a page on twscript.paulanorman.info
I think that we need some sort of easier exposure to script of release and
version strings please. You'll see what I mean if you look at the TeXworks
(I don;t think version is at all available as yet.)
On 16 January 2012 21:51, Paul A Norman <paul.a.norman at gmail.com> wrote:
> On 16 January 2012 19:42, Stefan Löffler <st.loeffler at gmail.com> wrote:
>> 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
> Thanks Stefan, I agree entirely, I only saw it as descriptive for
> additional visual comparison purposes (and upto the Script Author
> what they were showing in there - not as a programmable piece of data) and
> as you point out, we can entirely rely on the Version field.
> Interestingly, due to the international nature of the TeXworks project, in
> the TeXworks Script Api, in the descriptive text I am actually frequently
> adding superscripted th nd and rd to YYYY-??-?? dates to make it very clear
> what form they are in, and what they mean.
>> 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.
> Can you add an extra TeXworks sub page to the existing TUG TeXworks page
> on TUG?
> I had been thinking to actually do a simple page for there (with
> that a Script could call, which would show the User what their:
> 1. current version +rev was,
> 2. their release (TeXworks direct or say MikTeX - I think that is
> exposed to scripting?),
> 3. what the current Official TeXworks release ver + rev was ( with
> link to downlaod page ),
> 4. and what the latest Development version and rev was (with link to
> downlaod page).
> Thought that might be an immediately useful example - what do you think?
> It would require maintaining a simple external text data file along with
> the new .html page on TUG.
>> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the texworks