[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Groff] File Locking
From: |
Robert Thorsby |
Subject: |
Re: [Groff] File Locking |
Date: |
Fri, 14 Mar 2008 10:12:22 +1100 |
On 14/03/08 09:29:41, Tadziu Hoffmann wrote:
> > My script runs in the foreground but launches
> > both the editor and gv to run in the background.
>
> Ah. I misunderstood. (Probably because your philosophy
> is somewhat different from mine -- I launch the script
> from the editor (not the other way around), and the
> editor is "blocked" until the script terminates, so this
> kind of thing can't happen.)
>
> But now I'm wondering: how does the editor communicate
> with the script, i.e., how does the script know when
> you've pressed the "save" button? (Apart from the script
> simply polling the file in regular intervals, which either
> wastes CPU time (not too much of an issue these days) or
> makes you wait unnecessarily until the next update.)
You are correct. My script runs stat against the input file every two
seconds -- kludgy, I know. CPU cycles are not really an issue, at least
not when compared to my scripting skills. After all, I am supposed to
be writing a letter, not doing a Gentoo-style "re-compile world".
At the moment a maximum delay of two seconds is not a problem, but I
intend to reduce that to one second and see if the faster re-groffing
actually achieves anything practicable.
BTW, the reason why the script launches the editor rather than vice
versa is that the script first loads a config-style file into the
editor. This way I can feed in all the information about addressee,
subject matter headings, references, signature blocks, etc etc. Then I
close the editor and the script turns the original input file into a
proper groff file which it loads into the relaunched editor (in the
bg). The script also outputs a postscript file which it loads into gv
(also in the bg). The script then monitors the newly created groff
file, into which I can add the body copy and amend the preliminary
stuff. It is this lastmentioned file that is monitored for changes.
> I think I'll agree with Ted -- this is mostly
> an academic issue, since no permanent harm is
> being done by "saving at the wrong time".
Yes. Not being a programmer, I was concerned that I might be getting
carried away with my own cleverness.
Robert Thorsby
Without C we would only have Pasal, Basi, and obol.