undefined | Better HN

0 pointseviks2y ago0 comments

Yeah, the fact that you've never tried Karabiner explains a lot of why you keep wrongly insisting things are impossible

> Swap Control/Option ... the new binds work correctly

That means the web app knows. Or do you want it to show the wrong keycap labels instead of the correct key function names?

> Well, you can't get rid of Command-C for copy

You can. Depending on the terminal you can do it either in the app or in Karabiner

> can't get the "copy on select" behavior

Think that's also possible, maybe not in iTerm, though how is this relevant when we're talking about keybinds? Obviously you can't have two functions per key 100% (below 100% you can have context-dependency like selection), so I don't understand what your perfect baseline is? No matter where control physically is you'll still have this issue that you can't use it to copy and cancel in the same context, so the fact that you'd need to resolve a conflict in Cmd is not an argument for any position.

> but Vim's isn't

But you can detect vim and use Cmd+C to pass Ctrl+C to it, so you'd retain vim's dumb behaviour just like you'd have with the original Ctrl+C, so there is no functional improvement, just ergonomic one (though this is more complicated)

>lose the app's bind, and you don't always have a way to get it back

you can always send the original Ctrl+C key event instead of "Copy" with a different keybind, so you'd retain that function

> You can't have it both ways. Either rebinding is easy or there are many clashes.

I can:

1. It's relatively easy in one case of the terminal app where you move Ctrl+X keybinds to Cmd+X and resolve a few conflicts

