I'm trying to do a case-sensitive search in Nano. The help menu at the bottom of the screen says I can toggle case-sensitivity by typing M-C.
^G Get Help ^Y First Line ^T Go To Line ^W Beg of Par M-J FullJstify M-B Backwards
^C Cancel ^V Last Line ^R Replace ^O End of Par M-C Case Sens M-R Regexp
I'm not sure how to do this. Does M- refer to a modifier key that should be held while I type C? Or does M- mean I should press some key or key combination before hitting C?
M refers to the meta key, which is not present on most keyboards. (Its use in software is for primarily historical reasons.) Usually, the meta key is emulated by another key on your keyboard. On Windows and Linux, it is usually the Alt key. On Mac OS X, that key (aka Option) already has other uses, and so Escape is used instead.
Esc
For instance, if you wanted to go to the end of the file press
Esc then /
You don't need to hold down Esc as if it were Shift.
I do not know for nano, but for emacs, M- stands for the Meta key, which can mean pressing the Alt key simultaneously with the letter key or by pressing Esc key before the letter key. Alt generally only works when using an X version of the application, so when using a dumb terminal, only Esc will work.
Related
What are QKeyEvent.nativeModifiers()? The documentation doesn't say much (https://doc.qt.io/qtforpython/PySide6/QtGui/QKeyEvent.html#PySide6.QtGui.PySide6.QtGui.QKeyEvent.nativeModifiers). From what I understand, the integer that is returned by calling this method on a QKeyEvent object represents the full state of the modifier keys (Ctrl, Shift, Alt, etc.).
Moreover, I would assume that the mapping between these integers and their respective modifier states is systematic, so is there a way to test whether a given modifier state contains a specific modifier (e.g. by using the "&" operator)?
Importantly, are the native modifiers cross-platform such that a Left Ctrl keypress on a PC returns the same integer as a Left Command on a Mac (since Qt.Key_Control corresponds to the MacOS command keys)?
As name suggests native modifiers has different values on mac and on pc. On windows value is a combination of WindowsNativeModifiers, on macOS it is a combination of NSEventModifierFlags, both translated to Qt::KeyboardModifiers (windows macOS) which is same on both platforms.
I've been through the subreddit and the SO tag as well as a couple of pages of multiple phrasings of a Google search, and I can't find any threads/topics/pages that address this, so here goes:
I want the prefix key in tmux to always 'activate' the prefix in tmux. Let me explain what I mean - from the man page:
tmux may be controlled from an attached client by using a key combination of a prefix key, `C-b' (Ctrl-b) by default, followed by a command key.
The default command key bindings are:
C-b
Send the prefix key (C-b) through to the application.
I don't have 'send-prefix' in my tmux.conf set to send the prefix combination to the application when pressed twice, but the result seems to be that the prefix now acts as a 'toggle'. Press it once, and the next key is interpreted as a command. Press it twice and the next key is sent directly to the application. For example:
C-b, C-Up results in my pane being resized up by one cell, but
C-b, C-b, C-Up results in ctrl + up being sent to my terminal window.
I would like to make it so regardless of how many times the prefix is pressed, the next key pressed is always interpreted as a command (i.e. the two keystroke sequences above to give the same result).
Thanks in advance!
If you're wondering why I want this, suffice to say it has to do with a very complex tmux.conf file and the repeatable flag on a lot, but not nearly all, of my key bindings. I'm so accustomed to having to press the prefix immediately before the non-repeatable bindings that I always hit it, even if I've just finished using a repeatable command. This looks like a 'second' press of the prefix to tmux, which makes sends my command key to the terminal. Edge case, I know, but if it is possible to turn this behavior off it would save me a ton of mistaken keystrokes!
This should do the trick:
bind-key C-b switch-client -Tprefix
It makes more sense if you think of the prefix not as a special key, but simply one bound in the root table that also calls switch-client -T:
# Equivalent to 'set-option -g prefix C-b'?
bind-key -Troot C-b switch-client -Tprefix
I don't know if this is a bug or something wrong i am doing but when ever i type something and press enter to select from the auto complete menu it leaves whatever is written before... or specifically the # symbol for now
here a picture demonstration
enter image description here
enter image description here
So more to the question, Atom does replace whatever you type if you chose to auto-complete in contrary to what Brent said below. In an html file try typing dv or btn and select to auto-complete you'll then see that it replaces what you've typed. So this behavior is only (as far as i am concerned) replicable with symbols
From the Autocomplete section of the Atom Flight manual:
By default, the autocomplete system will look through the current open file for strings that match what you're starting to type.
If you've typed in part of a keyword that Atom doesn't recognize, and then autocomplete the rest of the phrase, Atom will not erase what you've previously typed. I used to do this a bunch when I first started using Atom. The solution is simple: just type the part of the keyword that Atom recognizes before auto-completing the rest of it. So in the case of your first example image, you just have to start typing the phrase media and then press enter; no need to include the preceding # symbol. This ultimately means that you just have to type less to get your desired code, which I think is pretty sweet.
I am trying desperately to get a Bluetooth dongle working with my Arduino but I can't send it a command that it needs. I can use it when I plug it into my computer via a USB to UART chip and send the command (C) from PuTTY and then press Enter.
The Bluetooth dongle's command sheet says that the command I am trying to send it C<cr> but I can't figure out how to send the proper carriage return character from the Arduino code. I have tried using the Serial.println() function as well as adding the \r character to my current Serial.write("C\r") but neither of those are working.
How can I achieve this?
Interestingly, I can report the opposite on Win 7: PuTTY for me and my embedded project is sending ONLY \r over the COM port. Curious, read: frustratingly unexplainable, but I simply look for either character on the other end of the serial connection.
Then, if you enable "Implicit LF in every CR" under Terminal options it will send both \r\n. Default behaviour seems to be akin to a Commodore machine :D (http://en.wikipedia.org/wiki/Newline). who knew...
Sending CR+LF is possible in modified PuTTY. Source code is available at https://github.com/gniemirowski/putty-crlf and Windows binary at https://www.grzegorz.net/pliki/putty-crlf.zip When you run this version just go to Terminal -> Keyboard and select "CR LF" for "The Enter key" option.
PuTTY emulates xterm which emulates vt100. To have putty send CR/LF when pressing enter, type ESC[20h in putty after connecting to the serial device. This sets VT100 LNM true.
http://vt100.net/docs/vt100-ug/chapter3.html
Line feed/new line New line ESC [20h Line feed ESC [20l
If you watch the ascii table or similar reference you might find interesting: \r ou \x0D
For better understanding, see : http://www.grok2.com/sedfaq6.html
The modified PuTTY is the easiest solution. If you want to stick with the standard PuTTY, there's some other options...
You can send a newline using ctrl+j before pressing enter, but that's a faff.
To automate it, you can use AutoHotKey to change your {ENTER} to ^J{ENTER} when you've got a PuTTY window active:
#if WinActive("ahk_exe putty.exe")
Enter::
SendInput ^J{Enter}
Return
#if
To do this for just one PuTTY window, you can give AHK the name of the window:
#if WinActive("COM8 - PuTTY")
Enter::
SendInput ^J{Enter}
Return
#if
On arduino program, just use Serial.write and both characters codes:
Serial.write(13); // CR
Serial.write(10); // LF
And Avoid Serial.print as it is intended as human readable, so formatted.
references: write print
In standard configuration (on Windows and Linux) if you type "help" and then press enter, the following chain of bytes will appear on the serial port (checked with external connected terminal via RS232, and logic analyzer):
0x68(h) 0x65(e) 0x6c(l) 0x70(p) 0x0d(CR: Carriage Return U+000D)
So it seems like PUTTY puts CR on ENTER (no matter if you are on Linux or Windows).
I'm almost sure that you are looking for the \n new line character.
I tried this very simple code (cr = carriage return)
Serial.write(13);
And because the next "printed" caracters will feed the residual text, it's ok.
If I add a listener to KeyboardEvent.KEY_DOWN, I can find out the keyCode and the charCode.
The keyCode maps to a different character depending on the keyboard.
The charCode is just as useless, according to the help:
The character code values are English keyboard values. For example, if you press Shift+3, charCode is # on a Japanese keyboard, just as it is on an English keyboard.
So, how can I find out which character the user pressed?
You left out a pretty important part of the quote or it was missing where you found it:
For example, if you press Shift+3, the
getASCIICode() method returns # on a
Japanese keyboard, just as it does on
an English keyboard.
http://livedocs.adobe.com/flex/201/langref/flash/events/KeyboardEvent.html
This is probably more helpful:
The charCode property is the numeric value of that key in the current character set (the default character set is UTF-8, which supports ASCII).
http://livedocs.adobe.com/flex/2/docs/wwhelp/wwhimpl/common/html/wwhelp.htm?context=LiveDocs_Parts&file=00000480.html
Your application determines what characters set is used, meaning that the even if you have to use separate keys of different keyboard locals to produce the same character, it will have the same charCode.
NOTE: (This is about keyboard messages in general and does not apply to actionscript alone. I misread the question and provided a deeper answer then was helpful)
Really, the path from keyboard to windows char is a VERY complex one, it goes something like this:
Keyboard send scancode to Keyboard device driver (KDD).
KDD sends a message to the system message queue.
The system then sends the message to the foreground thread that created the window with the current keyboard focus.
The thread's message loop picks up the message and figures out the correct character translation.
The 'real' char that was typed is not calculated until it finishes that whole process, as each window and thread can be on a different locale and you can't really 'translate' the key without knowing the locale and key buffer history.
The "WM_KEYDOWN" and "WM_KEYUP" messages cannot just be converted with MapVirtualKey or something because you don't know how many key presses make up a single char. The simple method is just handle the 'WM_CHAR' event and use that. Consider the following:
en-US locale, you press the following keys a + ' + a, you get the following output "a'a"
pt-BZ locale, you press the following keys a + ' + a, you get the following output "aá"
So in both examples you would get 3 KEYDOWN, KEYUP messages, but in the first you get 3 WM_CHAR and in the second you only get 2.
The following article is really good for the basic concepts:
http://msdn.microsoft.com/en-us/library/ms646267(VS.85).aspx
You cannot effectively use charCode or keyCode to determine the character that was entered. You must compare strings only. The KeyboardEvent does not give you the entered text, which is also silly.
In my case I implemented a KeyboardEvent.KEY_DOWN event in addition to a TextEvent.TEXT_INPUT event. In the handler for the latter I implemented all functionality where the charCode was needed and didn't vary per keyboard locale (eg. space bar or enter). In the the former I checked for the text property of the event to compare what I needed locale independent.
Forgot to mention that this post hinted me to that solution: How to find out the character pressed key in languages?
Typing Japanese hiragana etc characters often require several keystrokes and sometimes even selecting the appropriate character from a drop down menu. You probably want to listen for a different event, something like a textfield's change event.