All Text command line like input as an Option

[MewR4D]

Paper logging for me is great because I can write down multiple times the call sing I hear and finally pic the right version. After that usually RST and a Number are exchanged. This Informations are going out and coming in on paper I Tag my Notes with “i /in” and “o/out”. An input could look like this. DO8 DO8A DO8E DO8EW 59i 025i 59o o001 Representing I heard DO8EW recived 59 and Number 025 I reported a 59 with Number 001.

[vk6flab]

Nice to hear from you and thank you for the first issue. I've marked it as a feature request and will use it to track progress towards implementation.

Implementing it isn't likely to be an issue, but functionality is, as in, how would this actually work?

The reason I'm asking is that most of the purpose of a contest logger is to show what the next exchange is for the operator and to validate that a log entry is allowed with the rules for that contest.

Please don't read this as a dismissal of your idea, it's not. I would like to understand how you'd like this to work, how it fits and what the user experience is. Again, writing the code is not the difficult part, it's understanding how it should work.

[flwyd]

Here's how I've imagined something like this would work:

• One set of fields sets some defaults for all logs, e.g. station callsign, operator, mode, band, frequency, TX power, QSO date, etc. When contesting, set your contest ID and exchange here. When doing a special event like POTA or SOTA, set your own reference(s) (MY_SIG_INFO plus MY_POTA_REF/MY_SOTA_REF in ADIF).
• For logging, there's a free-form text field and a parser. This free-form field allows entry of a couple fields, in any order: contacted callsign, frequency, time, RST sent, RST received, location, and contest/special event exchange. Anything that's not parsed into one of those fields is put into the NOTES field. (The user can enclose text in [] or () to force it into the notes field without being parsed, e.g. [see their QRZ page for info about their antenna setup].)
• When I'm hunting another station (assume an ARRL Section exchange), the line might start with 14.234 n4abc nc 59/ (radio is tuned to 14.234 Mhz, I heard their callsign as N4ABC and state as North Carolina, and I'm copying them as 59) while I'm waiting for them to respond to my call. When they respond with a 57 signal, I type 57. The whole line now looks like 14.234 n4abc nc 59/57, which would parse as (in order) FREQ, CALL, ARRL_SECT, RST_SENT, RST_RCVD and with TIME_ON taken from the system clock. When calling CQ, the frequency would be prefilled in the defaults section, so I would just need to enter n4abc 59/57 nc (note the different field order). If I was operating from a POTA park during the contest and someone called in with a park-to-park contact, I could write k0xyz 59/57 co k-1234 and it would record both ARRL_SECT and POTA_REF.
• When hitting Enter, the free-form field is parsed into a log record (with TIME_ON set if it's not present in the free-form) and displayed in a table with other logs. Additionally, the free-form text as entered is preserved as a field in the record so that there's context when reviewing the log for data entry errors that resulted in an incorrect parse, or to fill in details of a secondary contest, e.g. you're focused on the 7th Area QSO Party but work a station from the New England QSO Party and record that exchange as well.
• It would be cool if the free-form field was parsed as data is entered, so you can see individual fields in the tabular record fill in as you type, helping catch errors.
• Ideally there's a way to have multiple in-progress free-form fields. This is useful when working a pileup: call QRZ and hear someone start with "kilo seven", then hear someone else ending in "bravo charlie", another ending in "yankee zulu", and a third say "QRP". To keep track of the queue, you type (on separate rows) K7, BC, YZ, and then ask the QRP station to go ahead, logging their details in a fourth freeform line. Hitting enter on that line completes the log for the QRP station, you then move your cursor up to one of the other three partials and ask for them to call again. Partials might hang out for awhile; I sometimes write down all or part of a callsign and then don't hear a response due to band fading, then call for them again a few minutes later and their response gets through.

I think that parsing this data would be reasonably straightforward because the fields match different patterns. Split on whitespace, then test each "word" against a set of regex patterns or lookup tables. If it matches \d+.\d+ it's a frequency. If it matches [a-z]+[0-9]+[a-z]+(/\w+)? it's a callsign. (Actual callsign regex is a little more complex, since some countries have numbers in their prefix, etc.) If it matches \d{2,3}/\d{2,3} it's an RST sent/received; if it's \d{2,3}/ it's just RST sent, if it's /\d{2,3} it's just RST received (this allows typing things as they're heard over the air: "Kilo seven station go again" / "This is K7XYZ you're 59 in Oregon" / "K7XYZ thanks for 59 Oregon, you're 55 Colorado" --> K7XYZ /59 OR 55/. If it matches \d{2}:\d{2} it's the time on (useful for entering paper logs). If it matches \w+-{4,5} it's a POTA reference. [a-z]{2}[0-9]{2}([a-z]{2}([0-9]{2})?)? is a Maidenhead grid square. Contest exchange would need a little configuration, but there are a couple common options including standalone integer (serial number or CQWW zone or station power) and a string matching an entry in a list (ARRL section, county abbreviation for a QSO party). Since the full text of the free-form field is stored, if the exchange can't be identified (e.g. someone gives you their country because they don't know their CQWW zone) you can correct the details later.

[vk6flab]

My thinking about this is currently that a "CLI" plug-in would provide the basic functionality that a "POTA" or "SOTA" plug-in could enhance, especially considering Issue #20 where the suggestion is to provide extra "lookup" data.

[flwyd]

I would shy away from using a plugin architecture for parsing this field. There are a lot of variations a person could type in, so robust unit testing to ensure minimal surprises is valuable. It may make sense to let users select and deselect a set of fields the free-form box will look for, but I recommend keeping the set of parsers "in the core code" to make development easier to understand. For what it's worth, IOTA, POTA, SOTA, and WWFF all have different string formats which are easy to distinguish from each other. FISTS, SKCC, and Ten-Ten member numbers are just integers, so if free-form support is desired then a microsyntax like SK#123 and TT#456 might be useful.

I think of things like POTA detail lookup as orthogonal to the free-form parsing. The lookup would be tied to the structured field; once the free-form parser populates the POTA_REF field, a POTA listener could display the park details. I think a plugin architecture for that functionality may be warranted, since the chance for weird interactions between plugins in such a case is reduced.

[NoseyNick]

I do quite like the basic idea here - just type the stuff into a freeform field and have it break out. I'd extend further by saying if I've NOT typed a frequency, take one from hamlib (if available) or from the most recent QSO (if recent enough). Also highlight mandatory fields that haven't yet been typed.

Obvious problem would be if multiple pattern-matches match. Crappy examples:

• Was 14.234 a freq, or a partial LatLon?
• Was ONS part of a callsign or a Field Day section?
• Was 599 an RST, or a serial number?

Here some combination of heuristics (599 looks MOST LIKELY to be an RST but 123 looks more likely to be a serial number)... and "what we have already filled" may help?