Skip to content
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

Open
N0NB opened this issue Sep 1, 2022 · 38 comments
Open

Enhance _Escape_ to stop message TX on first press #344

N0NB opened this issue Sep 1, 2022 · 38 comments

Comments

@N0NB
Copy link
Member

N0NB commented Sep 1, 2022

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.

@df7cb
Copy link
Contributor

df7cb commented Sep 1, 2022

Fwiw there's already a note in the manpage about that:

       Escape Stop CW transmission, clears characters, returns to call input field, keyboard off (universal undo).
              Note:  Some  changes  are being considered to modify the behavior of Escape slightly.  The intent will be to have Escape
              only stop sending on first press and not clear any entered information.  It is planned that Escape will stop  the  play‐
              back of the voice keyer as well.

              As  an  example,  characters have been entered in both the call input and exchange fields, the cursor is in the exchange
              field, and the transmission of a CW message is in progress.

              The first press of Escape will stop the CW transmission and clear the exchange field and  position  the  cursor  to  the
              leftmost position of the exchange field.

              The second press of Escape will move the cursor to the right of the last character in the call input field.

              The third press of Escape will clear the call input field.

(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.

@N0NB
Copy link
Member Author

N0NB commented Sep 1, 2022

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.

@dl1jbe
Copy link
Member

dl1jbe commented Sep 1, 2022 via email

@dl1jbe
Copy link
Member

dl1jbe commented Sep 1, 2022

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.

@N0NB
Copy link
Member Author

N0NB commented Sep 1, 2022

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.

@zcsahok
Copy link
Member

zcsahok commented Sep 1, 2022

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

  • 1st Esc calls stoptx(). There is no visual feedback.
  • 2nd Esc clears current input field. If we are in the call input field then that's all.
  • 3rd Esc (in exchange field) switches back to the end of call input.
  • 4th Esc (now at call input) does the same as the 2nd: clears call input field.

I see no problem with pressing Esc multiple times as it involves just minimal hand movement.
Additionally the proposed "clear field" (Ctrl-W) key could also be added.

@dl1jbe
Copy link
Member

dl1jbe commented Sep 1, 2022

Nate, In CW or SSB? Never observed similar here.

For CW in Run mode I can see only two possible problems:

  • If exchange gets automatically filled in (CQWW or Recall_Mults) when pressing Enter in call input field the message starts, cursor advances to exchange field and that gets autofilled. Pressing ESC now stops CW and stays in exchange input (normally it would back to call input). Pressing Enter again will autofill the field.
  • If ESC is pressed after sending the final the QSO is logged but the final is only partially sent.

In S_P the same problems exist. But here the needed exchange from my side is missing.

@N0NB
Copy link
Member Author

N0NB commented Sep 1, 2022

My quick test this morning is that I observed the same behavior in each.

@dl1jbe
Copy link
Member

dl1jbe commented Sep 1, 2022

TLF is generally not aware whether a transmission is ongoing except two special CW use cases (auto CQ and
auto send).

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 reality ANY Esc calls 'stoptx()' (see in onechar() function). But only the first one gives an obvservable feedback (message stops).
  • Any Esc while we are in call input field clears the field.
  • If we are in exchange field and field is NOT empty it is cleared.
  • If we are in exchange field and field is empty it directly goes back to call input.

In case exchange field is empty it saves one key press.

* 1st Esc calls `stoptx()`. There is no visual feedback.
* 2nd Esc clears current input field. If we are in the call input field then that's all.
* 3rd Esc (in exchange field) switches back to the end of call input.
* 4th Esc (now at call input) does the same as the 2nd: clears call input field.

@dl1jbe
Copy link
Member

dl1jbe commented Sep 1, 2022

The problem behind lies in the fact that we get no feedback from the CW keyer if the message is still running.
But we could add a similar logic as for auto-CQ and auto send:

  • calculate the expected running time of the CW message and remember the expected time of its end.
  • Check against that expected time 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.

@N0NB
Copy link
Member Author

N0NB commented Sep 1, 2022

The problem behind lies in the fact that we get no feedback from the CW keyer if the message is still running. But we could add a similar logic as for auto-CQ and auto send:

* calculate the expected running time of the CW message and remember the expected time of its end.

* Check against that expected time if the message is still running.

That would work as long as Tlf has the real sending speed (so no manual setting of it).

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.

It would allows us to fix at least the problem with pressing ESC while a message is running.

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.

@dl1jbe
Copy link
Member

dl1jbe commented Sep 2, 2022

That would work as long as Tlf has the real sending speed (so no manual setting of it).

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.

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.

@zcsahok
Copy link
Member

zcsahok commented Sep 2, 2022

Will be away the next days for local field day

(same here, op of HA5N/P)

@ha5se
Copy link
Contributor

ha5se commented Sep 7, 2022

Sorry, but again, I have a bad feeling that calculating (that is, purely guessing) -- is much more complicated as it first sounds.

  • Regarding K1EL, there is an option for contest spacing: "Instead of 7 dits per wordspace, Contest spacing selects six dits per wordspace."
  • Still regarding different winkeyer implementations, actual WPM implementations may very well differ in actual speed, with no doc. I just refer to my (not very cheap) RigExpert TI-5000 where I had to experiment very much to learn (at least somewhat of) the actual behaviour.
  • Regarding CWDAEMON, it runs under a supervised multi-tasking environment. This means that the actual CW speed is for sure slower than the nominal, due to timer interrupt delays in the supertvisor...
  • Wrong estimations make more confusion than real help. In real situation, I hear from my earphone how far my sending proceeded. However, if TLF thinks (estimates) something different, than it makes more confusion and anger, instead of real help.

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...

@N0NB
Copy link
Member Author

N0NB commented Sep 7, 2022

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 logcfg.dat will enable the behavior we desire. I propose that we use Ctrl-W (although that could be used by a terminal to close a tab like browsers and other programs do so we might need to sample various terminals to be sure) which matches CT and N1MM as a "wipe fields" command that is always active. Only ESC would be affected by the new key word. With the key word ESC only stops TX and without it the present behavior is maintained.

@dl1jbe
Copy link
Member

dl1jbe commented Sep 14, 2022

From HA5SE
Good summary of problems. One minor comment:

* Regarding CWDAEMON, it runs under a supervised multi-tasking environment. This means that the actual CW speed is for sure slower than the nominal, due to timer interrupt delays in the supertvisor...

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.

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...

May be, together with the ESCAPE_STOP_TX_ONLY keyword, the best solution.

Will prepare a Pull request shortly.

From N0NB

I propose that we use Ctrl-W (although that could be used by a terminal to close a tab like browsers and other programs do so we might need to sample various terminals to be sure) which matches CT and N1MM as a "wipe fields" command that is always active.

Ok. Will look if CTRL-W can be used.

@zcsahok
Copy link
Member

zcsahok commented Sep 14, 2022

I'd still prefer the current multi-ESC functionality, of course without the first press wiping the input field.
This seems to me a 3rd alternative, not precluding the introduction of Ctrl-W to clear the field.

@ha5se
Copy link
Contributor

ha5se commented Sep 14, 2022

@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
1:03.93 elapsed

Per definition, should be exactly 1:00.00.
However, much slower. Have also verified few times against wall clock while listening.
i5-8350U CPU @ 1.70GHz, no other load.

@N0NB
Copy link
Member Author

N0NB commented Sep 14, 2022

How accurate is cwdaemon with the PARIS timing?

@ha5se
Copy link
Contributor

ha5se commented Sep 14, 2022

Well... First I would suggest you experiment on your own environment ;) ....
My point was that imho it is impossible to reliably estimate CW duration with the different implementations, and consequently impossible to reliably overload ESC key with different functions on depending upon those wrong estimations.
I am afraid that it is no much help to state e.g. "about 94% correct". At least not for me. I am expecting much more reliability. For the car break, for the washing machine, even my mobile phone ;) ... And expecting still much more when joining my hobby ;) ...

