I'm still on v2.1... Good thing to watch out for, however. Greg On January 11, 2018 9:51:32 PM PST, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
Maybe the recent change for IDF v3 where Espressif messed around with CRLF.
2f0c9f0 Translate CR or CRLF to LF on async console for microrl
$ git diff fc69e3e 2f0c9f0 diff --git a/vehicle/OVMS.V3/main/console_async.cpp b/vehicle/OVMS.V3/main/console_async.cpp index e7110fa..dd3df4a 100644 --- a/vehicle/OVMS.V3/main/console_async.cpp +++ b/vehicle/OVMS.V3/main/console_async.cpp @@ -155,6 +155,24 @@ void ConsoleAsync::HandleDeviceEvent(void* pEvent) if (buffered_size > 0) { int len = uart_read_bytes(EX_UART_NUM, data, BUF_SIZE, 100 / portTICK_RATE_MS); + // Translate CR (Enter) from montitor into \n for microrl + bool found = false; + for (int i = 0; i < len; ++i) + { + if (found && data[i] == '\n') + { + for (int j = i+1; j < len; ++j) + data[j-1] = data[j]; + --len; + continue; + } + found = false; + if (data[i] == '\r') + { + data[i] = '\n'; + found = true; + } + } ProcessChars((char*)data, len); } break; @@ -171,7 +189,7 @@ void ConsoleAsync::HandleDeviceEvent(void* pEvent) uart_flush(EX_UART_NUM); break; default: - ESP_LOGI(TAG, "uart event type: %d\n", event.type); + ESP_LOGE(TAG, "uart event type: %d", event.type); break; } }
That should only affect the ASYNC console, I think. It converts CR/LF/CRLF -> LF. Maybe the enum KEY_ACTION in openemacs (vfsedit component) needs to change?
Fix is probably to add a NL=10 to KEY_ACTION and then to treat NL or ENTER as the same in the editor_process_keypress. My build environment is all switched to v3 at the moment, so hard for me to test (as IDF v3 does things differently). I’ve made the fix in the for-master branch, and it seems to work for me.
$ git diff --staged --- a/vehicle/OVMS.V3/components/vfsedit/src/openemacs.c +++ b/vehicle/OVMS.V3/components/vfsedit/src/openemacs.c @@ -71,7 +71,7 @@ struct append_buffer enum KEY_ACTION { CTRL_A = 1, CTRL_B = 2, CTRL_C = 3, CTRL_D = 4, CTRL_E = 5, CTRL_F = 6, BACKSPACE = 8, TAB = 9, - CTRL_K = 11, CTRL_L = 12, ENTER = 13, CTRL_N = 14, CTRL_P = 16, CTRL_Q = 17, CTRL_R = 18, + NL = 10, CTRL_K = 11, CTRL_L = 12, ENTER = 13, CTRL_N = 14, CTRL_P = 16, CTRL_Q = 17, CTRL_R = 18, CTRL_S = 19, CTRL_U = 21, CTRL_V = 22, CTRL_X = 24, CTRL_Y = 25, CTRL_Z = 26, ESC = 27, FORWARD_DELETE = 127, // The following are just soft codes, not really reported by the @@ -1297,7 +1297,7 @@ bool editor_process_keypress(struct editor_state* E, int k) // Quoted insert - insert character as-is editor_insert_char(E,key); } - else if (key == ENTER) + else if (key == ENTER || key == NL) { editor_insert_newline(E); }
I just made the fix also in the master branch, but haven’t tested.
Regards, Mark.
On 12 Jan 2018, at 1:36 PM, Greg D. <gregd2350@gmail.com> wrote:
Is anyone else having trouble with the vfs editor? I can't seem to enter a newline anymore. The status line at the bottom complains of an unknown command 10 (presumably control-J). If I try an explicit control-M, it says the same.
Did I fat-finger something in my config (I removed SSH, Telnet, and several other items to save RAM recently), or did something else change? This is with two different terminals - make monitor on the development laptop, and putty on my in-car Raspberry Pi.
Greg
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.