dwg

Same logic applies internationally.

Glad to hear it!

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.

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.

Added reverse hotkey setting (defaults to none).

Jitteriness has also been addressed.

New release available on GitHub. Please set the forward shortcut again too.

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.

Glad you find it useful.

I found cmd+backtick broke in many other situations too. Was driving me mad.

Didn't think reverse cycling was worth it since most apps only have a few windows open. Any use case you have in mind?

Wish I had the courage to do this too.

what are the default values, in case someone wants to restore them?

Love the irony: Man builds a Gemini-style feed aggregator for small web, finding it, well, not so small.

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.

@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:

≠, ≡, ∞, ∴, λ, θ, α, β, ・, °, ※

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.

Your choices are not limited to one extreme or the other.