Playing Devil's advocate -- what's the advantages to this over a native "search and replace line endings with a unique delimiter, then use KM's array notation" approach?
I can think of a couple -- is your unique delimiter actually unique, and AppleScript is liberal about format in its "paragraph" determination -- but do these outweigh the cost of spinning up an AS process and passing variables?
For the people who use my macros the biggest advantage is simplicity: drop the execute subroutine action in the macro being built and it tells you what's required and what's returned and doesn't do anything unpredictable under error conditions. That's a lot quicker and simpler to use than converting a list to a different format plus using KM's unwieldy array-with-custom-delimiter notation afterwards. (Remember my users would have to consult KM's wiki to do those things - actually, so would I probably!)
is not significant in my use-case. It might be different for others.
PS: don't let me tempt you back to the dark side - I can't stand it over here
Sorry @tiffle -- I meant "what's the advantage to writing the subroutine using AS rather than a KM-native approach"? Here's a variant I've hacked up (which also takes care of the "unique string" and "both newlines and returns" problems):
...which works with your test macro above -- simply change the test macro's target subroutine.
I'll try and do some speed testing later...
Tested with 100 repeats for each subroutine (including a compiled AS version), a random number being used for the line parameter on every repeat. Results were:
Time taken in milliseconds for 100 repeats
Compiled AS: 61944.118
It didn't make a difference if the original list was 9 or 99 lines, which is good news. And I fully agree with @tiffle that, for a user manually picking one line to extract, it doesn't matter that using AppleScript is 60-75 times slower. Nice to put some numbers on it, though!
Oh - I misunderstood what you were saying @Nige_S.
In this particular case, to a KM user the subroutine is a black box that takes inputs and produces an output so the actual implementation is hidden and - to the user - more or less uninteresting as long as it does what is expected. You’ve shown the advantage of avoiding the AppleScript implementation so if the user wants better performance the native KM would seem to be the one to choose. To be honest, given the choice I’d always use your version
BTW - I love the way you ensure the delimiter is unique although I’m not sure of the benefit of displaying it!