@N0NB
Copy link
Member Author

N0NB commented Sep 15, 2022

What package contains /usr/bin/cw? I see there is a Debian package cw, is that the one you're using?

@N0NB
Copy link
Member Author

N0NB commented Sep 15, 2022

My first run of your command on this Lenovo M73 (i5-4570 CPU @ 3.20GHz (quad core)) gives me:

1:01.79 elapsed

I halved the speed, still consistent:

$ for i in {1..20}; do printf 'PARIS ' ; done | time -f '%E elapsed' /usr/bin/cw --noecho -s p -w 20
1:01.77 elapsed

Watching the elapsed time with a wall clock matches the time command output.

@dl1jbe
Copy link
Member

dl1jbe commented Sep 15, 2022

@zcsahok

I'd still prefer the current multi-ESC functionality, of course without the first press wiping the input field. This seems to me a 3rd alternative, not precluding the introduction of Ctrl-W to clear the field.

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
Thanks for the reply. I did the same check and can confirm the deviation (here it takes 1:04,7.
I did some more checks this time with load on CPU, storage and scheduler (3 parallel jobs compiling a mix of different programs - gcc, boost and some more). Disko IO arond 10MB/s, CPU load 80..100%.

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:

  • Provide a keyword to optional disable ESCAPE for wiping fields
  • Add logic to guess the runtime of cw message (and add some room for errors) and let ESCAPE only wipe out fields if message is no longer running.
  • Add a way to clear the fields without pressing ESCAPE

@ha5se
Copy link
Contributor

ha5se commented Sep 15, 2022

@dl1jbe,

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.

/* from cwdaemon: */
#define _POSIX_C_SOURCE 200809L /* nanosleep(), strdup() */
#define _GNU_SOURCE /* getopt_long() */

#include <time.h>

void main() {
    struct timespec sleeptime, time_remainder;
    int i;

    sleeptime.tv_sec = 0;
    sleeptime.tv_nsec = 50000000;

    for ( i = 1; i <= 1200; i++ ) {
        nanosleep(&sleeptime, &time_remainder);
    }
}

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.

@dl1jbe
Copy link
Member

dl1jbe commented Sep 18, 2022

@dl1jbe,

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.

Maybe you forgot the trailing space character. That should make 30 in the end.

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.

So 1200 is indeed the right number.

.....
    for ( i = 1; i <= 1200; i++ ) {
        nanosleep(&sleeptime, &time_remainder);
    }
}

