"lineAtOffset"?

[Ben Rubinstein]

On 29/10/2015 15:47, Richard Gaskin wrote:

> Like "lineOffset", "lineAtOffset" would take the same arguments and
> operate similarly, but rather than returning the number of the matching
> line it would return the text of that line.
 >
 > Questions for you folks:
 >
 > 1. Is this as useful as I think it might be?
 >
 > 2....
 >
 > 3. Is this worth submitting to the request queue?

My £0.02 for what they're worth:

Of course this could be useful occasionally - but I'm not sure the value 
outweighs the cost - not so much the cost of implementation, as the cost of 
adding more words to the language.

In code, it saves a single line.

In efficiency, I grant there's a cost; but it seems to me that if the cost was 
high (i.e. you're searching in a really long piece of text, and you're doing 
it a very large number of times) then you could choose to mitigate that cost 
in various ways (e.g. doing split to get an array indexed by line number, or 
(depending on your situation) doing "offset" instead of line offset, and then 
taking a chunk starting sufficiently before the found character position and 
doing "lineoffset" on that...

But mainly, I'm agin this proposal because, if there were to be changes to the 
offset suite of functions, I'd much rather that effort was spent on making 
them work backwards. It's fast and simple to do offset, lineoffset, etc to 
find the first occurrence of a fragment, or to walk 'forward' through the 
occurrences of a fragment; but it's neither fast nor simple to get the last 
occurrence, or to walk backwards through the occurences.

There's an inconsistency here - LC makes it as easy to ask for the last item, 
or the third line from the end, as it does the first item, or the third line. 
  But the *offset functions only work in one direction.

Also note that implementing the backwards offsets needn't (I think) require 
adding any new keywords, because we can use the skip parameter with a negative 
number.

Sorry to hijack your thread!

Ben