Save to multiple directories

To keep more than one directory (usually two) up to date with the file one is editing, particularly between scheduled backups, it is awkward to have to do complete Save-as drags to each open directory. What about a dual or multiple Save mechanism?

I could envisage, for example, dragging the icon from a Save-as box to a configured icon (on pinboard or iconbar) that would cause Filer to save to more than one location. That would be an extension of what is already available to one directory via *AddTinyDir.

Allowing Adjust drag to leave the Save-as box open for a second drag could be another solution, but perhaps less elegant.

Has anyone thought about this before?

It might be better to have a program which keeps two directories continually synchronised (ala DropBox), rather than complicate the save as mechanism for what is quite an edge case.

Actaully I realise one can’t currently drag save to an AddTinyDir icon bar icon as I imagined, though an icon that represented a short program that did accept a Save-as icon could work. I will look at RiscLua for this.

And druck’s suggestion is also worth considering.

Perhaps an application could present a window into which saves could be dragged but be aware of the intended multiple destination directories and simply do a background copy or copies after the transfer has finished.

Could also monitor the principal directory for the last saved file and update the multiple copies if it changes.

Wouldn’t be a difficult app to write.

At Bernard’s prompting I have cooked up a small application !Multisave . I would be grateful for feedback.

I take Druck’s point. It is an edge case. However, it is very minimal, it could equally well be written in BASIC, and should be easy to extend or modify – to keep records of activity, for example. Anyway, I am grateful for any opportunity to tinker with small throwaway programs that do not tax my concentration beyond capacity.

I have whipped up a small application !Multisave . I would be grateful for feedback.

Loading your RunImage into StrongED to inspect your work raises an error:

File Lua.Modefile
Line 25
Error Missing "

I assume that this is an error in my Lua Modefile.

Does this happen to anyone else and what should I do to correct it please (StrongED 4.69f11)?

You can get modes from here but I think they are rather ancient. The Lua one is dated 23/10/11, for example. In fact I sent an updated Lua mode to Fred Graute quite recently, being dissatisfied with what I had previously submitted. My current Lua mode is dated 2021/03/08 and I am using it with StrongED 4.70a14.

John, in Lua’s modefile you need to add a space in between the 2 quotes after “lua-variable” on line 25.
Fred is aware.

John, in Lua’s modefile you need to add a space in between the 2 quotes after “lua-variable” on line 25.
Fred is aware.

This is Gavin’s Mode File dated 09/02/14 for RiscLua 5.70.

To be clear, as there are two mentions of “lua-variable” on that line, it’s the empty string that needs a space in it. Is that right?

That seems to have suppressed the error here, but as my understanding is (very) limited… !

Yes, it’s the empty string that needs the space.

Yes, it’s the empty string that needs the space.

Thank you.

Now all we need is for Gavin to produce a heavily-annotated version so that we can get a flavour of how Lua works!

After all, he did say:

I am grateful for any opportunity to tinker with small throwaway programs that do not tax my concentration beyond capacity.

Yes, it’s the empty string that needs the space.

We all need space.

Now all we need is for Gavin to produce a heavily-annotated version so that we can get a flavour of how Lua works!

I am working on a fully illustrated StrongHelp manual that I hope will answer your need. In fact !Multisave is written as a sticky . The core program is in BASIC which must be a good thirty years old. It sets up a wimp task that puts an icon on the iconbar and which calls Obeyfiles, !Select and !Adjust, to respond to clicks on the icon, and , in this case, a TaskObeyfile called !Drag for drags onto it.
In other words the BASIC program deals with all the wimp stuff, which in this case is minimal (no windows), leaving only the clicks and drags to the iconbar-icon for other things to respond to. In this case !Drag happens to call a short Lua program.

PS. Major edit. I have been talking rubbish. About to upload a simpler version. Senior moments etc.

The phrase buffered side down comes to mind; and the Rabbi explaining My son, it means that you buffered the wrong side.

Is double-buffering likely to cause weight gain in the code?

OK. Heavily annotated version now on my website. The program is divided into chunks each chunk being commented for the words it uses and the words it exports . As Harriet Bazley noted many years ago, Lua programs are best read backwards, last chunk first. It is the last chunk that does the business, as a rule, with the earlier ones providing what it needs. I have also provided a StrongHelp manual to explain how stickies work.