I am working on a macro to scrape weekly comic release lists at the Marvel Database wikia. The macro scrapes the data, formats it for my Excel spreadsheet and then pastes it into the spreadsheet from a KM named clipboard. All of that works just fine, except...
My spreadsheet starts with 2 columns that have to be filled in manually after the rows are added, so I leave them as tabs in the output from the macro. But it seems like Keyboard Maestro is eating those initial tabs on the first line of the output.
(I suppose I could just adjust the paste into Excel step so it starts from the 3rd column instead of the 1st, but now I'm mad about this and I'm determined to bend it to my will.)
If I run my macro and dump the output to a text window and then copy/paste into BBEdit, this is what I see:
You can see that the first line is missing tabs but subsequent lines aren't.
If I allow the macro to paste directly into Excel, same thing:
But!
If I user Safari's web inspector to run the javascript I use to scrape the webpage and build my result list, it comes out with those initial two tabs intact!
I am at a loss what could be causing this. Any ideas?
Addendum:
I just had the thought to try saving the results of the page scraping to a KM variable instead of a named clipboard and then just set the value of the correct cell in Excel to the value of the variable, thus bypassing the clipboard altogether.
Nope, same problem. So it's not just the clipboard, I guess. Does KM trim whitespace from the front of variables and clipboard contents?
I have to run to an appointment, but I've seen this before, and I wasn't using KM. I was convinced that the macOS GUI was not actually selecting the initial two tabs.
That's my only idea before I run off to my appointment.
Hmm, that might explain when I select the results in the text display window, but would it account for when the data flows through the clipboard without any GUI interaction?
But it's not just Excel. This also occurs if I dump the results to a text window and then copy/paste them into BBEdit, as shown in my first image.
And, in fact, if I bypass the clipboard altogether and use an AppleScript to paste the results directly into an Excel spreadsheet or—as I just tried—a BBEdit document, I get the exact same results.
Safari's web inspector is the only place I don't see the two initial tabs on the first line getting removed.
First of all, thank you. I've never noticed that option before. Turning it off did indeed solve my problem.
But second—and I realize this isn't your fault or responsibility so consider it more a general rant—why on earth would that setting be on by default?!? Trimming output should be something the macro developer should have to explicitly turn on if they want it, precisely because it can lead to unexpected results if they don't realize it is on. You should always get the results you expect (barring any bugs, of course) under the default settings and changes to your results such as trimming whitespace should be something you have to explicitly ask for.
Also, I see in the wiki that Trim Results is described on the page for Execute a Shell Script but not for Execute JavaScript for Automation. It's also not mentioned in the user manual. That's especially bad if it's the default setting.
Again, though, thanks for your help. Things are working correctly now.
Your comments about documentation seem very valid.
I'm not so sure about that. I've been programming in KM for many years, and only once did I ever need to include the whitespace. Obviously your situations are different from mine, but mine are valid cases too.
If we changed this behaviour in KM now, then many of my macros would break, and I'm sure most people would be in the same situation for many of their macros.
Oh, I'm not asking it to be changed; that ship has long since sailed and I realize I need to accommodate my habits to KM's reality. Me learning that I need to uncheck Trim Results is a heckuva lot easier than everyone else adjusting to the opposite. And I'm okay with that.
But really, actions that are destructive to the returned data should never be the default.
Fair point. But did you know there are other actions with "trim results" set on by default? Like "Execute Shell Script". You are getting me to wonder whether there should be a documentation page for the "trim results" flag which would list all the actions which use that flag. Or maybe better, the KM Editor search window should be able to search on the word "trim" like it can search for other words within the non-user fields of an action. Now there's an idea.
Because, as a general rule scripts include trailing white space that is not explicitly included in the script, and then things like conditions that say if result is "Whatever" would failed because of the unexpected white space. White space is traditionally ignored for most scripting systems, both on input and output.
Very rarely, the white space is important, which is why there is an option to turn this off, but it is certainly a very rare situation.
You must be referring to shell scripts. AFAIK AppleScripts; JXA scripts, or JavaScripts return only what the script outputs, unless there is an error. Or is this something caused by the Execute Script actions?
I still disagree that the default should be to automatically strip whitespace versus forcing the developer to make a conscious decision to turn that on, but your explanation does make sense for trailing spaces.
However, AFAIK scripts don't generally add leading whitespace, so if there is any leading whitespace present it is more than likely an intentional and meaningful part of the output and therefore IMO should not be stripped.
But then, I'm the type who, if leading or trailing whitespace is not desired, will strip it out before returning the output in the first place, so
