Scratchpad's "Open File" command is great for me, since I like to edit in Emacs, and it lets me keep long-lived scratch work. But whenever I modify my file and want to run it, I have to open it all over again, which involves navigating a file picker. It would be great if Scratchpad somehow saw that my file had changed on disk and automatically reloaded it. Two suggested designs -- both would become "active" only after a file has been opened: Option 1: A "Reload and Run" command (say, Cmd+Shift+R). If the text in Scratchpad's UI hasn't been modified, then "Reload and Run" re-opens the file, updates the UI, and runs it. If the text has been modified, then it warns the user that his modifications will be lost and asks if he wants to continue. Option 2: Detect when the currently opened file has changed on disk. When that happens, if the text in Scratchpad's UI hasn't been modified, silently update the UI with the contents of the file. If the text has been modified, then ask the user what to do: either update the UI or not. This is how Apple's Xcode works, and it works well IMO. Is this something you guys would accept? If so, I'd like to work on it.

We would absolutely accept something like this. One possibility for Option 2 could be to stat the file on opening, and store the last-modified timestamp for the file. Later, on scratchpad focus, restat the file and compare the timestamps. If it's been touched, ask or automatically update the file. This could be awesome for allowing external editing of scratchpad files in the editor of your choice. Nice.

(In reply to comment #1) > This could be awesome for allowing external editing of scratchpad files in > the editor of your choice. +1 Perhaps along with this another key command for 'reload from disk' so you can toggle between emacs and firefox and not have to always edit in the scratchpad, which would speed up the workflow at times.

I did a bit of research on this a while ago and it appears we do not have the inotify-like multiplatform xpcom interface that would be required for efficient implementation of this feature. Should we open a separate bug?

I have a patch that just stats the file (actually, it's just using nsILocalFile) each time that Scratchpad's window is focused. Kind of cheating, but it works OK, assuming an actual human is externally editing the file using the same desktop as the one Scratchpad's running in.

Will not work when Scratchpad is integrated in the browser... or would require also to use nsIWindowWatcher to check the browser window focus moreover the scratchpad focused for the current tab.

I think the proper response to my comment is, "Wow, that's a clever hack." Even if Scratchpad were inside a tab or browser window, tabs and browser windows are focused too. Actually, it would probably be better to check for focus on the textbox.

Right, listening 'focus' on the scratchpad textbox might work great in most cases. I'm sorry if I forgot a "probably" or a "might" and/or my comment sounded rude, it was not intended ;)

Might need a combination of checking focus and blur though. The user would otherwise have to be careful to use "Alt-Tab" or click directly in the Scratchpad's textbox in order to put the browser window to foreground again. Also on a dual-screen setup, this whole focus dance looks weird/unnecessary. Not that the hack is not clever and certainly is nice meanwhile but I guess we both agree this is not "the right way (tm)".

(In reply to comment #4) > I have a patch that just stats the file (actually, it's just using > nsILocalFile) each time that Scratchpad's window is focused. Kind of > cheating, but it works OK, assuming an actual human is externally editing > the file using the same desktop as the one Scratchpad's running in. wow, that's a clever hack! ;) kinda sounds like what I suggested in comment 1. In any case, I think when we embed the scratchpad, I'm not sure we'll provide a full file menu. Embedded scratchpads will likely be more simplistic.

filter on PEGASUS.