-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enhance _Escape_ to stop message TX on first press #344
Comments
Fwiw there's already a note in the manpage about that:
(4ffdce8 by you) I think changing that would make sense, the current behavior is both overzelaous (stop and clear) and too timid (3 ESC needed to clear everything). Perhaps being smarter and still requiring less ESC hits is possible. |
I know the man page does not match the behavior. :) If I recall, it was discussed on the mailing list but was never implemented, or at least HEAD is not matching the man page. I wanted to get this on the list of issues for some additional discussion. I recall from my days of using CT that Escape simply stopped the message TX. Nothing more. To clear any entered fields required using F11 or Ctrl-W. Of course, those keys were chosen long before windowing GUIs came into popular use. N1MM+ also uses Ctrl-W and Alt-W to 'wipe' the entry fields. Likewise, Escape only stops the TX and it also stops the message repeat. I don't know if we want to go in that direction. I do like that Escape can progressively clear the entry fields and I would be in favor of adding Ctrl-W as a "wipe all fields" keystroke (Alt-W is already assigned to set CW keying weight) that would allow for clearing all entry fields in one go. |
Just checked here with Tlf-1.4.1 and actual github version.
Works as documented in the man page (at least in CW, did not test voice
keying yet).
The behavior regards 3 times pressing ESC can be changed, any
suggestions for a better solution?
Christoph, can you confirm the problem?
…--
"Do what is needful!"
Ursula LeGuin: Earthsea
--
|
I have to correct myself. The 3 times ESC works as expected as long as you do NOT use the F1..F12 messages but only the Enter-Send-Message mechanism. (To be honest it was also implemented with that scenario in mind.) Stopping a running message results in the above described behavior. That really needs a fix. |
Tom, I do use ESM in Log mode. Sometimes the other station will decide to TX out of sequence or thinks I did not copy and starts to send their exchange and my message had just started (I use QSK on the K3 so I know). I had more than once that even with ESM the fields were cleared as above. |
TLF is generally not aware whether a transmission is ongoing except two special CW use cases (auto CQ and auto send). So we have to keep the "multi-Esc" logic but fix it a way something like
I see no problem with pressing Esc multiple times as it involves just minimal hand movement. |
Nate, In CW or SSB? Never observed similar here. For CW in Run mode I can see only two possible problems:
In S_P the same problems exist. But here the needed exchange from my side is missing. |
My quick test this morning is that I observed the same behavior in each. |
That is only true for CW. In SSB you can check with 'is_vk_finished()'. May I add some minor additions which reflects the current logic and may help in understanding.
In case exchange field is empty it saves one key press.
|
The problem behind lies in the fact that we get no feedback from the CW keyer if the message is still running.
That would work as long as Tlf has the real sending speed (so no manual setting of it). It would allows us to fix at least the problem with pressing ESC while a message is running. |
By this I guess you mean no setting of an outboard keyer to a speed different than TLF? I have a K1EL compatible keyer that has a speed knob and it was acting a bit odd when setting the speed with it as opposed through TLF. I wound up matching them and then set it via TLF as Pg-Up/Dwn is much faster.
Perhaps this is why other loggers have stopping the TX as the only function for Escape? As TLF is heavily influenced by Tr Log, I thought I could find a keystroke summary for it. Skimming the manual I did find that Escape stops the message TX but I did not find what clears the fields. It is not Ctrl-W which does something much different. |
That is what I mean. Will be away the next days for local field day but can try to implement the above in next week. |
(same here, op of HA5N/P) |
Sorry, but again, I have a bad feeling that calculating (that is, purely guessing) -- is much more complicated as it first sounds.
Fortunately, both K1EL (the original at least) as well as CWDAEMON support digital (character) echo. I suspect that the primary purpose may have been to support "on the fly" correcting the callsign, with no superfluous repetition. For example, correcting HA5SI to HA5SE, no need to repeat the corrected call at the end of the report, as long as the keyboard correction took place whlie within sending HA5S. A probably more important feature, although I have never used, to automatically start sending in "RUN" (CQ) mode after typing in 3 (or whatever) characters. In this mode, while receiving HA5SE in head, one would only type HA in advance, and first type 5 after receiving the complete call to start sending, and then adding the missing SE as kind of correction while already sending. In order to let the logging program to know whether it is a real correction on-the-air (or not), that echo can be used. Instead of estimating, I am afraid that this echo could be the only reliable possibility to programmatically follow the CW flow. After all, IMHO that overloading the ESC key should be avoided altogether (or at least allowed to disable as an option). After long hours contesting, with many different logger programs, I quite often have found myself repeatedly and excitedly pressing ESC as long as it have not yet reached effect... My personal preference would be "ESC = break sending" unconditionally, with no key overloading -- at least as an option, respecting backward compatibility... |
I agree with ha5se's final paragraph. I think the overloading of ESC has led us to this point. Yes, there is ease in having ESC clear fields but I've been bit too many times by "repeatedly and excitedly pressing ESC as long as it have not yet reached effect..." and losing all the info. I will state that was never a problem with CT or N1MM when I used them. I know there are almost too many configuration key words already, but it's likely there are users who want the present behavior and others like me and ha5se who do not. Perhaps in order to avoid changing the default character of TLF a key word like ESCAPE_STOPS_TX_ONLY could be employed that when it is present in |
From HA5SE
That is not quite true. The min problem for cwdaemon, especially for higher speed, is the jitter for start and stop of the keying element. The jitter normally do not accumulate, so the resulting speed is not changed.
May be, together with the ESCAPE_STOP_TX_ONLY keyword, the best solution. Will prepare a Pull request shortly. From N0NB
Ok. Will look if CTRL-W can be used. |
I'd still prefer the current multi-ESC functionality, of course without the first press wiping the input field. |
@dl1jbe, thanks -- however, my experience, along with my understanding, still very much differs... for i in {1..40}; do printf 'PARIS ' ; done | time -f '%E elapsed' /usr/bin/cw --noecho -s p -w 40 Per definition, should be exactly 1:00.00. |
How accurate is |
Well... First I would suggest you experiment on your own environment ;) .... |
What package contains |
My first run of your command on this Lenovo M73 (i5-4570 CPU @ 3.20GHz (quad core)) gives me:
I halved the speed, still consistent:
Watching the elapsed time with a wall clock matches the |
I am on your side here. But as i tried to explain above, it will request to know if cwdaemon (or whatever used) is still sending. @ha5se For ten runs of your script the execution time varies in the range of 0.1 s. So we see that the timing is not correct (to slow) but it is not related to load and therefore scheduling. Where the wrong timing comes from is not easy to tell, but keep in mind, that the program needs to produce dot length of 50 ms. Granularity of the timers may be one factor for it. If time permits I will have a look into the cwlib code from unixcw (which is used by 'cw' and also 'cwdaemon'). The would bring us to the following concept:
|
thank you for the improved concept. This seems now much more flexible. Another test. A quick glance revealed that cwdaemon utilizes nanosleep. In the word PARIS, there are 14 signals and 14 gaps, implying 28 sleeps. For the previous test of 40 WPM, this means 40x28 = 1120 sleeps in 60sec. In order to exclude any granularity problems from this test, now I use the very near rounding to 1200 sleeps, 60/1200 = 0.05 sec each.
This gave me 1:00.43 elapsed while not yet doing anything useful... I think that estimating too short may be the disturbing one because I can hear my keyer still sending while the ESC function may have changed to wiping. On the other side, estimating much longer than needed would make much less confusion, because I do not think that it would be important to wipe immediately after sending finished -- and anyway, in worst case, ESC should be pressed few more times to really wipe. Going on along this line, keeping your concept, I would suggest another option instead of simply disabling, say something like ESC_WIPES_FIELDS_AFTER_SEC= to allow maximal flexibility in personal preferences. This many seconds could be added to the estimated length. Choosing a huge value would practically disable this functionality. |
Maybe you forgot the trailing space character. That should make 30 in the end.
So 1200 is indeed the right number.
That tells us, that timing for 50ms intervals should be correct. If it works for say 22 wpm the same may be different, but is not our point here. It seems cwdaemon the timing a little bit odd.
I think we should give the calculated timing a +10% addon, that would make 1s for any 10s message. Let us try it as a start and we can adapt aftre the first real tests.
Sounds interesting. Let us keep it on record. But I would first try to implement the base mechanism. |
If the Ctrl-W idea to clear fields is implemented, please also add Ctrl-U which is part of the standard unix keybindings for "clear entire line". |
There is a first version at https://github.com/dl1jbe/tlf/tree/change_ESC_handling which allows to command ESCAPE usage only to stop tx (ESC_STOP_TX_ONLY) and which supports ctrl-W to wipe out comment or call input field. Ctrl-u suggested by @df7cb is to be done. It could use some thorough tests.Please give feedback about success or failure. |
Wouldn't it be better to hold Ctrl-U in reserve for a future feature? The only sequence I see in the man page that implements any common shell command in a similar way is Ctrl-Z to suspend TLF. Even Ctrl-C is trapped and ignored. Other shell sequences (assuming one is using Emacs bindings and not vi bindings) that have their own meaning in TLF are Alt-A, Alt-B, Alt-E, Ctrl-K, and so on. Also, if one were to be pedantic about it, Ctrl-U should only clear everything to the left of the cursor! I say Ctrl-W is sufficient as it matches other popular logging programs which is area TLF exists, not shell commands. |
After building and making some quick tests in CW and SSB modes with the However, Ctrl-W does not currently work the way I recall it working from CT or N1MM which is that it clears all fields immediately when pressed. As it works now it only clears the field the cursor is in so the cursor must be moved to the other field to clear both fields. In this way it sort of mimics the shell behavior of Ctrl-W. In the domain of contest loggers Ctrl-W clears all fields at once which is probably the expected behavior. |
That was a clear misunderstanding from my side. I got the impression that Ctrl-W should wipe out only one field and Ctrl-U should wipe the whole line. If we use Ctrl-W to wipe out the whole QSO than I see no point for an addtional Ctrl-U at all. |
I guess the question becomes which behavior of Ctrl-W should be followed, that of TR-LOG or CT/N1MM. I will note that not all three work exactly the same. The way TR-LOG clears the fields is described at the bottom of page 75 through most of 76 in its manual: https://www.kkn.net/~trlog/TRmanual.pdf It describes Ctrl-W as only clearing the current field. But when one looks at the table on page 76 it is clear TLF departed from full TR-LOG compatibility long ago! Looking at the N1MM+ manual, Ctrl-W and Alt-W are synonymous but have the following properties: Alt+W or Ctrl+W (Alt+W = Ctrl+W)
As N1MM+ is a program for MS Windows only, can have multiple input GUI windows on the screen. TLF uses Alt-W to set CW weight so that should remain unchanged. Okay, now it gets more confusing! I found the help file for CT version 10 and it states Ctrl-W wipes a field (CT had a field for the callsign and then a field for each exchange element) and F11 or Alt-F8 wipes an entry! In TLF F11 is a message key and Alt-F8 is caught by GNOME (and probably other window managers) as a resize window command so that is probably out. CT and TR-LOG agree that Ctrl-W wipes the field the cursor is in. N1MM+ extends this to wiping all fields in a window but also if all entries are empty restoring the previously wiped information. Let's pause and think about this for a bit. First, TLF clearly has its own set of keys that follow no other logger strictly. Therefore, I think we can do this in a way that is familiar but also useful for TLF. How about this as an idea:
Now, I know this puts a lot on your plate, Tom. I hope everyone can give their thoughts before you proceed much further. |
That Nate for digging in. It seems there is no common handling of the problem. Your suggestion
comes down in general as having an UNDO function for the last Ctrl-W and Ctrl-U. That should be doable with moderate effort. I try to do it on the weekend. |
Just updated the above mentioned branch ( https://github.com/dl1jbe/tlf/tree/change_ESC_handling ) according to the above discussion.
Please just test if that is working for you all or if there are further things to add. |
@N0NB Ping. |
Sorry, I guess I had that one fall through the cracks Three weeks ago was a particularly busy time so a lot of things got pushed to the side. Things have slowed and I can back to playing in a few days. |
Sorry for the delays, Tom. I've just built your branch and ran some quick tests. I think this is probably ready to merge. May as well since the bugs are only found when the program is used in battle! |
Ok, thanks for testing Nate. I will check the actual code tomorrow and prepare a first pull request. The second part with the better handling for ESC needs some more work, but it is a separate thing. |
Could this issue be closed? |
In Log mode, Pressing Escape while a message is being transmitted results in two actions happening--the TX is stopped and the field the cursor is in causes one of two things to happen. If the cursor is in the Call field, both the Call and Exchange fields are cleared (bad news when the objective is to just stop the TX). If the cursor is in the Exchange field then any entered text is erased and the cursor moved to the Call field.
In S&P mode if the cursor is in the Exchange field and there is text, Escape stops the TX and clears the text but keeps the cursor in the Exchange field. If the cursor is in the Call field the TX is stopped and all fields are cleared.
The actions appear to be the same whether the operating mode is CW or SSB.
Perhaps this is the desired action for Escape, or perhaps it mimics Tr Log (I don't know as I've never used Tr).
Ideally, I would like Escape to only stop the TX if a message is being sent and not clear any text on first press. However, if there is no message being sent, then if should clear the fields as it does now. If this is at odds with the expectations of others that I'd propose this to be a configurable option.
On a couple of occasions the past weekend I had to ask for repeats because when I only intended to stop the TX I also had at least one input field cleared.
The text was updated successfully, but these errors were encountered: