Hello Ervin, Tomasz,
The problem I find is that after having cruised up and down a band several times, I basically "forget" the location of worked stations on the band. So, I will hear a station I can work, and then wait for the station to ID. With some operators, this can take awhile ;-) So, if somehow I can see that in the past N minutes (N can be defined as it is now) I worked AB1CD on 14.240 as I approach 14.240 then I'll know not to wait too long as I likely worked him already.
My thought initially on the Python add-on, was a simple gui or ncurses display that gave the current frequency and mapped worked calls before and after it. I figured Python, because that's mostly what I use these days (unless working on the hardware level with a need for speed) and Python makes it sooo much easier to deal with parsing of strings. I had once quickly tried to run tlf using rigctld and the generic rig def (2?) but wasn't able to get that working and haven't gone back to it. I'm thinking this would be the cleanest way to add secondary codes accessing the rig information.
The ideas pointed to by Fred would also do most if not all of this, I think.
Also on the Python front, I have written a number of scripts (using Ipython) to do post-contest scoring for some unsupported contests that are important to me, like the RAC Canada Day and Winter Contests, NAQP, IARU, and now IOTA.
As for N1MM logger ... I haven't actually used it since 2004. I could use it here at home, but I can't justify it while on NA-008 as I would have to dedicate a pc to it. So, it's tlf for the win!