This gave me 1:00.43 elapsed while not yet doing anything useful...

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.

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.

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.

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.

Sounds interesting. Let us keep it on record. But I would first try to implement the base mechanism.

@df7cb
Copy link
Contributor

df7cb commented Sep 20, 2022

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".

@dl1jbe
Copy link
Member

dl1jbe commented Sep 23, 2022

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.

@N0NB
Copy link
Member Author

N0NB commented Sep 24, 2022

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.

@N0NB
Copy link
Member Author

N0NB commented Sep 24, 2022

After building and making some quick tests in CW and SSB modes with the ESC_STOP_TX_ONLY key word in logcfg.dat, Escape only stops the TX no matter how many times it is pressed! Hooray!

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.

@dl1jbe
Copy link
Member

dl1jbe commented Sep 24, 2022

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.

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.

@N0NB
Copy link
Member Author

N0NB commented Sep 24, 2022

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)

  • Wipe Out Entry Fields, clear information about the current contact in this window
  • If all of the entry fields are blank, this restores the last wiped contact (“unwipe” function)
  • Serial number contests: Release a reserved serial number after it has been reserved

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:

  • When a field is not empty, Ctrl-W wipes the field the cursor is in.
  • When a field is empty Ctrl-W restores the previously wiped information in that field. Ctrl-W then becomes a sort of toggle--wipe, restore, wipe, restore, etc.
  • Conversely, when there are characters in any/all fields, Ctrl-U wipes all fields.
  • When all fields are empty, Ctrl-U restores the previously wiped information to all fields. It too becomes a toggle of sorts--wipe, restore, wipe, restore, but operating on all fields.

Now, I know this puts a lot on your plate, Tom. I hope everyone can give their thoughts before you proceed much further.

@dl1jbe
Copy link
Member

dl1jbe commented Sep 30, 2022

That Nate for digging in. It seems there is no common handling of the problem.

Your suggestion

Therefore, I think we can do this in a way that is familiar but also useful for TLF. How about this as an idea:

* When a field is not empty, Ctrl-W wipes the field the cursor is in.

* When a field is empty Ctrl-W restores the previously wiped information in that field.  Ctrl-W then becomes a sort of toggle--wipe, restore, wipe, restore, etc.

* Conversely, when there are characters in any/all fields, Ctrl-U wipes all fields.

* When all fields are empty, Ctrl-U restores the previously wiped information to all fields.  It too becomes a toggle of sorts--wipe, restore, wipe, restore, but operating on all fields.

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.

@dl1jbe
Copy link
Member

dl1jbe commented Oct 3, 2022

Just updated the above mentioned branch ( https://github.com/dl1jbe/tlf/tree/change_ESC_handling ) according to the above discussion.

  • Ctrl-W and Ctrl-U should work now.
  • Ctrl-U also resets any change in RST (sent and received) but keeps no copy of it.
  • After a second Ctrl-U the content of call input and comment field is restored, but cursor stays in call input field. Should we advance it to comment field if that is not empty?

Please just test if that is working for you all or if there are further things to add.

@dl1jbe
Copy link
Member

dl1jbe commented Oct 23, 2022

@N0NB Ping.
Any feedback here?

@N0NB
Copy link
Member Author

N0NB commented Oct 23, 2022

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.

@N0NB
Copy link
Member Author

N0NB commented Nov 25, 2022

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!

@dl1jbe
Copy link
Member

dl1jbe commented Nov 27, 2022

Ok, thanks for testing Nate.
To be honest I have to apologize to not do to some more work here in the meantime. Schedule is quite terse here, so I got not much time for tlf.

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.

@zcsahok
Copy link
Member

zcsahok commented Dec 31, 2024

Could this issue be closed?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants