Grab spot nearest to current frequency

[zcsahok]

This fix addresses the issue that grab can lead to unexpected result, especially when the bandmap is full during a contest.
An example situation is as follows:

• on a full bandmap a rare station appears (say a VK)
• one grabs VK
• rig switches to another unrelated station containing VK in its callsign lower the band

By looking for a match closest to the current frequency such issues can be at least reduced.

[dl1jbe]

I see the problem with the first match (on lowest frequency), but why would be 'nearest frequency' better?

The problem seems not that we find the first of many VKs on the list, but that we accept ANY station with an VK inside.

So what if we would not just look for a match anywhere in the callsign but prefer spots which has the searchstring as start of call - first look for match with start of call and if nothing found search also inside the calls?

[dl1jbe]

I made PR #506 for easy comparison of both suggested changes for the spot lookup. (Man page still has to be adapted if choosen.)
Feel free to compare and choose which fits best.

[zcsahok]

I think there is no right logic for grab selection as it depends how one uses it.

Here is what I do:

1. scan the visible bandmap for a 2-4 char long unique substring identifying my target call
   so for OK1ABC I may enter ABC or OK1, or even K1A, depending on the other spots.
2. if grab selects my target, then all is fine
3. if not my target is selected, but another call on the visible bandmap, then it is my fault: the search string was not unique enough.
4. if a call out of the visible bandmap is selected, well, then I must blame TLF on this...

This PR just addresses case 4 above by moving the focus from the beginning of band to the current frequency, thus implicitly to the visible part of the bandmap.

The example given in the previous comment was just one possible scenario. Another one is wanting to grab say HB9ABC by entering HB9 (as it is the only HB9 station on my bandmap) and then selecting HB9XYZ at the beginning on the band (so case 4 again). Here #506 would also not improve the match.

The point is not the substring versus prefix search, but fixing the artificial bias towards the beginning of the band. This is no way perfect (as it simply can't be), but at least reduces unexpected results (the case 4).

[dl1jbe]

Now I see your point. I had overlooked scenario 4. PR#506 can't help here.

The failure in the original implementation is that we search the whole filtered spot list and not only the displayed ones. PR #507 fixes that. It can surely combined with further filtering - by distance, country precedence or other schemes.

[zcsahok]

Closing as it is covered by #507