Yeah I knew that workaround, but since I use TotalTerminal, in the end I have to merge all new windows, and for merge there’s no applescript command, so again I would have to resort to GUI scripting.
I’m not sure if I know what you mean, but there is a document at developer.apple.com, named “Debugging Magic”, it shows you how to raise/lower the message level of an app, so you can get a clearer view in console as to what is going on. There are also some variables that can be set in terminal, so that output is logged into Console.app, when you run a script through the osascript command.
No, maybe not in that end, as to the detail level in the error messages. however, notching up the error level, as to when you have no clues as to why something fail, for instance without an error message, or maybe an error that states that an apple event timed out, it can prove useful to inspect any internal error messages.
I won’t speculate as to if it is a bug, or not, that you can’t make a new window with the make new window command, but I think we all can agree that the dictionary of Terminal lacks a comment for the make command, that states how new windows are intended to be made.
You make a new Finder Window for instance, and Finder windows aren’t based on documents either, so it hasn’t anything to do with the lack of the NSDocument class in the background of the window really.
tell application "Finder"
make new Finder window
end tell
If you look in Terminal’s scripting dictionary, you’ll see that for window it says it responds to close, print, save – no mention of make. Dictionaries can lie, and there’s no obligation to list what commands a class responds to – most don’t for window, for example. But when they do, it can be a hint that they’ve implemented it a bit differently. And the absence of make in that list might well suggest it’s not accidental.