Get Line From List

[tiffle]

This purpose of this subroutine is to extract a specific line from a list of items.

So if you had a list of items e.g.

Item 1
Item 2
Item 3
Item 4

and you ran this subroutine asking for line 2, the subroutine would return the value

Item 2

Since it uses AppleScript at its heart, you can get the last item in the list by specifying -1; the next to last by specifying -2; and so on.

By asking for line 0, the subroutine will return the count of the number of lines in the list.

Here is the subroutine:

[SUB] Get Line From List.kmmacros (4.9 KB)

Click to see macro

To help you become familiar with its operation, here is a macro to test the subroutine. It's very simple so you should have little trouble working out how it might fit into your own use-cases.

Test [SUB] Get Line From List.kmmacros (5.8 KB)

Click to see macro

As usual this has been tested but it comes with no warrantees nor guarantees.

[_jims]

Hi @tiffle. Thanks for sharing. I didn't know that AppleScript would return values from the end when a negative integer is specified. Very cool!

I've adapted your AppleScript and created a new example in MACRO: Text Transformation EXAMPLES - Macro Library.

[tiffle]

@_jims

I didn't know that AppleScript would return values from the end...

That was a revelation to me, too. I really have a lot of trouble with AppleScript

[Nige_S]

@tiffle

This purpose of this subroutine is to extract a specific line from a list of items.

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?

[tiffle]

@Nige_S

what's the advantage

You decide that to best suit your use-case.

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!)

@Nige_S

the cost of spinning up an AS process and passing variables

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

[Nige_S]

@tiffle

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.

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):

[SUB] Native Get Line From List.kmmacros (7.4 KB)

Macro Image

...which works with your test macro above -- simply change the test macro's target subroutine.

I'll try and do some speed testing later...

(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
Native: 1001.967
AppleScript: 75299.023
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!

[tiffle]

@Nige_S

Sorry @tiffle -- I meant "what's the advantage to writing the subroutine…

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!

[Nige_S]

@tiffle

BTW - I love the way you ensure the delimiter is unique although I’m not sure of the benefit of displaying it!

Realised I'd left that in from debugging, but didn't get round to posting the sanitised version. Luckily I removed all the sweary dialogs!

[ccstone]

Hey Folks,

Thought I'd take a crack at this with Perl just for fun – it's faster than AppleScript, but the KM array method looks to be a bit faster yet.

• Special commands (without the quotes);
  • Integers give the specific line.
  • 'length' gives the number of lines in the array.
  • '$' gives the last item in the array.
     
• Supports negative indexing (without the quotes).
  • '-1' will give the 2nd to last line.
  • '-2' will give the 3nd to last line.
  • Etc.

-Chris

---

Return a Given Line from a Linefeed Separated Array (List) of LInes v1.00.kmmacros (12 KB)

Macro Image