Yes, in fact right in the same spot as the set-up for fetching from the net, you can set up what you are looking for. The attribute AutoFetchCommand will execute when AutoFetch is enabled. Try something like this in AutoFetchCommand:

Code:

Text=`cat ~/Documents/some_text_file.txt 

Then, with AutoFetch set to true, open the note. It should have the contents of the file loaded already. Everything to the right of that ` symbol is sent to the UNIX shell. So you can run pretty much anything in there that prints to STDOUT and get the results imported automatically into Tinderbox.

Note, if you meant "text file" in the non-purist sense, and what you are trying to import is actually RTF or something, you'll want to use a different command. Something like:

Code:

Text=`textutil -stdout -convert txt ~/Documents/some_rtf_file.rtf 

Bi-directional is going to be more tricky. The potential for the Rule and AutoFetch stampeding all over each other would exist, and you might risk losing data one way or the other. In this matter, personally, I would be less inclined toward automation. It would certainly be possible to write out files using a Rule, the question is whether that would be prudent. For one thing, file operations are going to be slower than other Rule actions. If you have a bunch of them constantly writing to the hard drive it would needlessly wear out your hardware and slow down your system. Then there is accidental data loss to consider. Example: You spend a day writing in TextMate, then a few days later open your Tinderbox document. AutoFetch doesn't run until the notes are opened (I think... though there might be a delay), but the Rules are going to run instantly and constantly---they will export the days-old content right into your files without even asking if that is what you want to do.

Alternatively: Tinderbox is a very capable exporter, and while its default system attributes are all set up for HTML export, it is fairly simple to circumvent that with a few attribute modifications, file extension adjustments, and so forth. With a little customisation, the "HTML" exporter can be informed to export nearly any file format. The advantage of using that over the text exporter is that it can retain file structures. You could mirror the directory you wish to keep up to date, in Tinderbox, and when you export the files and folders will all end up where you would expect them to.

Another alternative would be to roll your own exporter. This could be accomplished with a few attributes and a couple agents. I would store the path and name of the file in a string attribute instead of using the File attribute because of the path addressing differences. Tinderbox uses the legacy Mac method of displaying paths with colons, as you noted. Then a boolean attribute "ExportNow" or something, which triggers an agent with an AgentAction containing the export action, and finally un-sets ExportNow, making it a one shot deal. In other words, exporting becomes an intentional, per-document decision. Of course, you could set it up to export an entire range of documents once, too. It would all depend on how you set up the attributes and agents.

I would definitely try playing with the HTML exporter first and see if that is going to work for what you need. Any other route is going to be potentially complicated . HTML export comes in two flavours: Single-note export (Cmd-Opt-H), and full document export (Cmd-Shift-H). The latter respects an exclusion attribute, so you can narrow down what "full document" means.

One thing is clear, if you are going to want bi-directional, AutoFetch probably isn't what you want. It would be too easy to accidentally lose work. All it would take is typing in a note for a while, forgetting to export, and then re-opening the note later.

Sourcing you AutoFetched note's content from a File path is possible. OK, first you need to set the note's URL attribute to be the path storeed in the File attribute.  But you can't just set an action URL=%File as the File path will look like this:
Macintosh HD:Users:mwra:Desktop:Path test.txt
and the URL needs to be in this form:
file:///Users/mwra/Desktop/Path%20test.txt
So you'll need to urlEncode() your File path and use a script a regular expression to swap out colons for slashes plus remove the path's volume name replacing it with the file:// protocol. Using my example above you'll go through stages (within the action & script) like the following, where 'xyz' is the short name form of the current user's account.

Read the File attribute
  Macintosh HD:Users:xyz:Desktop:Path test.txt (=value of $File)
  Macintosh%20HD:Users:xyz:Desktop:Path%20test.txt (=value of urlEncode($File)
  Macintosh%20HD/Users/xyz/Desktop/Path%20test.txt (after shell regexp replace colons->slashes)
  /Users/xyz/Desktop/Path%20test.txt (after shell remove volume name)
  file:///Users/xyz/Desktop/Path%20test.txt (after shell prefix with 'file://' protocol)
...then pass to URL attribute as value

[post edit: this is a conceptual answer - I've not successfully tested it to through to the OP's desired result]

Amber, your CL gives me - with a text file on my desktop as $File - a truncated URL value of 'File://'. Regexp issue? I'm not CL/regexp savvy enough to fully understand the sed syntax!

Testing my above idea a bit further, again with a 'txt' file on my desktop, I find that if I explicitly set the correct file:///etc.... URL ViewInBrowser 'true' opens the file in TextEdit but when false the note doesn't show any text. I also tried these as AutoFetchCommands:
runCommand("cat '"+$File+"'");
runCommand("cat '~/Desktop/some_file.txt'");

Perhaps we're pushing TB a bit too far in this context? I know Mark B's away at a conference right now but he may have a more authoritative view on what syntax is reasonable to try when he gets back.

Brilliant !!! It works like a charm . Only caveat is I have to clear the file close the note and let the text window clear to nothing then attach a new file and it reads that file as well . This is definitly a motivator to get better at my shell scripting . Thanks for your help.

Great, thanks for sharing that. Works fine here too.