Re-send exchange should respect contest specific settings

[dl1jbe]

After a qso gets logged you can re-send the exchange by pressing '_'.

At the moment it is hard-coded to send RST and last qso number. It should respect the the contest specific exchange settings instead.

[VictorDenisov]

I'm wondering if there is any work happening around this topic. S&P mode in general seems like second class citizen in tlf. Sending repeats in S&P mode requires invoking manual keying. I would like to tackle this issue and would appreciate any directions.

[zcsahok]

I'm not checking this one, maybe Tom does.

One question is what shall be actually re-sent?
My typical config looks like

F3=@ ++5NN-- -#+
S&P_TU_MSG=TU ++5NN-- -#+

When asked for NR I send just the serial part, so it would be for me "-#+" only. An option could be to send the last word of F3/S&P_TU. Other users could have other preferences (like sending 5NN also). Or the exchange could be more complex, composed of multiple words.
Re-sending shall rely on a previously sent message as in a networked setup (that is alas broken now) QSO number n-1 could belong to another node.
Just brainstorming...

[VictorDenisov]

Yeah. You are exactly describing my challenges with S&P mode. Once you press enter in S&P mode you are moved to the next QSO and you can't use macro keys because they will be using serials from new QSO not from the previous one. Underscore can either send S&P_TU_MSG or F3 message. It would be ideal to fix the whole user experience around repeats in S&P, but underscore is something that I would like to have first.
How do other loggers do it? Tlf is my first real contest logger. As a result I have no idea how other renowned loggers implement S&P mode.

[dl1jbe]

From your discussion let me summarize the following needs:

• Use the last QSO nr sent instead of the actual one (At the moment '_' uses actual 'qsonum -1', we should keep a copy of last sent number for that).
• Have the ability for a custom reply. I fear using 'only the last word' or similar will fall short. Best maybe a new keyword RESEND_MSG (or similar) with an useful callback if not set.

[zcsahok]

One more point:

• if callsign field is empty then F3 shall also use the stored previous QSO number. (i.e. make a "full" resend instead of the potentially shorter '_')

[VictorDenisov]

I'm wondering if in S&P mode as long as the call sign field is empty we need to make all macro expansions with the previous QSO values. Some people like to put parts of qso exchange in alternative macros. This approach would allow for their macros to be useful without any custom extra variables.
What do you think?

[dl1jbe]

Sounds reasonable. At the moment I am not sure if it would always be good, so let us think a little bit about it.

[VictorDenisov]

As I was exploring code around this change I ran into this https://github.com/Tlf/tlf/blob/master/src/sendbuf.c#L178
Could you please help me understand the purpose of these variables:

• hiscall_sent
• sentcall
  What is early start?
  Why are first and subsequent @ signs are handled differently?

[zcsahok]

early_started belongs to the auto-send feature, see autosend() in callinput.c.
Auto-send is controlled by ":CHAr" command, it always starts disabled.
The use case is (assuming it was set to 3 chars)

• we want to work K1ABC
• as soon as we type the first 3 chars (K1A) keying starts
• we finish the call input (BC) and press Enter
• now K1A is already queued (even partially sent), so the initial @ in F3 shall only be expanded to "BC". Any eventual further @ references have to be replaced with the full call as usual.

This of course assumes that F3 does start with @, and not with say "GE @". But auto-send is anyway meant for contests only.

Re sending previous serial on empty call field in S&P: as an extra advantage one could configure a rarely used F-key (e.g. F4) for a customized re-send (like slower and twice) in addition to '_'.

[zcsahok]

Issue solved by #361