2. There are many clashes if you do it another way and move keys around at the OS level. And the amount of clashes is OS-dependent, and the reason it is due to Alt (including Mac's Alt)

> Great, the Alt you were talking about is for PC keyboards. That's what I thought; dunno why we had to go deep into like, API docs for macOS. Sometimes people goof! That's OK! Now I see what you meant here.

Unfortunately, you're still confused, but trying to persist in your mistake too hard to notice. I meant both keys (Mac's Alt and Win's Alt), and the fact that they serve different functions on different OS explains how "defaults matter even if you change them", that's how Alt (includings Mac's) is relevant

(also, it's not API docs, it's general user keyboard shortcuts help, why do you need to make even these things up?)

0 comments

3 comments · 1 top-level

camgunz2y ago· 2 in thread

Just as a meta point here, you're really digging in to something that's pretty trivial. We're way to the right of the comments about... honestly I don't even know what. You're being condescending, sarcastic and pedantic. I'm not really even sure what you're trying to convince me of; can you plainly state your argument? Maybe you're deep into score points in an internet argument mode; if so I respectfully suggest pulling up a little.

> Yeah, the fact that you've never tried Karabiner explains a lot of why you keep wrongly insisting things are impossible

Huh I don't think I said anything's impossible. I've said things will clash or will be a lot of work, but in software all things are possible. I've been trying to define parameters around what you're saying. This is why I've been saying stuff like "if rebinding is an option then why do key layouts matter", which you've yet to explain. If installing 3rd party software and spending tons of time configuring it is an option, I think key layouts matter even less. I'm confused because you've yet to take a clear position on anything, instead you take small, generally inaccurate swipes at trivial stuff I write.

>> Swap Control/Option ... the new binds work correctly

> That means the web app knows.

No, it means the OS is passing different key codes to the browser.

> Or do you want it to show the wrong keycap labels instead of the correct key function names?

When I swap Ctrl and Option, I want Google Docs to show Option when it would have shown Ctrl. That's how I'd know the webapp "knows". But it doesn't, hence why I listed it as a drawback of rebinding.

>> Well, you can't get rid of Command-C for copy

> You can. Depending on the terminal you can do it either in the app or in Karabiner

How do I do this in iTerm2, a super popular terminal emulator for macOS? It only has a keybinding option for Paste and that only lets you create a bind. I don't see how I would use this to disable Command-C for copy. Again I'm not saying it's impossible--I thing I feel like I now have to say. You could hex edit the binary! You could redirect gamma rays to minute parts of your hard drive! I'm saying in the finite amount of time I'd want to spend on something like this, it doesn't seem straightforward.

>> can't get the "copy on select" behavior

> Think that's also possible, maybe not in iTerm, though how is this relevant when we're talking about keybinds?

Isn't the whole point to "rebind it to make your experience 100% consistent"? You must have meant "consistent with other OSes". The reason Linux does copy on select is that's its solve for "Ctrl-C is cancel".

> No matter where control physically is you'll still have this issue that you can't use it to copy and cancel in the same context...

Phew! It took a while but, this is what I've been saying. Glad we agree.

> ...so the fact that you'd need to resolve a conflict in Cmd is not an argument for any position

It's the whole problem! macOS solves the "Ctrl-C is cancel" problem in terminals by having a whole different key for it. If you scooch it over to Cmd you'll find a host of problems that are irritating to resolve, which we're currently discussing, albeit in a super awkward way.

> But you can detect vim and use Cmd+C to pass Ctrl+C to it, so you'd retain vim's dumb behaviour

Woof this is a hot take. Vim's behavior isn't "dumb", it just isn't anticipating your super weird rebinding strategy. Also I don't know what you mean by "detect vim".

>>lose the app's bind, and you don't always have a way to get it back

> you can always send the original Ctrl+C key event instead of "Copy" with a different keybind, so you'd retain that function

Of course; there's always something you can do. That's why I said "My point is that it's always gonna be a little imperfect and maybe a lot of work." But, in this case I don't think it's super straightforward. If you bind Cmd+S to Copy and then open up VLC you'll see there's no shortcut to save a playlist. Dunno what you would do about that.

> 1. It's relatively easy in one case of the terminal app where you move Ctrl+X keybinds to Cmd+X and resolve a few conflicts

I can't see a way to do any of this in iTerm2 or Terminal.app.

> 2. There are many clashes if you do it another way and move keys around at the OS level. And the amount of clashes is OS-dependent, and the reason it is due to Alt (including Mac's Alt)

Agree, but since this doesn't seem possible in the most popular terminal apps for macOS, I think this is what most people are forced into.

> (also, it's not API docs, it's general user keyboard shortcuts help, why do you need to make even these things up?)

Sorry then, what did you mean by "docs" here: "It is a literal (as in both printed on the key and referenced in the OS/docs) key on a Mac keyboard". I'm not making anything up; I'm genuinely trying to understand what you're saying, which after you being wrong, self-contradictory, and moving the goalposts for days seems to be: "Cmd's position is more convenient for the operations other OSes use Ctrl for, and you can spend a lot of time in Karabiner if you want it to function consistently with other OSes".

eviksOP2y ago

> This is why I've been saying stuff like "if rebinding is an option then why do key layouts matter", which you've yet to explain.

I've explained it several times, yet you keep ignoring the complexity in your trivialized binary option: the amount of effort differs even if rebinding is an option, so key layouts still matter

> If installing 3rd party software and spending tons of time configuring it is an option, I think key layouts matter even less.

For the same reason it actually matters: to reduce the amount of time spent

If you keep ignoring these simple facts you'll never get past your confused state of "weird to hear this so often. Macs also have the same" etc. or...

> I'm confused because you've yet to take a clear position on anything, instead you take small, generally inaccurate swipes at trivial stuff I write.

Which parts of the "better design ... more convenient thumb" confuse you? The swipes are also generaly accurate, thus you keep trying to do all the meta instead of addressing them directly.

> Sorry then, what did you mean by "docs" here

Company's keybinding help web page? You're making it up by trying to move the goalpost to narrower scope of "newer hardware" or "API docs"

> seems to be: "Cmd's position is more convenient for the operations other OSes use Ctrl for, and you can spend a lot of time in Karabiner if you want it to function consistently with other OSes".

That's also something you've made up again, on both points.

1. You can spend very little time with a few tweaks (like using a different keybind to cancel in the terminal). You need to spend a lot of time only if you insist on better matching the original conflicting design. But even then, the amount of time depends on the layout/OS

2. And no, it's not about consistency with other OS since the better design of Cmd on a Mac is NOT consistent with Windows. The goal is to achieve consistency WITHIN the OS so you can, for example, use the same key combo to copy in all apps

camgunz2y ago

> I've explained it several times, yet you keep ignoring the complexity in your trivialized binary option: the amount of effort differs even if rebinding is an option, so key layouts still matter

Oh, I didn't consider this because it's super obvious, and also the presumption of the whole thread (switching Fn/Ctrl) until you entered it. What's the value in pointing this out yet again?

>> you take small, generally inaccurate swipes at trivial stuff I write

> The swipes are also generaly accurate, thus you keep trying to do all the meta instead of addressing them directly.

Of course you write this in a post where you again only pull out very small things in my previous post, and engage with none of my larger points:

- It doesn't seem like any of your suggestions are possible

- even if they are with something like Karabiner, "My point is that it's always gonna be a little imperfect and maybe a lot of work"

>> Sorry then, what did you mean by "docs" here

> Company's keybinding help web page? You're making it up by trying to move the goalpost to narrower scope of "newer hardware" or "API docs"

No, all I'm saying is that going from "docs" to "API docs" on a site like HN isn't a big leap, and I was just making an off-hand remark that you've dug into multiple times now.

> 1. You can spend very little time with a few tweaks (like using a different keybind to cancel in the terminal).

You've not responded to my questions about specifics on this for either Terminal.app or iTerm2. I'm forced to conclude you don't actually know how to do this, if it's even possible. Also FWIW "using a different keybind to cancel" isn't something you've suggested before, which I know can be done in config files. You've only gestured vaguely at some context-dependent logic and rebinding Copy.

> 2. And no, it's not about consistency with other OS since the better design of Cmd on a Mac is NOT consistent with Windows. The goal is to achieve consistency WITHIN the OS so you can, for example, use the same key combo to copy in all apps

You can't really mean this. Are there macOS apps where Cmd-C isn't copy and adjusting the binds in System Preferences or Karabiner will fix it? I find that hard to believe.

1 more reply

j / k navigate · click thread line to collapse