I want to know how I can write those two lines || in Eclipse and/or in Android studio. I never figured out how to do this i always copied them out of the internet- -> very uncomfortable.
That depends on your keyboard. On mine it is on the key on the lower left next to the left shift.
However if you don't find it, hold the Alt key and type 124 on the numerical keypad. At least under Windows that returns |.
Related
I know that there exists String.upper for the alphabet, but I'm looking for the shift version rather than the alphabetic version, such as the "uppercase" of the semicolon would be the colon. When I attempt to google I get irrelevant results about string.upper.
I think the best way to handle this would be a lookup table, for example:
local with_shift = {
["1"] = "!",
["2"] = "#",
["3"] = "#",
}
I haven't been able to find an existing table of this, but I'm sure one exists somewhere.
If you are using that for input, you can always check that both the ',' key and the shift key are pressed at the same time - and then execute whatever code you wanted to do.
As others are saying, keyboard layouts are not universal. In a French keyboard, for example, you have to press shift in order to get a '1' when pressing the '1' key in the "top" number row (it defaults to symbols). Neither LÖVE nor Lua know all the keyboard layouts available, and even if they did you could be using a custom-made one (I in fact use one on my computer).
In order to program more efficiently, I want to remap some seldomly used keys on my azerty keyboard §èçà to the more useful []{} (Which otherwise need a Alt-Gr).
I tried a script like this
§::{
è::}
ç::[
à::]
But the problem is that Autohotkey automatically also maps the shifted keys; as such I lose my numbers. Adding the following script does not seem to solve the issue:
+§::6
+è::7
+ç::9
+à::0
Any help how I might remap the "lowercase" letters but not the "uppercase" numbers ?
Try this one:
#If !GetKeyState("LShift") && !GetKeyState("RShift")
§::{
è::}
ç::[
à::]
You could try this:
This looks for a string of one character and the capital C makes it case sensitive. Since I don't own a azerty keyboard, I can't test it.
:?C*:§::{{}
:?C*:è::{}}
:?C*:ç::{[}
:?C*:à::{]}
This works perfectly:
:?C*:§::{{}
:?C*:è::{}}
:?C*:ç::{[}
:?C*:à::{]}
although my version is
:?C*:ù::{[}
:?C*:µ::{]}
:?C*:ç::{{}
:?C*:à::{}}
I want to jump out from quotes. When I was not using ReSharper 'Tap' key helped to jump out from double quotes, but it is not working when using ReSharper.
Of course I do not want to use right arrow key.
Help please.
If you're looking to jump out of the method arguments altogether, use Ctrl+Shift+Enter (Complete Statement).
If your intention is to quit the current string value to start entering the next argument, then I'm not sure anything apart from the right arrow or Ctrl + right arrow will work.
What's the 'Tap' key btw?
As a workaround you can also use Ctrl+W which is 'Expand selection'. Pressing it around three times will select the entire string literal. Then you can press → to go to the right side of selection.
I'm not sure whether there is such a command in Resharper, but if you're saying that this command there was in VS before Resharper then you can find this command in Options->Environment->Keyboard
I'm unable to get this mapping to work in vim inside an xterm terminal.
:map <k0> :echo 'Hello'<CR>
I can get the same mapping to work fine in gvim. If I issue the above command in vim on a terminal, it accepts it, and it shows up correctly when I type :map. But in normal mode, if I press the 0 keypad key, a "0" shows up on the status line, and then disappears with the next keypress.
I'm using the vim that came with Fedora 14 if that matters, and a plain xterm. The keypad keys work fine in insert mode, both with numlock on and off.
What am I missing?
Try to add this line to your ~/.Xdefaults:
xterm*appkeypadDefault: false
and relaunch xterm.
The "Application Keypad Mode" is likely the reason of your troubles.
But I don't think you should do what you are doing. In --NORMAL-- mode, numeric input is used to indicate "count" like in 4dd. Mapping numbers to other commands is going to get you into troubles fast.
You should add a xterm tag to your question.
There's some ambiguity in the question, which may indicate the actual problem. vim accepts that binding for k0 supposing that it is a function key.
Most keyboards that you'll see number function-keys starting at 1, and a few terminal descriptions equate function-key 1 to k0, a few equate it k0 to function-key 10. It's also possible that someone assumes that is part of the numeric keypad, but unlikely (since the keypad uses different character sequences than the function keys).
That's assuming you used a terminal description that knows about the function keys. The vt100 terminal description doesn't do that, since vt100's had no function keys (other than PF1 through PF4 which are or aren't depending who you talk to). But if you had TERM=vt100, then some of the numeric keypad could be recognized on the basis of the terminal description (see for instance the lengthy comment above the vt100+fnkeys description).
It's not in TERM=xterm, however.
What you're overlooking is that vim (helpfully perhaps) amends the terminal description using its built-in termcaps. It recognizes PF1, etc. using table entries like this:
{K_XF1, IF_EB("\033O*P", ESC_STR "O*P")},
{K_XF2, IF_EB("\033O*Q", ESC_STR "O*Q")},
{K_XF3, IF_EB("\033O*R", ESC_STR "O*R")},
{K_XF4, IF_EB("\033O*S", ESC_STR "O*S")},
But there are no entries for the numbered keys; there's no "\033O*p" for the 0 key.
If vim has (in the terminal description) the k0, and you haven't mapped it to anything, vim will treat it as a literal 0. The same happens with k1, etc., in effect treating the function-keys and numeric keypad as the same thing.
For what it's worth, GNU screen does the same thing, but also for the numbered keys. If I run vim inside screen, vim will see only the 0's. A literal 0 in vim doesn't do much in command-mode.
I've been using Vim for many years and have never really thought about it. A friend of mine asked why that is, noting that in our culture, left would usually map to up while right would map to down, making the Vim keys backwards.
I understand that they are on the home row, meaning that you do not have to move your fingers anywhere to hit them, but that's a different point altogether.
Why were these keys given their present purposes? Is there some documentation on the decision as well?
The answer is in the Wikipedia entry for vi. Bill Joy, who wrote the visual mode of ex - which ended up being Vim's precursor vi - used a Lear Siegler ADM-3A terminal on which the HJKL keys mapped to left, down, up, right - and it’s been that way ever since.
Here's the keyboard layout:
A couple of other points of note on the ADM-3A layout:
Left of the Q: the escape key - somewhat handier than where it is on keyboards today, hence a good choice for switching between normal and insert modes.
Top right: the 'Home' key doubles as the tilde (~), which subsequently became shorthand for a Unix user's home directory.
vimtutor provides the mnemonic that 'J' looks vaguely like a downward-pointing arrow, though that may or may not be the original reason why it was chosen.
This is a total guess, but: The Ctrl+J character is the "line feed" character, which on a traditional TTY moves down one line, providing a mnemonic. K was right next to it on a Qwerty keyboard, under the second most commonly used finger on the right hand when in the home position.
Simply to supplement all the answers, here is the photo of the ADM-3A keyboard (the exact keyboard on which Vim has been created).
P.S: I wish they had used W, A, S, D
From a user experience perspective, after you open a file, you always move down first and moving down is usually a more frequent operation. Since from left to right is the natural direction for most of us, it make sense to associate the task you perform first or more frequently with the key on the left. You can try to switch the 2 keys and try to tell which way is better. For me, "J" for down is more natural and comfortable.
It explains it if you run vimtutor in the terminal. It says:
The h key is at the left and moves left.
The l key is at the right and moves right.
The j key looks like a down arrow.
I always thought it was because on the Dvorak layout, j and k are also next to each other. There are not many keys that have this property on both Dvorak and A/QWERTY/Z.