Horizontal split view: load other script


(Phil Stokes) #1

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).


(Shane Stanley) #2

Have you considered writing a script to do the faffing? Not what you’re asking for, but perhaps a start.

And don’t take much notice of what’s happening in Sierra at this stage.


(Phil Stokes) #3

Haha. Fair enough. Will do. I was looking for something to do this evening, anyway… :grinning:

EDITED TO ADD:

Well, they announced at WWDC that tabs-not-windows would be the default behaviour for all apps, so I don’t think that’ll change as the beta develops.


(Shane Stanley) #4

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.


(Shane Stanley) #5

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.


(Phil Stokes) #6

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.


(Shane Stanley) #7

Feel free to send them along any time.


(Phil Stokes) #8

So I came up with this:

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).


(Shane Stanley) #9

You have the bounds of the window, and tab width will give you the width of any pane that’s showing.


(Phil Stokes) #10

Aha. Brilliant. That’s what I was looking for. Ta.


(Phil Stokes) #11

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… :slight_smile:


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

(Phil Stokes) #12

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… :slight_smile:)


(Mark Alldritt) #13

Noted.

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.


(Stan Cleveland) #14

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.

Stan C.


(Phil Stokes) #15

Thanks Stan

I hadn’t thought of utilising FileMerge. That’s another useful workaround. :+1:


(Phil Stokes) #16

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.


(Ed Stockly) #17

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.