What I’d like to do, if possible, is develop a number of switch cases that capture the majority of popular web sites that offer code snippets.
It would be great that as we (or the user of this macro) identify more cases of popular sites, we can easily add to the JS cases.
Does this make sense?
For the cases where extend-select works, and all that needs to change is the XPATH you could use the pattern of this macro:
to place the XPath which matches a particular site or set of sites in a KM variable, and execute a standard function in the relevant browser, with only the XPath changing.
I think you'd have to do a lookup on the url of the site you were visiting to see whether it kept code on a known XPATH, or was a member of a groups of sites whose code section were on a particular path.
Thanks. I think we're getting closer. 
But I would like to avoid tracking on an URL basis, unless there is no other choice. IOW, I'd like to examine the structure of the current page, and determine if it fits one of a number of "common" setups for displaying code snippets.
I'm sure there will be some sites that will never fit, but hopefully those are in the minority of sites.
So, what do you think? Can we do something like this?
Alas no : - )
Page structure analysis and automatic identification of code would be a very big project.
Another approach, assuming that you have selected (or are hovering over) a node in the code that interests you, would simply be to cycle through a list of XPATHs, reaping a harvest if a hit is found, and reporting [perplexity|novelty] if no harvest is forthcoming.
If I understand you, that is what I was talking about.
If the user selects a word at the top of the code block, than can’t you look at the containers immediately above it, and determine if they fit one of our cases?
Hey JM,
No, I'm using Rob's JavaScript code. But all can be done in one fell swoop with an AppleScript without resorting to driving the UI. It's faster and less prone to error.
-Chris
Thanks, but it's working really well the way it is in the macro. I'm not seeing any performance issues -- it's quite fast.
For the moment, I think keeping the actions separate gives us more flexibility, easier to change, and easier for other users to change. IMO, it best for non-script users to stay out of the script code, so that's why I like stuff like the output script header to be KM var. Easier to see and change, and no danger of screwing up code.
Here's a great example. If you're running Mavericks or earlier, then the macro needs to open AppleScript Editor. Whereas with Yosemite and later it needs to open Script Editor.
It has been kindly pointed out to me that this approach is not working with Safari at the moment.
The horse seems to fall at the starting gate, with window.getSelection()
There is a workaround, but unfortunately it's name is Chrome ...
(or Firefox, very new and snappy now, and all re-written in Rust, but not supported by the power and convenience of a Keyboard Maestro action)
(Not sure if Apple made some kind of security decision, or if someone was just sleepy one afternoon. It doesn't seem to be specific to the rights of code introduced from outside, in the manner of a KM Action - window.getSelection now pretends to work but really just returns a blank sheet even from Safari's own JS Console.
The better news is that it looks fixed in Safari Technology Preview
No idea what that means over the next year for the consumer Safari, or for Keyboard Maestro's Execute JS in Safari action.
JM found a method that works with Safari 11.0.1 (12604.3.5.1.1).
Get Selected Discourse Code Block on Web Page & Open in Editor
I've tested it out, and it works well.
-Chris
