Information and entertainment are less scarce today than the 1960s. Expensive is not just relative to what it used to cost, but also relative to value.
As a counterpoint, perhaps there is a sort of "natural selection" which will drive better abstractions due to being more token-efficient. Albeit perhaps a relatively smaller effect.
Thanks for building this. Cmd-` broke in 2009 and has never been repaired. I'm frustrated by it on a daily basis. Two things:
1. Animation when switching windows is jarring. I'd have to record the screen and play it back frame by frame to properly explain what's happening. This is on MacOS 26.3.1(a) on a new device.
2. I use backward cycling all the time! I'm the sort of person who has tons of windows open after a little while, mostly browser windows but not exclusively. I would love to see that added.
Thank you for sharing this. I'm going to test drive and see if it's reliable enough to run full time because it's pretty important to me that this functionality work as it was once intended. I'll buy you a beer if we ever land next to each other at a bar.
Edit: stopped responding to kbd shortcut just a few minutes later. However, works when I use Shift as a modifier. I set the shortcut to Cmd-`, fwiw if trying to reproduce.
Edit2: just entered a state where invoking the kbd shortcut caused every open window for the frontmost app to cycle through.
Outstanding! Thank you. I was noticing how I'm having to retrain myself to make this shortcut a first-class tool now that it's working reliably. I didn't realize how much I'd conditioned myself to avoid it. It's nice having this workflow back.
Just wanted to note that today I found myself using both directions of the shortcut between terminal windows and was genuinely delighted to be reminded that it's working properly again after a decade and a half!
I found that Sash forward switching works about 97% of the time, but still occasionally has a hiccup. Have not been able to pinpoint a cause yet, but I find that even in that case the reverse shortcut still works.
Even without that, I find myself using the reverse shortcut more than I thought I would, so that was a good suggestion.
@apt-apt-apt-apt pointed out in a separate comment that:
>A simple translation of keywords seems straightforward, I wonder why it's not standard.
I replied that for Japanese at least, probably due to symbol input being too tedious. However I think it's worth mentioning a potential mitigation, and maybe even an advantage.
As a mitigation, full-width symbols could be used instead, which are typically the default in Japanese input. Japanese itself is also fixed-width so if done across the board the language itself becomes fixed-width, not just by virtue of a font selection.
As an advantage, some logical symbols, greek letters, other rare characters are easy to input in Japanese mode, and this could lend itself to a more symbol-heavy language design. I already take advantage of this myself with Δ, φ, and τ use selectively in a few projects. Symbols with easy entry may differ by OS, but here are a few other examples that could be useful:
Japanese input system do allow use of arbitrary UTF-8 symbols, but you have to type out the "pronunciation" for symbols, e.g. "nottoiko-ru" for ≠, "goudou" for ≡, "yueni" for ∴, "ramuda" for λ, etc. Just using "!=" is faster.
In case it was not clear, that is exactly my point: a language designed for Japanese could open up the possibility of incorporating symbols other than those readily available on QWERTY keyboards.
And my other point is that != is _harder_ to type in Japanese input mode because you constantly have to manage full-width vs half-width input.
I can't speak to Korean, but thinking about Japanese, one probable reason it wouldn't catch on is how tedious and inefficient it would be to constantly switch between input modes. Japanese input mode is designed for prose, and isn't well-suited to efficiently entering the symbols commonly used in programming. Even spaces. It results in needing a lot of extra keystrokes.
reply