Does anyone know if using AHK increases input latency at all?
In Praise of AutoHotKey
91–100 of 220 posts
Re: In Praise of AutoHotKey
#92Earlier quoted context omitted.
The usage of ; as a hyper key is fascinating. This is the first time I've seen someone do something with Hammerspoon that's actually tempting me to try it out. For paste blockers I've been using an Alfred workflow that types keys using AppleScript. It doesn't work with characters that require special input like ü, which is annoying, but it's sufficient for passwords. The benefit here is I'm not using up a global hotk…
Using ; as a hyper key blew my mind, like the article recently about how a certain developer calls all of his scripts ',something' so if he want to run a cli command of his, pressing comma then tab will show only his scripts, so ',py(tab)' won't have 15 pythons in it.
I had almost used up all combinations of Ctrl, Alt, Shift, Win and letters at one point, and still never thought of making my own hyper key. It's genius.
At my new job I'm afraid to download AHK at all :(
Re: In Praise of AutoHotKey
#93A thousand times, this. I love AHK. It, along with Ditto Clipboard Manager (Yes, I know W10 has its own. It sucks) changes my workflow so much for the better. Some of my favorite examples: Right Alt becomes Ctrl Tab: Ralt::^Tab Common typos: ::teh::the ::alreadsy::already ::nopity::Call to undefined function pity() ::awk1::awk '{{} print $1 {}}' ::du-m::du -m --max-depth=1 | sort -n But it goes waaay behond this. I o…
I'm a bit masochistic when it comes to typos. This is from my AHK script: :*:netowrk:: Send, {Home}+{End}{Delete} return What it does: I have a really bad habit of misspelling "network" that way. I think my right hand is just so eager to get that 'o' keyed in that it doesn't wait for my left hand to hit the 'w' first. So I'm always screwing that word up when typing quickly. So now, when I make that mistake, I'm punis…
You should add a popup that requires you to type in "network" correctly and then issues a Ctrl+Z.
Re: In Praise of AutoHotKey
#94I would like to see much more work on "Generic Scripting Hosts", like ActiveScripting (MS) and OSA (Apple)? But since everybody develops into the cloud, goodbye elegant user experience...
Re: In Praise of AutoHotKey
#95The hotstrings feature is also present in Linux, where they are known as compose sequences. The default compose sequences can be found in the Compose files under /usr/share/X11/locale and you can also have custom compose sequences in ~/.XCompose. Some of the compose sequences make use of a special Compose key (written in the rules). You may need to go to the keyboard settings to enable the compose key. https://en.wik…
you can also use espanso: https://github.com/federico-terzi/espanso
Re: In Praise of AutoHotKey
#96Earlier quoted context omitted.
Not at all. He could have written his own program and just used it, and IT would never have gotten involved. Because it was using a 3rd party tool, IT got lazy. My company, BTW, not only explicitly allows AHK, they actually encourage it. I mean, if you're going to give people compilers to write arbitrary code, this is not worse.
It seems weird to expect someone with no programming training (an IT guy) to either build or sign off on something they have no understanding of. In large/high stakes settings, being risk averse and knowing the limits of your understanding are very good traits. Imho, this IT guy did his job, more or less. What was the testing plan for this AHK script? What edge cases were considered? Unit tests, integ tests.... was t…
You absolutely do not need all that red tape to use a script written for a well-known program. The IT guy just didn't care to spend the teensiest mental energy to save people an enormous amount of work. "No" is the easiest, safest call possible, not a hard call at all. People like him should be shamed.
Re: In Praise of AutoHotKey
#97[deleted]
Re: In Praise of AutoHotKey
#98I've started[1] to do similar things on macOS using Hammerspoon[2]. So far I've set it up to let me: 1. Use shift when pasting something to simulate typing in the text instead, getting around websites that block pasting. 2. Use ";" as a hyper key. By holding it down and pressing another key, I can switch between specific programs without cycling. I can also use hjkl as arrow keys. 3. Automatically switch audio input…
I really need to look at Hammerspoon, thanks for the pointer.
Talking about automation, I use BetterTouchTool[1] to give me a few useful touch bar icons:
- Speaker and headphone buttons (using switchaudio-osx[2])
- Start meeting that starts a Zoom call and adds the link to my clipboard
- Write email that gives me a new blank email (and makes it visible)
Re: In Praise of AutoHotKey
#99Earlier quoted context omitted.
Not at all. He could have written his own program and just used it, and IT would never have gotten involved. Because it was using a 3rd party tool, IT got lazy. My company, BTW, not only explicitly allows AHK, they actually encourage it. I mean, if you're going to give people compilers to write arbitrary code, this is not worse.
It seems weird to expect someone with no programming training (an IT guy) to either build or sign off on something they have no understanding of. In large/high stakes settings, being risk averse and knowing the limits of your understanding are very good traits. Imho, this IT guy did his job, more or less. What was the testing plan for this AHK script? What edge cases were considered? Unit tests, integ tests.... was t…
> It seems weird to expect someone with no programming training (an IT guy) to either build or sign off on something they have no understanding of.
Once again, if I wrote my own Python script they would not be involved, and my Python script is as error prone as using AHK.
Think of AHK as similar to a compiler + linker. By rejecting AHK because someone can write a program that could screw things up, you might as well just prevent people from writing scripts and compiling programs.
> I'm not saying a bunch of people typing are error prone, if that's your take on my post. I just think that there's a VERY different set of risks (and therefore mitigations) between a distributed manual process and a large scale automated one.
You've essentially argued that IT should oppose any automation that is not thoroughly tested. And how will they determine how well it is tested? Do they have those skills?
Where I work, IT is more concerned about security (viruses, theft, etc), licensing, and things that can break the machine. They don't prevent people from using APIs to mass edit databases as long as you do it to data you own or have permission from the owner. They don't own the data, so you're free to screw it up if you're careless. Ensuring my program is bug free and well tested is the job of my team/org/data owners, not IT.
You're merely pointing out that this IT person has been given more power than his skills warrant.
Re: In Praise of AutoHotKey
#100Earlier quoted context omitted.
Not at all. He could have written his own program and just used it, and IT would never have gotten involved. Because it was using a 3rd party tool, IT got lazy. My company, BTW, not only explicitly allows AHK, they actually encourage it. I mean, if you're going to give people compilers to write arbitrary code, this is not worse.
It seems weird to expect someone with no programming training (an IT guy) to either build or sign off on something they have no understanding of. In large/high stakes settings, being risk averse and knowing the limits of your understanding are very good traits. Imho, this IT guy did his job, more or less. What was the testing plan for this AHK script? What edge cases were considered? Unit tests, integ tests.... was t…
Exactly.
A lot of programmers, or programming enthusiasts, thumb their nose at IT staff who naturally push back on stuff like this. In their mind, to play devil's advocate, they're seeing IT as unnecessarily burdensome, and getting in the way of automation.
The IT staff are probably naturally welcoming to the general idea of automation. However, to elevate something up from an off the cuff script that's described as "depraved" to the level of an actual business tool that can be relied upon, is a HUGE time and money sink. Validation is a very complex problem as you have described. This is the difference between consumer and enterprise hardware. If business management isn't setting this as a priority for IT, and if IT is already overwhelmed with the "known" quantities of work, then it just isn't practical to officially adopt.
I see it like this: It takes 1 "effort point" for a data entry staffer to manually enter the information tediously. It takes 10 effort points for the same staffer to write the AHK script to automate it. (Good for the staffer, assuming there's no flaws, and their reward is a longer lunch break.) To truly validate an automation as a business tool would take something on the scale of 150 to 200 effort points and involve lots of conversation - assuming there even is a framework for new tool validation established that can be used. IT knew this and made the right call. If company management wants to adopt a new tool without research and validation, that can be reckless.