I'm currently building resheet.dev, a notion-spreadsheet-hybrid. Started because I often ran into limitations with Notion and with spreadsheets. In Notion I wanted to be able to just do some calculations (or even have some embedded spreadsheet). Spreadsheets are nice, but I always ran into limitations. I always thought these could easily be overcome by having a more feature-complete programming language. Because I previously failed very hard by being too ambitious, I tried to keep this project simple. ReSheet runs JavaScript with React because of the vast ecosystem and wide adoption.
It was important to me that it's core is simple and extensible: Everything revolves around the concept of a "Block", which can be thought of like a cell in a spreadsheet. Blocks can be nested and you're able to write and then use your custom Block completely in ReSheet itself. As ReSheet itself is just one big Block you can embed ReSheet in itself.
Maybe sometime in the future I'll get to work on a Block for visual and interactive programming, but currently I'm trying to get it reliably working and useful in the current state.
I'd love to hear your feedback and to answer any questions! (Documentation is still lacking. Currently working on adding some example documents (in ReSheet) to better show what's possible)
I'm wondering why there is a keyboard calibration wizard. Everything else on the web works without calibration.
Problem is: Ctrl+? for example is a different combination in different keyboard layouts. I wanted to keep the "?" constant, not the physical keys which have to be pressed. The latter would be possible without the wizard. And I didn't want to maintain different shortcut settings for different layouts. So this was the easiest solution I could come up with. 🤷♂️ It would be almost possible without, but a tiny detail in the keyboard event handling makes this necessary: On a US layout Shift+/ is "?" and is reported as event.key === '?' , but as soon as I add another modifier, like Meta+Shift+/ I get event.key === '/'
I suspect others either just use the physical location to determine the shortcut or they maintain different shortcut mappings for different keyboard layouts.
I see. As a user, the latter is what I want anyway. The fact that character mapped to Shift-'/' does not equal the character mapped to Meta-Shift-'/' is not a mistake and needs not be corrected. As soon as you add another modifier, you're in a different and unrelated group in the keyboard layout, and you can't assume that the Meta-Shift group equals the Shift group.
There's really no such thing as Control-'?' . When I see such a key binding, it confuses me, and I think it was made by some American who has a question mark key on their keyboard, and I assume it's not accessible to me. The key binding is really Control-Shift-'/' , regardless of whether Shift-'/' happens to type a question mark.
Keyboard layouts vary in what modifiers need to be pressed. Imagine you have the key binding Shift-'1' , and then someone comes with a Czech keyboard, which requires holding Shift to type digits, and then the key binding becomes the nonsensical Shift-Shift-'+' .
Here's an excerpt from a handbook I'm writing in text editor design:
Key bindings should be the actual keys on the keyboard, not the characters the keys type after applying a keyboard layout that may change due to locale and user preference. Control-z should be the same place on the keyboard regardless of whether the keyboard layout causes the z key to type the character z (English), y (German), w (French), Я (Russian) or ; (Dvorak).
Regarding your example on Ctrl-z: It is mostly practice that it still is Ctrl-z on a german keyboard, even though it is a different location. Without judging if this was a good design in the first place, I think it's not unreasonable to follow this practice.
Your example with the Czech keyboard layout is one of the cases I avoid with this design: Neither do I have Shift-'/' nor do I have Shift-'1' as a keybinding.
Another note: I'm not sure if/where you're speaking of '/' as the key in any keyboard layout that generates a '/' , or if you mean the key location, that generates a '/' on a US layout. If you were only speaking of the former, then your remark about Control-Shift-'/' has the same problem as you described in your Czech example: On a german keyboard '/' is typed by pressing Shift-'7' , so there is no Shift-'/' as this would be Shift-Shift-'/' .
The part about not being clear enough how Control-'?' can be typed is indeed something I have to clarify in the app.
I'm also not super-invested in the way I solved this. I may change it in the future. It was just the option that seemed most sensible to me under the circumstances I had. (Which included how much time I want to invest, does it work cross-keyboard-layout, how do I display the shortcut, do I have memorable shortcuts, etc)
It is mostly practice that it still is Ctrl-z on a german keyboard, even though it is a different location.
Which is a practice that annoys me every time. Even more so the Vim style directional keys j , k , l , ; , a variation of which is present in your app.
Your example with the Czech keyboard layout is one of the cases I avoid with this design
Even if you never bind the digit keys, you'll still have problems with Russian layouts among others that don't have the letters a to z . I used to have a keyboard layout where a question mark is typed with the Alt Gr modifier, which the calibration wizard does not support at all.
I'm not sure if/where you're speaking of
'/'as the key in any keyboard layout that generates a'/', or if you mean the key location, that generates a'/'on a US layout.
I wasn't generalizing this particular example beyond the US layout, so the distinction doesn't matter. When generalizing, my suggestion is to bind keys to actual locations every time.
I see, you're right, my approach still has limitations. When I have time, I need to work on that.