Closed prairiedock closed 3 years ago
One method for debugging is to run > raw
which will show what event micro thinks it is receiving when you press certain keys. What does micro report when you press Ctrl-n, Ctrl-f, Shift-up and Shift-down in this mode?
OK, results of > raw are:
1 EventKey: Shift-Left: "\x1b[1;2D"
2 EventKey: Shift-Right: "\x1b[1;2C"
3 EventKey: Ctrl-n: "\x0e"
4 EventKey: Ctrl-o: "\x0f"
5 EventKey: Ctrl-p: "\x10"
Lines 1 and 2 are included FYI. Shift-up and Shift-down are trapped by the terminal and scroll the whole window up and down-- I didn't notice this before because the crosh window was already at the limits of its travel, so it appeared that the keys did nothing. Ctrl-n and Ctrl-p look normal; I don't know why they don't work after a Ctrl-f search.
Ctrl-f produces "\x06".
It seems like micro is correctly recognizing ctrl-n, ctrl-f, and ctrl-p so I'm not sure what the issue there is. Do these keys work for you on other systems? If you rebind their actions (FindNext, Find, ...) to keys you know to work in crosh do they work then?
I have only Chromebooks right now, but I have another one which can run Debian in a VM (Crostini) (and/or Crouton, which is straight Ubuntu in a chroot), so I'll try it out there as soon as I get a chance.
Also I'll try it on this machine with rebound keys. Thanks for your help so far.
Despite these minor problems, I'm inclined to use Micro going forward; it looks good to me.
On further investigation, it appears that the Ctrl-n, Ctrl-p thing was a bit of my mistake. (Sorry!) If you hit Ctrl-f and type a search regex, Micro searches and highlights as you type. If you then hit Ctrl-n or Ctrl-p, nothing happens. You have to hit ENTER to close off the search first, and then Ctrl-n and Ctrl-p work as expected.
As for Shift-uparrow and Shift-downarrow not working, the Crosh terminal captures them and that's that. (I found that this problem is discussed in the documentation.) I rebound the SelectUp and SelectDown functions to different keys in bindings.json.
So this whole issue can be summarized as:
TL;DR: A hotkey combination will not work in Micro if the OS or the terminal captures it first.
and TL:DR2: Micro works in a Chromebook in Developer Mode by simply inserting the binary into /usr/local/bin (in Crosh.) This should be good news to anybody looking for a code editor for a Chromebook.
Hi,
Just for a complete overview: A keyboard expander like Autohotkey (Windows) can intercept keystrokes before they are consumed by the terminal. Then you can send allowed replacements and bind them, I think this is why micro recognizes F keys up to F64!
KR Gavin Holt
Description of the problem or steps to reproduce
Shift-up and Shift-down don't work to select text up and down, resp. (They do nothing, although Shift-left and Shift-right work.) Also, Ctrl-n following Ctrl-f does nothing rather than "next search"
Specifications
Micro version: 2.0.8 Commit hash: cfcb2e45 OS: Chrome OS (kernel 3.18.0) Terminal: Crosh shell
I was thrilled to find that in Crosh shell on my Lenovo Thinkpad 13 Chromebook
inserts a static binary into /usr/local/bin, and it works, without my having to install Chromebrew or Crouton. This could be highly useful, since Chrome Apps (and thus the Caret Editor) are going away in June, 2021, and the Thinkpad 13 won't run Crostini (Debian) on account of the kernel being too old.
Almost everything works perfectly except the keyboard shortcuts above. I rebound SelectUp and SelectDown to Alt-j and Alt-k (in bindings.json) and they work, so the issue is with the keyboard/terminal somehow. I should mention that I full-screen the Crosh window so that, e.g., Micro keys like Ctrl-w work properly and are not captured by Chrome OS, but this didn't help Shift-left and Shift-right.
I don't know if this is related to #1864 or not; that issue appears to be with Windows.