I mentioned this in my review, but now after a couple of weeks of using SD, I’d say this is for me the biggest “missing feature” in Script Debugger.
Pretty much everyday I’m thinking: hellfire, I wish I could just put these two scripts side by side and scroll through them line by line.
My workaround is to open the other script in a new window then faff about trying to clumsily resize and rearrange them so they line up as best as possible. Also, with Sierra now defaulting to making Command-N behave like Command-T, there’s an extra step involved even in doing that (i.e., tearing the tab off to make a new window).**
I appreciate this is probably too big to make it into an SD6 maintenance update, but I really hope it’s high on the list of things for SD7.
**Aside: I don’t know whether it’s a good thing or not, but in Sierra SD ends up with two tab bars, as well as the possibility of multiple windows (each with all their own Sierra tabs and SD6 tabs inside them. Looks messy and confusing to me, but then Apple have really lost the plot with regards to UI design in recent years IMO anyway).
I have a couple of scripts that I used for Script Debugger 5 that I hadn’t got around to updating for version 6 – turns out they don’t need any changes. And you can change from BBEdit to TextWrangler. Here’s the first one:
use AppleScript version "2.4" -- Yosemite (10.10) or later
use scripting additions
try
tell application "Script Debugger"
set script2 to (source text of document 2) as text
set script1 to (source text of document 1) as text
end tell
on error -- not two scripts open
beep
end try
tell application "BBEdit"
make new text window with properties {contents:script2}
make new text window with properties {contents:script1}
set theDiff to compare text window 1 against text window 2 options {case sensitive:true, ignore leading spaces:true, ignore trailing spaces:true, ignore extra spaces:false}
beep
set foundDiff to differences found of theDiff
end tell
if foundDiff is false then
tell application "BBEdit"
set theReason to reason for no differences of theDiff
close text window 1 saving no
close text window 1 saving no
end tell
tell application "Script Debugger"
activate
with timeout of 100000 seconds
display dialog "No differences found. (" & theReason & ")" buttons "OK" default button 1
end timeout
end tell
end if
And the other just uses selection instead of source text.
What I meant was that SD hasn’t made any changes for Sierra yet. Apple’s suggesting apps that already support tabs can just turn off the new stuff, but our focus has really been on getting 6.0.1 out.
Right, fair do’s. I wasn’t suggesting you’d have made changes for Sierra. I haven’t done with my own apps and won’t till it’s nearer GM.
I’ve already got a short list of SD-things that I’ve found in Sierra that will need to be looked at, but I hadn’t intended to bother you with them until you release an official Sierra-supported release and I could see what hadn’t been addressed.
tell application "Script Debugger"
tell front script window
set b to its bounds
tell its current document
set f to its source text
end tell
end tell
set b's item 1 to (b's item 1) + 700
set b's item 3 to (b's item 3) + 700
set w to make new document
set w's source text to f
tell w to compile
tell w's script window
set its bounds to b
end tell
end tell
It works, but it’s bit crude. The horizontal offset is pure guesswork. Is there any way to get the width of the text view that contains the script so that I can accurately position the new window (NB: this won’t work in Sierra for reasons mentioned above).
OK, should anyone else…wonder why I’m wanting to do this instead of just using the split pane: this allows me to now duplicate a script, and experiment in the mirror version without having the changes affect the original. When I’m done experimenting, I can now visually get an eyeball on the diffs and port any changes back.
I can also, thanks to Shane’s script above, get the diffs actually printed out. I’ll probably mess around some more to incorporate that as an option in my script which I’m running out of FastScripts…maybe I’ll even use a fancy Dialog Toolkit alert with it…
tell application "Script Debugger"
tell front script window
set mb to its bounds
set its bounds to {50, 50, (mb's item 3) - (mb's item 1), (mb's item 4) - (mb's item 2)}
set b to its bounds
set tw to its tab width
tell its current document
set f to its source text
end tell
end tell
set newWindowXPos to (b's item 3) - tw
set newFrameWidth to (newWindowXPos - (b's item 1)) + (b's item 3)
set b's item 1 to newWindowXPos
set b's item 3 to newFrameWidth
set w to make new document
tell w's script window
set its bounds to b
set its tab width to tw
end tell
set w's source text to f
tell w to compile
end tell
Just for extra giggles, if you put these into El Capitan’s Full Screen ‘split screen’ mode, you get an almost Xcode like effect (alas, you’ll have to imagine the graphical difference engine… )
While it may seem like a simple change, this actually represents a massive alternation of Script Debugger’s document/window model. Like most document-based applications, each tab displays a single document. What you are proposing means that a tab must display multiple documents. This is in contrast to an application like Xcode whose main document is a project and source files are items within the porject.
For Script Debugger, this kind of change introduces many UI challenges. For instance, how do you indicate the document you want to show next to another document. When you go to close the window, are you closing both documents or just one. It goes on and on.
However, I think if we are to properly address the idea of AppleScript libraries we may have to move to a project-based model where you create a script project, and associate various source files (main script, libraries, etc) with it. Then, we can use many of the navigation techniques on show in Xcode. This also gives us the opportunity to introduce a build system and other project-level amenities. On the downside, this kind of change makes the Script Debugger UI just that much more complex and we already have a problem with approachability. This would also break Script Editor interoperability which is something I’ve tried to maintain through the years.
When I need to “diff” two similar scripts, which I do almost daily, I go for the powerful tool “FileMerge” that comes free with Xcode. It uses numbered, color-coded highlighting to show the differences. The two scripts are kept in sync through an excellent scrolling mechanism. Here’s an idea of what it looks like:
There are only two caveats. First, you must resave the scripts as text. That one is easy for me, since I store all my AS source code in text files. Second, be sure that both files use the same line endings, as those are annoying when highlighted.
A slight disappointment is that the familiar AS syntax formatting is absent. Despite that, FileMerge provides such a useful view of differences between the two scripts, that I’m okay with the generic font.
Hmmm, in that case I might withdraw my feature request! I think that may create more problems than it would solve. Xcode is a different story and the project model makes sense because there’s always multiple files in even the simplest project, but the majority of scripts (at least that I write) are never going to need that overhead.
This reminds me of something I’ve always wanted (always meaning since I first started using tabbed windows).
I think it would be cool to be able to have more than one tab visible at a time. I could see this used in a text editor; a browser; or a script editor.
)
