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