I got this simple key mapping:
!l::Send, {right}
Pressing it a few times or holding it down for short periods of times is no problem; it works as you would expect. However, if you hold alt + l for a long period of time, the mapping will eventually break, sending the actual key instead of what is mapped to. So in this case it would send a lot of l's when it eventually breaks.
Gif showcasing it,
Another example
The issue isn't unique for this mapping, it happens for a lot of my other simple mappings too.
Is this a general known issue?
Is there any fix?
Details
My OS is Windows 10
Related
Try running the following code yourself, and you would notice that "/hello" changes to "/HELLO", but I want it to change it to "hi". On the other hand, I want to keep the 1.st line of code, which changes "hello" to "HELLO". How could I achieve this(?)
This code problem is very related to my last problem:
Collision with two lines of code make code does not work the way it is meant by me, what could I do different to get this work(?)
The soltuion for my last problem was good for that problem, but it is not working for the new above mentioned problem.
::hello::HELLO
::/hello::hi
That is interesting. I really expected it to work by removing / from the EndChars. But after looking at it for a while, it becomes obvious why it's behaving this way. When you type "/hello" it actually matches to both hotstrings, so AHK chooses the first one defined. Anyway, there are two solutions that I know of:
Reorder your hotstrings. Place ::/hello::hi above the other one and you'll always get the desired result. Additionally, you don't need to change the EndChars since / is the first character.
Use the asterisk option on the second hotstring. This will make it update immediately, which may or may not be desirable (I prefer it).
I am posting for a sanity check so please forgive me if this sounds a little basic. I am trying to learn more about encryption so I figured a good starter project would be implement the Sha-1 hashing algorithm. I found a walk-through and have hit a point where I do not know if the walk-through is wrong or my understanding of bitness/rotation/binary operations is wrong.
From the document:
Step 11.2: Put them together
After completing one of the four functions above, each variable will move on to this step before restarting the loop with the next
word. For this step we are going to create a new variable called
'temp' and set it equal to: (A left rotate 5) + F + E + K + (the
current word).
Notice that other than the left rotate the only operation we're doing is basic addition. Addition in binary is about as simple as it
can be.
We'll use the results from the last word(79) as an example for this step.
A lrot 5:
00110001000100010000101101110100
F:
10001011110000011101111100100001
A lrot 5 + F
Out:
110111100110100101110101010010101
Notice that the result of this operation is one bit longer than the two inputs. This is just like adding 5 and 6, you will need a new
place value to represent the answer. For everything to work out
properly we will need to truncate that extra bit eventually. However,
we do not want to do that until the end!
This does not quite work out. What I think would happen is:
A = 00110001000100010000101101110100
F = 10001011110000011101111100100001
A Left rotate 5 = 00100010001000010110111010000110
(A Left Rotate 5) + F = 10101101111000110100110110100111 (which is still 32 bits)
What I need is just another set of eyes on this to say "Yes krtzer, you are correct and this document is wrong" Or "Your understanding of bitness, endianness, and/or bit rotation is wrong, this is how it works".
Right now I am not sure if my integer representation is wrong (the spec says use U32s, but this section says that I need to keep track of the extra bits), the endianness of my program is messing up the rotation (I use little endian) or there is something else.
Any experience or insight will be appreciated!
You are correct in your understanding of how everything works. The problem was with the article (which I wrote). An extra digit must always be added in the beginning of step 11.2, whether it's necessary or not, and if it's not necessary, it should be set to 1.
The article now reads:
Notice that the result of this operation is one bit longer than the two inputs. After each iteration the new word should be one bit longer than the last. Sometimes this will be a necessary carrier bit (like the extra place value you need to represent the result of adding the two single digit numbers 5 and 6 in base 10), and when that's not needed you must simply prepend a 1. For everything to work out properly we will need to truncate that extra bit eventually; however, we do not want to do that until the end!
The article was also unclear about the fact that an already rotated A was being shown in the example.
How to lower/remove the delay, and speed up the insertion of additional keys on holding down a key?
For instance: if you want to type a long "ffffffffffffff" sequence, when you do not care how many f's exactly, it takes quite some time when holding down the f to get the result.
There is a quite long initial delay, and the speed of the f's appearing after the delay is not the fastest either. Does anyone know which parameters are involved, and how to alter them?
Key repeat settings are always controlled by the base operating system, which you didn't state. In the control panel or settings configuration for windows, osx, Linux, (and pretty much everything these days) there are two settings controlling key repeating. The first is how long the delay is until the repeating starts, and the second is how fast the repeating occurs.
On unix systems (ie, X-window based), there is also the xset command line tool which can be used to change the keyrepeat:
# xset -h
... help output ...
To turn auto-repeat off or on:
-r [keycode] r off
r [keycode] r on
r rate [delay [rate]]
And, as someone said, in emacs it's actually faster to insert a bunch of random characters by simply using ctrl-u followed by your random number and then hitting the key. Or, in fact, you can use alt-6 alt-4 f as well.
(yes it's technically meta in emacs, but your key is likely labeled alt)
I do really like key-chord.el but I'd need it to only trigger when I start pressing keystrokes after a short delay during which I didn't do anything elapsed. I'd like to know if it's easy to modify key-chord.el to do that.
Why I want that is simple and I'll try to explain it as easily as I can:
I do want keychords to be assigned to keys that are on my "strong" fingers (no pinky) and that are on my home row (I do touch-type). Hence I'm potentially creating quite a few keychords which may clash with common words / code when I'm typing.
I realized that everytime there's a clash (i.e. keychords kicking in while I didn't want to) it's because I'm in the process of frenziedly modifying the buffer.
Here's an example...
I'm a fast typist so if I'm entering, say, "held", there is never going to be a long delay between when I add the 'e' of "held" and when I then type the 'l'. So in this case it should be "obvious" that I do not want key-chord to kick in when I type 'ld'. However if there's a pause and if 'ld' is an assigned key-chord and then I hit 'ld', then it is very unlikely that I'm writing code / text that would be starting with 'ld'. So in this later case (and because I have assigned 'ld' to a key-chord), I do want it to kick in.
Now don't get me wrong: I'm not sayin this would eliminate every single possible clash in every single case. All I'm saying is that, in my case, this would probably eliminate 99.9% of the (already rare) clashes. The "time lost" should one clash still occur after this change to key-chord would be negligible compared to the amount of time key-chord is making me gain.
The code to key-chord.el is very small so maybe such an addition wouldn't be too hard?
Does anyone have an idea as to how if it would be easy to modify key-chord.el to provide such a feature? (I hope I explained correctly what I want to do)
Here's the code to key-chord.el and half of it is comments:
http://emacswiki.org/emacs/key-chord.el
The Idle Timer mechanism should be able to facilitate this.
C-hig (elisp) Idle Timers RET
I'll leave it to you (or someone else) to figure out the details. Offhand thoughts are:
enable the Key Chord functionality via an idle timer
use post-command-hook to disable it again
That might be all that is needed?
I see two timings at play here
time before the chord (between the letter before the chord and the chord. If short enough, no chord)
time after the chord (if new letter quickly typed, no chord)
The second type of timing is probably more natural, and easy to get used to. If one type the chord, a short timeout before it executes can be accepted. (This is not what you asked for and would not solve the "ld" example. But it could potentially solve the problem with letter combinations that may appear in the beginning of words.)
The first type of timing is probably harder to get used to. When one have completed typing a word and the next thing is to type a chord, I suspect it is not a natural instinct to make a short pause. If one uses the chord often, one is likely to type it quickly, and get annoyed if it is not recognized (and the two chars are inserted into the text instead). What I want to say is, I am not sure a timing before the chord will solve the problem to a satisfactory degree.
As for the implementation of such a timing. The way the state machine in the key-chord-input-method function is currently structured, it would grow exponentially with the number of timers to consider (if I recall correctly). I.e. there would be at least about a dozen new lines of code.
To experiment with the functionality, try phils suggestion in the other answer: a post command that disables chords, and an idle timer that, after a fraction of a second, enables them again. A quick and dirty way to disable and enable chords, without actually changing minor mode, would be to set the input-method-function variable.
Code for test purpose only. It assumes, but does not check, that key-chord-mode version 0.5 is loaded and enabled:
;; Helper functions to be used in timers and hooks
(defun my-enable-chords () (setq input-method-function 'key-chord-input-method))
(defun my-disable-chords () (setq input-method-function nil))
;; Start test
(add-hook 'post-command-hook 'my-disable-chords)
(setq my-timer (run-with-idle-timer 0.3 'repeat 'my-enable-chords))
;; Finish test
(remove-hook 'post-command-hook 'my-disable-chords)
(cancel-timer my-timer)
By "cleaned" I mean formatting inputs such as "a1b2c3" into "A1B 2C3" or "5551234567" into "(555) 123-4567". I figure we have few options:
As the user is typing. For instance, when a user is typing a postal code, all letters are instantly capitalized, or after the user types 3 digits of a phone number, it puts brackets around them.
When the field loses focus.
Never. Formatting happens on the server-side only, just before it is inserted into the DB. The user never gets to see how it was formatted unless it is displayed on the site somewhere.
(3b) If there were form errors, or on the confirmation page. If there are form errors and the form needs to be re-displayed, the formatting on the valid inputs will appear, or if you have a confirmation page (are these inputs correct?) they will show there.
Never ever. Data should be dumped into the database as-is and only formatted in the template/view just before it is displayed back to the user.
What do you think? I think I like (2). Reminds me of how code-formatting works in Visual Studio (happens when you close a brace or type a semi-colon).
I like to either filter the field just after it loses focus (when it is critical that the field be formatted correctly before they move on to the next field - which is rarely), or I filter the field content as soon as the user hits the "SUBMIT" button (or whatever you want to call it) to send the data to the server.
This has a few advantages for me:
The user's input is not interrupted with annoying "auto-corrections" - being auto-corrected can sometimes feel like demonic possession if it is not done well.
The user really neither cares, nor needs to know that you do not want the (,), or -, in your phone number field... so take it out quietly for them. No notes, or instructions needed.
Also, I ALWAYS filter the field values anyway to protect against any kind of code-injection attacks (which are alarmingly easy to pull off if you know what you are doing). I have read about entire databases being compromised because the author did not remove potential SQL markup from submitted data.... it makes me shudder.
It also allows me to check for ALL input errors (if any), or non-filled-out required fields and report a single set of issues to the user at a single time... I have been to sites that give you so many messages while filling out a form it feels a bit like having a nagging relative over your shoulder.
I'd go with either (1) or (2), depending on the kind of input. (1) is probably most user-friendly if done right, but it will be more complex to implement neatly (e.g., what happens if I delete a digit from a hyphenated phone number - or a hyphen?). Go with (1) if you can afford it, otherwise (2).
I follow the same method I use for validation. Once on the client side, once on the server side. Whether it happens on loose focus or as they type it doesn't really matter.
As the user is typing. For instance, when a user is typing a postal code, all letters are instantly capitalized, or after the user types 3 digits of a phone number, it puts brackets around them.
This type of input is excellent for things such as entering serial codes or CD keys for software or games. I notice a lot of people get confused whether or not the code is case sensitive or if they should be inputting the dashes as well.
If you have an iPhone you'll notice when entering a phone number it is also auto formatted with brackets and spaces as you enter it. But this often turns out to be confusing as a partially typed number is not always 'grouped' correctly.
Answer: It all depends on context.