Am eagerly anticipating the commercial availability of Mathpad.
At the moment I'm using Espanso, an open source software that lets users map typed character sequences to unicode. So it's possible to set things up in such a way that typing the character sequence ";" "a" ";" makes Espanso replace the entire ;a; string with the greek symbol alpha α.
Symbols like ⇒ that can kind of be "drawn" with common keyboard characters "=" ">" is possibly nice to be mapped to the character sequence ;=>; This is a personal preference inspired by Typst's math notation design choice.
I prefer using a Compose key [0] (remapped Caps Lock, for me), which can be installed/configured on all major platforms. Configuration is sharable via XCompose configuration files.
I like Vim's digraphs, which go in a similar direction. For instance, Ctrl-K = > gives ⇒, Ctrl-K a * gives α. An overview of available digraphs is available at :digraphs.
Otherwise I like the Agda input method of Emacs, where \to gives ⇒ and \alpha (or \Ga) gives α.
Somewhat predictably zsh also has a digraphs¹ feature, via the insert-composed-char function². Supported characters can be seen in source³, and beyond that there is the insert-unicode-char² function for when you need it.
I flit between regular compose key input and zsh/vim digraphs in a way that makes no sense to me whatsoever. Compose ^1, AltGr+1 or C-k 1S all kind of feel natural to me, but the advantage of the ZLE method is that you can also use it to preview characters which can be useful if you want to test something out while in another widget or find the hex value to insert using some other tool.
I use qwerty-fr [0] for this. It's pretty nice, since it works on all three major OSes and is basically a few compose layers on top of a US base layout. I use it to type greek letters, swedish vowels, italian accents and math symbols. A couple of non-breaking spaces are also there. It's the only layout I use nowadays.
I have rofimoji[0] bound to a key chord in i3wm and configured it in such a way that it allows me to enter not just the usual emojis but also common math symbols. Works like a charm!
Interesting idea! Though since it doesn't have a more ergonomic keypad-like layout, but repeats the slanted mistake of default keyboards, and requires software companion, what's the advantage over adding math layers to your current keyboard, where you also have access to more keys and modifiers?
Seconded. This looks like a fun toy, but it solves a problem that I don't have (and I believe I am the target audience). Modern typesetters are very good (e.g., TexMacs). There is also a limited set of characters by design, and I would have to remove my hand from my keyboard only for those.
it is frustrating that nowhere does it tell how it actually works. generally keyboards can not send specific unicode codepoints to host system, they only send scancodes that get interpreted by operating systems keymap. But most keymaps do not define any keys for these symbols, so there is something going on here. Based on the docs, I'll guess it attempts to send a sequence of keypresses to trigger some compose mode (thus requiring additional software on windows). I find such hacks slightly frustrating because they are so fragile, they depend on the keyboard predicting perfectly how the host will handle the keypress sequences which obviously can break quite easily, e.g. simply by switching layouts or having some timing/focus related aspects.
I would really love to see new keyboard HID designed specifically for modern advanced keyboards (qmk etc) where you wouldn't need to resort on this kind of trickery. Or alternatively make the input stacks of OSs more easily configurable with custom physical layouts and modifiers etc instead of assuming that all keyboards follow basic ISO/ANSI layout.
Ya, I was right. The driver is built around popular QMK framework. Here you can read how it handles unicode input: https://docs.qmk.fm/features/unicode.
It's likely the driver handling the conversion. Which makes me wonder, can I use the same driver to remap extra keys on my existing QMK compatible keyboard?
I'd pay money for one of these, if it had the keys which I want, which this one doesn't. I think the trick would be to somehow make it customizable, but I'm not sure the best way to do that. Parametrized PCB design? 3d printing?
I'm not quite sure, but my dream would be smaller buttons, coarsely modelled on the HP48-style keypad. I can't imagine many people share that dream, but I've wanted to make that for a long, long time.
Coincidentally, you get a long ways there by simple adding a Greek keyboard layout. You hit meta-space, and ασδζχψ. meta-space, and back to normal.
Foreign-language keyboard under GNU/Linux also have a layer with many convenient math keys (²·≈·¾ all exist natively in my normal layout).
A smaller win for me would be to simply print all of that on my keycaps.
You should try building one for yourself, I did [1] and it’s easier than you’d think. I made mine just a basic numpad but I really like the idea of turning it into a tool to enter math symbols.. guess I know what my next project is, thanks for the inspiration!
This one is customisable. The firmware uses QMK, so you can remap it however you like. You'd need to make some key label stickers in Inkscape or something if you want the keys to show the characters.
or used a stylus and the drawing input in TeXview.app on my NeXT Cube or https://www.inftyproject.org/en/software.html --- since then, didn't Microsoft's Journal and various other stylus note-taking apps get math support?
These days I just press the touch keyboard icon in the task bar and use that to get special characters.
A further concern is one has to be entering things more than just as a lineal stream --- superscripts and subscripts need to be entered into, things need to be put over or under a fraction bar, &c. --- do the hard-wired buttons actually accelerate things that much?
Why not just use a programmable keypad such as a Streamdeck?
I love the idea of a physical device (esp. with buttons) but I get that it is not always practical. I wonder how much work it would take to add math symbols to something like Touch Portal. I haven't used it but read that many people do for controlling various software, including DAWs (which can be latency-sensitive).
I bought a 25 key pad that is collecting dust. Not worth it for me to have an extra keyboard taking up space on my desk, may as well use LaTeX or alt codes
Not bad, curious about price, but as noted by others in thread, the only really special thing are the keycaps, given those you could replicate functionality on any ZMK/QMK keyboard. I might try this as a layer of a glove 80 or ZSA voyager, s.t. like that
This is super cool. When I was doing a lot of math-related typesetting I found that I got really fast with Emacs + AuCTeX. I have no idea of the state of that project, but if you were fast you go at nearly the speed at which you could write.
It looks nice, but I'm not sure I'd jump ship from my snippets setup I have with vim. At the end of the day it would be very similar to a mouse hand movement and would probably take a long time to get it as quick and comfortable as just typing "aa" for alpha when I'm in math mode which I get into with "mk"
I definitely understand why macro-expander programs can be useful, but I'm always a bit puzzled about the idea of combining them with a macro language like (La)TeX. Why introduce two layers of macro indirection? Maybe it just doesn't fit my use case, which doesn't mean it can't fit anybody's; but, more intriguingly, maybe it would come to fit my use case if I understood what it can add, so I wonder if you could describe how it's useful to you.
TeX already has more than enough layers of macro indirection :/
Try debugging an \makeatletter\expandafter and you're going to have a bad day. I think the macro system is even Turing-complete in some sense, certainly the number of times you potentially need to run TeX to guarantee a complete output reduces to the halting problem.
> TeX already has more than enough layers of macro indirection :/
Sure, I should have said "another layer of macro indirection" instead of just two!
> Try debugging an \makeatletter\expandafter and you're going to have a bad day. I think the macro system is even Turing-complete in some sense, certainly the number of times you potentially need to run TeX to guarantee a complete output reduces to the halting problem.
So is the indirect (har!) answer that, for you, which I know isn't the same as the person I was originally responding to, introducing the new macro layer allows you to replace some of the TeX-level indirection by a more concretely understandable macro expander?
(By the way, you are right that TeX's macro system is Turing-complete, not just incidentally but intentionally; Knuth didn't plan to make it so, but did so by request from Steele.)
Am eagerly anticipating the commercial availability of Mathpad.
At the moment I'm using Espanso, an open source software that lets users map typed character sequences to unicode. So it's possible to set things up in such a way that typing the character sequence ";" "a" ";" makes Espanso replace the entire ;a; string with the greek symbol alpha α.
Symbols like ⇒ that can kind of be "drawn" with common keyboard characters "=" ">" is possibly nice to be mapped to the character sequence ;=>; This is a personal preference inspired by Typst's math notation design choice.
I prefer using a Compose key [0] (remapped Caps Lock, for me), which can be installed/configured on all major platforms. Configuration is sharable via XCompose configuration files.
[0] https://en.wikipedia.org/wiki/Compose_key
I like Vim's digraphs, which go in a similar direction. For instance, Ctrl-K = > gives ⇒, Ctrl-K a * gives α. An overview of available digraphs is available at :digraphs.
Otherwise I like the Agda input method of Emacs, where \to gives ⇒ and \alpha (or \Ga) gives α.
Somewhat predictably zsh also has a digraphs¹ feature, via the insert-composed-char function². Supported characters can be seen in source³, and beyond that there is the insert-unicode-char² function for when you need it.
I flit between regular compose key input and zsh/vim digraphs in a way that makes no sense to me whatsoever. Compose ^1, AltGr+1 or C-k 1S all kind of feel natural to me, but the advantage of the ZLE method is that you can also use it to preview characters which can be useful if you want to test something out while in another widget or find the hex value to insert using some other tool.
¹ https://datatracker.ietf.org/doc/html/rfc1345#section-2.3
² https://zsh.sourceforge.io/Doc/Release/User-Contributions.ht...
³ https://github.com/zsh-users/zsh/blob/master/Functions/Zle/d...
I use qwerty-fr [0] for this. It's pretty nice, since it works on all three major OSes and is basically a few compose layers on top of a US base layout. I use it to type greek letters, swedish vowels, italian accents and math symbols. A couple of non-breaking spaces are also there. It's the only layout I use nowadays.
[0]: https://qwerty-fr.org/
I have rofimoji[0] bound to a key chord in i3wm and configured it in such a way that it allows me to enter not just the usual emojis but also common math symbols. Works like a charm!
[0]: https://github.com/fdw/rofimoji
Interesting idea! Though since it doesn't have a more ergonomic keypad-like layout, but repeats the slanted mistake of default keyboards, and requires software companion, what's the advantage over adding math layers to your current keyboard, where you also have access to more keys and modifiers?
Seconded. This looks like a fun toy, but it solves a problem that I don't have (and I believe I am the target audience). Modern typesetters are very good (e.g., TexMacs). There is also a limited set of characters by design, and I would have to remove my hand from my keyboard only for those.
it is frustrating that nowhere does it tell how it actually works. generally keyboards can not send specific unicode codepoints to host system, they only send scancodes that get interpreted by operating systems keymap. But most keymaps do not define any keys for these symbols, so there is something going on here. Based on the docs, I'll guess it attempts to send a sequence of keypresses to trigger some compose mode (thus requiring additional software on windows). I find such hacks slightly frustrating because they are so fragile, they depend on the keyboard predicting perfectly how the host will handle the keypress sequences which obviously can break quite easily, e.g. simply by switching layouts or having some timing/focus related aspects.
I would really love to see new keyboard HID designed specifically for modern advanced keyboards (qmk etc) where you wouldn't need to resort on this kind of trickery. Or alternatively make the input stacks of OSs more easily configurable with custom physical layouts and modifiers etc instead of assuming that all keyboards follow basic ISO/ANSI layout.
Ya, I was right. The driver is built around popular QMK framework. Here you can read how it handles unicode input: https://docs.qmk.fm/features/unicode.
It's likely the driver handling the conversion. Which makes me wonder, can I use the same driver to remap extra keys on my existing QMK compatible keyboard?
Maybe it's as simple as sending popular ALT+<unicode> sequence, at least for Windows and Linux. But that's still hacky.
Prior art: https://en.wikipedia.org/wiki/Space-cadet_keyboard
Or the ZX Spectrum keyboard
https://www.retrotechlab.com/wp-content/uploads/2020/01/Sinc...
I'd pay money for one of these, if it had the keys which I want, which this one doesn't. I think the trick would be to somehow make it customizable, but I'm not sure the best way to do that. Parametrized PCB design? 3d printing?
I'm not quite sure, but my dream would be smaller buttons, coarsely modelled on the HP48-style keypad. I can't imagine many people share that dream, but I've wanted to make that for a long, long time.
Coincidentally, you get a long ways there by simple adding a Greek keyboard layout. You hit meta-space, and ασδζχψ. meta-space, and back to normal.
Foreign-language keyboard under GNU/Linux also have a layer with many convenient math keys (²·≈·¾ all exist natively in my normal layout).
A smaller win for me would be to simply print all of that on my keycaps.
You should try building one for yourself, I did [1] and it’s easier than you’d think. I made mine just a basic numpad but I really like the idea of turning it into a tool to enter math symbols.. guess I know what my next project is, thanks for the inspiration!
1: https://blog.hamaluik.ca/posts/custom-numpad/
This one is customisable. The firmware uses QMK, so you can remap it however you like. You'd need to make some key label stickers in Inkscape or something if you want the keys to show the characters.
You could go with a streamdeck and make your own set of bindings. Has the advantage that each key on it is a screen, so it can change for context
Interesting idea, but back when I needed to enter such I use DEC's compose.exe (while it still worked) and then Allchars:
https://sourceforge.net/projects/allchars/
or used a stylus and the drawing input in TeXview.app on my NeXT Cube or https://www.inftyproject.org/en/software.html --- since then, didn't Microsoft's Journal and various other stylus note-taking apps get math support?
These days I just press the touch keyboard icon in the task bar and use that to get special characters.
A further concern is one has to be entering things more than just as a lineal stream --- superscripts and subscripts need to be entered into, things need to be put over or under a fraction bar, &c. --- do the hard-wired buttons actually accelerate things that much?
Why not just use a programmable keypad such as a Streamdeck?
WinCompose [0] is the spiritual successor to AllChars.
[0] https://github.com/samhocevar/wincompose
I love the idea of a physical device (esp. with buttons) but I get that it is not always practical. I wonder how much work it would take to add math symbols to something like Touch Portal. I haven't used it but read that many people do for controlling various software, including DAWs (which can be latency-sensitive).
https://www.touch-portal.com/
I bought a 25 key pad that is collecting dust. Not worth it for me to have an extra keyboard taking up space on my desk, may as well use LaTeX or alt codes
For those interested in purchase rather than DIY, the above page links to:
https://www.crowdsupply.com/summa-cogni/mathpad
Not bad, curious about price, but as noted by others in thread, the only really special thing are the keycaps, given those you could replicate functionality on any ZMK/QMK keyboard. I might try this as a layer of a glove 80 or ZSA voyager, s.t. like that
Briefly there was an IPv6 numpad: it had 0-9 and A-F on it for typing "Hex"
This is super cool. When I was doing a lot of math-related typesetting I found that I got really fast with Emacs + AuCTeX. I have no idea of the state of that project, but if you were fast you go at nearly the speed at which you could write.
As a red-green colorblind person, I find it hard to distinguish the colors of the R and C keys
Love this idea, although I wonder if this can also be done with QMK keyboards. I'll have to try setting up similar macros in my Ergodox EZ.
It looks nice, but I'm not sure I'd jump ship from my snippets setup I have with vim. At the end of the day it would be very similar to a mouse hand movement and would probably take a long time to get it as quick and comfortable as just typing "aa" for alpha when I'm in math mode which I get into with "mk"
Y’all should try espanso for your latex needs.
> Y’all should try espanso for your latex needs.
I definitely understand why macro-expander programs can be useful, but I'm always a bit puzzled about the idea of combining them with a macro language like (La)TeX. Why introduce two layers of macro indirection? Maybe it just doesn't fit my use case, which doesn't mean it can't fit anybody's; but, more intriguingly, maybe it would come to fit my use case if I understood what it can add, so I wonder if you could describe how it's useful to you.
> Why introduce two layers of macro indirection
TeX already has more than enough layers of macro indirection :/
Try debugging an \makeatletter\expandafter and you're going to have a bad day. I think the macro system is even Turing-complete in some sense, certainly the number of times you potentially need to run TeX to guarantee a complete output reduces to the halting problem.
> > Why introduce two layers of macro indirection
> TeX already has more than enough layers of macro indirection :/
Sure, I should have said "another layer of macro indirection" instead of just two!
> Try debugging an \makeatletter\expandafter and you're going to have a bad day. I think the macro system is even Turing-complete in some sense, certainly the number of times you potentially need to run TeX to guarantee a complete output reduces to the halting problem.
So is the indirect (har!) answer that, for you, which I know isn't the same as the person I was originally responding to, introducing the new macro layer allows you to replace some of the TeX-level indirection by a more concretely understandable macro expander?
(By the way, you are right that TeX's macro system is Turing-complete, not just incidentally but intentionally; Knuth didn't plan to make it so, but did so by request from Steele.)
This is pretty cool!
Why no Aleph?!
Why no omicron!?
To infinity and beyond!