search alt keys on mac
Closed this issue · 30 comments
I'm on chrome-latest on an m2 mac.
The new search help says that alf-f will focus on the search bar. There is no alt on mac, so I tried option-f. Nothing happens.
ProductName: macOS
ProductVersion: 13.4
BuildVersion: 22F66
@finanalyst, can you point me at the code where you're binding alt-f?
@coke Website/plugins/page-styling/page-styling.js the listener is attached at line 145, the check for the keys pressed are at line 132, and the object containing the keystrokes are set at line 81.
The aim is to have a form in a modal so that the object values can be set by a user.
Looked into this a little bit. On my mac, pressing Alt+F (i.e. option+f) returns the character ƒ for e.key. Since this is being compared with f from this line, it doesn't match and thus does not focus the search box.
The deprecated which property is more consistent but I'm hesitant to recommend that since its deprecated.
Another option is to use the / or some other single key which avoids the modifier keys entirely.
@coke @opoku I think the most general solution will be to create a config popup for short cut keys. The problem with hard-coding alternatives for each OS is that there will always be a catchup maintenance issues whenever something changes in one or other OS.
If the aim is to have a generic config, then the options-search plugin shows how to create one, as in a modal window. However, the options-search only controls the search functionality. The short-cut keys that are needed are for the site as a whole.
I think the approach here should be to create a series of custom events, which are listened for by the various plugins that handle Search, Toc, Change of Theme, etc. Then the custom config for the shortcuts can associate keyboard input with the custom events.
I feel like this is being made more complicated. I wonder if there is a simpler way to react to the modifier.
- Since Mac is so widespread, I agree that a simple fix for Mac is needed.
- I have looked into this further for Mac. I don't have a Mac available to test with, so I'll need some help
- According to Stackoverflow the problem is complex for Mac OS. There is a library suggested in one of the answers, but some sample code that simulates the set up in page-styling would help me.
- According to MS doc about metakey JS can pick up the metakey from Mac and Windows. Suppose we make
.metakeyand.altkeyalternatives? - I'll try to get this working on new-raku for you to test soon.
Whatever is on new-raku now has stolen the default command-F == search in page, which is broken.
Experiencing the same here. Trying to bind the meta/command key is a bit of a whack-a-mole. meta-t is the universal mac shortcut for new tab.
FWIW, Github also binds / to the search. It's not an uncommon pattern. I think Gmail also uses it. In general, I think avoiding keyboard modifiers (like alt/meta/ctrl) works more universally and avoids messing with existing browser / OS bindings.
Edit: MDN also uses it.
@coke What is the default Command-F action on Mac? The default Ctrl-F in Firefox on Ubuntu is to search the current page, with a search entry bar at the bottom of the window.
Suppose we have allow for any character (without metaKey, AltKey, or CtrlKey) in the main window to switch focus and for the character to be the first in the search string? Then searching starts by inputting the search term. All the other altKey shortcuts can be switched off as happens now.
@finanalyst The default behavior for Command-F is the same as Control-F on other OSs. It activates the find in page bar at the bottom of the page. In general, most command key modifier bindings on Mac are equivalent to control key bindings on other OSs.
@finanalyst Starting search on any key is an interesting idea. That could work too but also feels a bit heavy handed. I would prefer only the / key activating the search bar (without also being the first character in the search) because it leaves the possibility of other single keys triggering other actions. E.g. ? to trigger help/settings popup, t to toggle theme etc.
Is there a default behavior for Firefox on Ubuntu associated with /?
@opoku How does the new-raku page feel on a Mac?
No reason for \ on new-raku. I used it instead of your suggested / by mistake.
No reason why ? = settings t=theme c=Table of Contents / search focus. Actually this sounds like a good idea. @coke @cfa @2colours thoughts?
@finanalyst It feels fine actually. One odd thing is that the first time (after a refresh), \ only focuses the search input. If I clicked out of the search input and then typed \ again, the search input is focused but the \ also appears as the first character.
Shortcuts like this have been suggested in the past and rejected by some community members. I'm OK with them.
@coke @opoku I tried implementing other chars for shortcuts.
The problem is the effect on the search entry boxes. Typing \ (/) when in the search box is fine. \ / is unlikely for filtering in the TOC box. But 't' 'c' 's' when in a search box should not have a side effect on the main window.
How to stop the side effect is - I am afraid - too much for me at present.
So for Mac Users, I can implement / for search focus, but the other things will need to wait.
Just tried /, but on Firefox, it has a default and raises the window search function. So it will have to be \
This is now on new-raku. I'll create a PR to do this for docs.raku.org
Well my opinion hasn't really changed with regards to punctuation marks/non-alphanumeric ascii characters as browser shortcuts, and / for search in particular.
I perceive it as a heavily anglocentric (US keyboard centric) convention. Out of the keyboard layouts I've had any business with, German, Czech and my native Hungarian keyboard layout all have the slash as a shift combo character. (Seems like the same is true for French AZERTY as well.) For me, it is shift+6, to be precise; less convenient or memorable than any usual well-reasoned shortcut.
Moreover, out of the three sites named, only MDN seems to actually respect the slash character for search! Gmail doesn't even propose it in any way and Github, while proposes it, doesn't react to it in any way with any focus (inb4 no, I didn't forget to click out of the input). Well, right, I could use the num pad, that could work... the num pad that I don't use for anything otherwise and isn't super ergonomic.
I don't feel much helped with a shortcut that is so anglocentric that it literally doesn't work on layouts that don't have a dedicated key for slash (which I kind of find useless anyway, to be honest). Of course I can't single-handedly prevent it but from all I know, Raku was meant to be very inclusive technology so standing by a convention that revolves so much around the (otherwise rather wasteful) US QWERTY layout would actually seem a little weird in my opinion.
Thanks for your perspective @2colours. I agree here. I didn't realize how anglocentric / actually was. Would just s or f then work better for search? And in my brief review, the , character is reasonably pervasive across the different keyboard layouts. Maybe that could be used for settings? command/meta + , is pretty comment for settings on mac.
@2colours I appreciate the point of view that the key choice is sensitive to the keyboard layout. I wouldn't call it 'anglocentric' so much as Querty-centric, although I accept that keyboard layouts are related to language issues (GB English keyboards also differ from US ones). But that's really another topic.
The question here is how to make Alt-type keyboard short cuts available to Mac. The following solutions have been suggested:
1.Solve the JS problem related to trapping 'Option' keys and integrating the solution into the 'page-styling.js' script that drives our web-site
- I think there are solutions out there, but I don't have the time to sort it out.
- Create a single character (one without a transform key) that will work across all keyboard layouts
- one issue discussed here is that we should choose keyboard shortcuts that are somehow 'standard' so that common work-flows are easy to adapt to this website.
- The complicating factor here is to ensure that if a single character is used, it can be constrained to the main window only and not affect the search entry areas.
- Even if a single character is chosen to get search focus, it will not affect search, but it will affect the filter in the Table of Contents.
- Consequently, a non-identifier character is best such as
/or\or¬. Work-flow proponents suggested/but that is not convenient for non-Querty keyboards. - We could simply choose a character by consensus, and let that be it for this website.
- Refactor the website UI so that a user can choose which ever key combinations work for them.
- This is my preferred solution, but I don't have the time to deal with it now.
I am willing to help anyone who chooses to do any of the above.
I have demonstrated that a choice of \ works on new-raku.
I would insist that QWERTY is not a good characterisation, unless one really means the US QWERTY-inspired layouts, often called "programmer layouts". (For what it's worth, I think they suck even at that because the dash is at a ridiculously uncomfortable position.) The Czech layout I mentioned is QWERTY, the Hungarian and German layouts are QWERTZ which doesn't sound like a relevant difference. On the other hand, one could perfectly compose a completely different English layout that still has loads of non-alphanumeric characters on separate keys (Dvorak is actually like that).
As a general principle, I don't think there should be any assumptions about the position of non-alphanumeric characters. Some of them might use altgr or even shift AND altgr in which case they might even interfere with ctrl+alt keyboard combos, depending on the way of keystroke detection.
@2colours OK I'll grant QUERTY is perhaps not the best characterisation of a real problem related to keyboards and layouts. But that it is not the problem at issue here.
Mac users reasonably ask for short-cuts that mimic the Alt-S / K / T / G short-cuts for this site.
Since I'm not a Mac user and in general that's a small club compared to PC users, I wouldn't know the variety of keyboards for Mac. If there are different layouts for Mac, I can imagine that the same points about being skeptical of non-alphanumeric shortcuts can apply.
@finanalyst I'm happy to take a crack at your option 2 above and look into avoiding the issues you outlined. Did you have a branch pushed to the repo with your experiments? nvm I see that you have make_backslash_shortcut_for_search_focus pushed. I'll take a look this weekend.
@opoku Sorry I did not respond in time for the weekend. The branch for doc-website has a minor change, just listening for a \ character. I did more work on the page-styling plugin in another repo, called finanalyst/collection-plugin-development on git hub. The relevant plugin is at lib/plugins/html/page-styling.
The JS script looks at a local storage for which Alt/Ctr/letter keys are registered (the code is to prepare for a more generic configuration). The initial default config is at about line 80.
Then every key press is scanned for these combinations in an Event Listener at around line 129
The problem is finding a way to trap the 'Option' key with a Mac, and treat it as if it were and 'altKey'. at around line 133.
According to the MS documentation site, 'e.altKey' should be true when 'Option' is held down and another key pressed on a Mac. There appears to be some extra code that can be used to ensure this happens, and my thought was to modify the Listener callback at around line 132.
But that's as far as I could go, because I dont have access to a Mac to test code on.
@finanalyst I've created a PR with some experiments that solve the problem in a few different ways. I'd appreciate your feedback on this work.
@opoku Thank you for your contribution.
Closed as completed