synch2writeroom

Tags ( )

This is a glueing together of Jeffrey Alexanders 2writeroom script, and the synch to external editor script I posted earlier. Basically it synchs (both ways!) a single writeroom to the text of the current note. The idea is that the writeroom sits behind Mori with the note text. When you want to go there you activate (by quicksilver or clicking) when you want to come back to Mori you quicksilver back. However DO NOT RUN THIS FROM WITHIN THE MORI SCRIPTS MENU. That seems to make everything hang. You can run it from everywhere else though. At some point I'll look into what goes on there.

tell application "Mori"

-- grab the content of the active note (even if blank) and throw it to WriteRoom
tell application "Mori" to set my_text to note of (current entry as reference)
set e to current entry
tell application "WriteRoom" to activate

-- here we work around a bug in WR 1.0beta, which needs its documents created through the menu routine in order to autosave, otherwise we will get bitten by a recurring prompt to save the new buffer
tell application "System Events"
tell process "WriteRoom" to click menu item "New WriteRoom" of menu 1 of menu bar item "File" of menu bar 1
end tell

--the fun part
repeat
tell application "WriteRoom"
tell application "Mori"
set my_text to note of (current entry as reference)
set e to current entry
end tell
set my_WRdocument to the document of window 1
set the zoomed of window 1 to true
set the text of my_WRdocument to my_text
end tell
tell application "Mori"
repeat while e is current entry
set last_note to note of e
tell application "WriteRoom"
set my_WRdocument to the document of window 1
set my_text to the text of the document of window 1
end tell
delay 1
set current_note to note of e
if current_note is last_note then
set note of e to my_text
else
tell application "WriteRoom"
set text of the document of window 1 to current_note
end tell
end if
end repeat
end tell
end repeat
end tell

Version: .2

I can't duplicate your problems

That's fairly workable if you want you changes applied back to Mori as you type; although there are some tweaks still necessary in your code for processing overhead, that's an interesting take on it. I wonder though why would you return to Mori and change the active note while you had it open for editing? but in any case I couldn't duplicate your crash when you changed active notes. The WR window is not temporary, it is a completely independent window with the text from Mori copied into it. If you (or anyone else)is having that crash with any frequency, let me know. And it runs fine when launch from the menu bar (how would it not?) -- in the original version, anyway. I wonder what your error messages were.

It's a little different from using WR as the fullscreen option of Mori (in the way other editors use fullscreen), you're essentially using both editors simultaneously. This version also limits the options which I was planning on exploring of allowing the user to choose whether to replace the content of the original note (updating) create a new note (versioning) or create a new note while calling Apple's FileMerge to do a diff-style comparison of the new and old, or even other post processing -- for example, saving the original, running a copy through textile, writing the resulting XHTML markup to an external file or application or even uploading it/writing it to a server directory automatically....

Even more fun. But I'm glad my code could help you with what you were needing to do.

im not sure how bad the overhead is did you actually profile it

You can of course increase the delay. Im sure your version runs fine from the Mori Launch Bar. The trouble with this version launching from Mori (which I only made it do once and it ground the whole world to a halt) is that when a process like say quicksilver or the menu bar launches one of these "watcher" scripts it can often freeze the original process. This isn't so bad unless the process is Mori.

The idea is that you can freely switch between both the note pane and Writeroom. As for why you might... re edit in Mori after you open it up. Well you might not (although I discovered this problem by absent mindedly doing so) But you might also want to edit a note purely in the notepane. Without the two way sync whatever you write would get overwritten by the writeroom.

You can think of this script as replaceing the Writeroom autosave to the filesystem to an autosave to Mori. Mori essentially serves as your writeroom file system.

I suppose we give up flexability of versioning in return for transparency of operation. You can still run whatever postprocessing you like on the note text.

And Quicksilver may be the culprit,

I don't use it or any system-wide config utilities like that. I dink with my system enough by what I _know_ I'm doing, I don't need a conspirator in the background at cross-purposes...

As far as what you term transparency of operation, I still don't see that, but rather more uneeded complexity. This would be the first app where you could edit at the same time in both fullscreen and windowed, and since one actually _can't_, physically do that, I don't see the point, as opposed to switching back and forth when you need to, as often as you need to.

In other words, you can switch back and forth every third word, but you are still switching -- simultaneously tracking buffers is useless, unless one is being viewed remotely by another person. (And a network admin would murder you if you ran this script that way....). As long as when you move from one mode to the other, if the text is completely updated when the switch occurs, isn't that good enough?

The processing overhead probably won't be noticable in user performance at this point unless you switch for a moment to Photoshop or GarageBand or watch QT video or the like while a synch is operable. But you realize that even as you sit and stare at the screen (a necessary part of my writing, more and moreso), or go fo a cup of coffee, there's cycles being expended synching indentical copies of text over and over. I'd love to see the effect on battery life.... :)

the best approach is to change on change of focus

I don't know how to do that. Anyway Im not sure why Quicksilver would matter, (or be any different than any other program or conspirator).

re Q-sliver...

Never trust 3rd party apps that try to act smarter than the system software it sucks up to.

Change of focus?

You're in Fullscreen, there is no change of focus, logically. But if you quit fullscreen, yes, then the content is written back as edited and displays in Mori. Enter Fullscreen again? first verse same as the first.

Now, yes, you can leave the WR screen up but (for example) you cmd-tab to Mori -- yes you can do that, but what are you doing that for? Just to have a peek? and if you do, should it not still be the unedited text you left there?

Here it is: Open a note (new or used), Open fullscreen, Edit, Close fullscreen, All is well, rinse, repeat. A simple workflow, a simple method. Two simple scripts for two simple apps, simply beautiful.

you seem to be angry about something

And Im sorry for that. Its just an applescript.

anyway regardless you are right you can write two scripts

thats fine, and probably the right way to go. I don't know. I was just lazy, and I just had already written this admittedly hacky script so that you could, essentially replace the note pane with a scriptable text editor (which So, with your bug work around, I applied it to writeroom. Thats all. No one has to use it. Anyway as for the cpu cost, its between 3 and 12 percent (on a 1 Ghz Ti Powerbook) depending on whether you are synching or waiting, and the size of the note.

Still, you should try quicksilver. (not for this, it really doesn't have anything to do with this. Here command-tab would work as well.) Combined with mori and applescript you can do quite a lot. I don't think you will find it so bad. Anyway good luck and thanks for all your help.

ah, no,

Not angry at all, I was just 3 hours late getting home last night, and grumpy. But I would look into whether or not QS is causing your AS problems.

I don't see how that is even

I don't see how that is even possible. This isn't like the old days when an application like QuickSilver would have required a kernel extension and thus have the ability to bring any random other system to its knees. It is just an on-demand data movement and launching tool; wholly initiated and controlled by the user. It doesn't do anything "smart" in the background until you've phsyically entered commands into the little QS box and pressed return.

--
Av.

im almost certain that QS has nothing do with it

I am not even activating it. Its just another program on my computer. Further, I have observed that if you launch some applescript which polls your machine in this manner the launching process (QS, Mori whatever) often suffers. For example QS will cease to operate until your script terminates. I am almost certain that was the difficulty. Anyway i don't really care enough to diagnose this. I am just letting people know that I launched this thing once from Mori and it slowed things way down. But from another script menu it puts some (say 5-10% load) on your system but nothing horrendous.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.