knrafto / mathsymbolsinput Goto Github PK

Ideally we should show both the command and the symbol we'd replace it with. I think at one time I tried the IMKCandidates API but it didn't really look right, so maybe this needs some custom UI work.

I find myself typing out keyboard shortcuts reasonably often. Others might benefit from including the proper symbols in the default set.

Here's a list copied from Stack Exchange: https://apple.stackexchange.com/questions/55727/where-can-i-find-the-unicode-symbols-for-mac-functional-keys-command-shift-e

• ⌘ U+2318 command
• ⇧ U+21e7 shift
• ⌥ U+2325 option
• ⌃ U+2303 control
• ↩U+21a9 return
• ⌤ U+2324 enter
• ⌫ U+232b delete
• ⌦ U+2326 forward delete
• ⌧ U+2327 clear
• ⇥ U+21e5 tab
• ⇤ U+21e4 backtab
• ␣ U+2423 space
• ⎋ U+238b escape
• ⇪ U+21ea caps lock
• ⏏ U+23cf eject

It would be nice if pressing tab completed the command instead of just inserting an incomplete command name. So, e.g., \al would complete to \alpha, inserting α, if that is the only available completion. If there are multiple completions, showing a list of completions would also be nice.

"Math Symbols Input" doesn't exactly roll off the tongue. Maybe a name like "LaTeX input" would be more googlable, and maybe more accurate since it doesn't have to be math symbols.

Examples of where this might help:

• escape doesn't work in VSCode find bar (the find bar still goes away...)
• cmd-z doesn't commit in Xcode (try \t cmd-z )

Hi,

I was attempting to package this input method with a declarative build setup (see LnL7/nix-darwin#587). It works well, but one problem is that if the list of custom commands is updated then the input method does not pick up the changes until the user logs out. The way this setup works is that it generates a com.mathsymbolsinput.inputmethod.MathSymbolsInput.plist file and then symlinks that into /Users/USER/Preferences/.

This is entirely a synthetic problem of my own making (and so don't expect any changes), but I was curious if it might make sense to add some ability to update the internal command buffer if the preference file changes. Potentially either through some sort of watch method (which may not work with the symlink) or by loading the preferences file each time the input method is switched to.

This may also help solve #17. You can see how I am attempting to share configurations between machines here.

I'm not totally sure what to put here though. Suggestions:

• Find out how to type a symbol
• List of all symbols
• Links to homepage or help or about

Right now it uses Apple's sample from NumberInput

Steps to reproduce:

• Type "\foo" into an xcode editor. Leave the input method active.
• Place the cursor somewhere else in the text document by clicking.
• Press enter.

A newline should be inserted, but instead a duplicate "\foo" is inserted at the cursor.

This is probably an XCode bug; the same thing happens with Chinese Pinyin.

If you try clicking on "About" from the menu while the keyboard focus is in the Chrome address bar, nothing happens. The menu works if the keyboard focus is in the webpage, however.

I'm fairly sure this is a macOS and/or Chrome bug. The same issue occurs with Google Japanese Input's menu. Chrome's address bar is probably highly customized and implements its own input method functionality, and nobody tested the menu.

There's no indication if the input method is active or not, because the "marked text" is not underlined. This is probably an XCode bug, because the same thing happens with Chinese Pinyin.

Sample code: https://github.com/microsoft/Windows-classic-samples/tree/master/Samples/IME

There seems to be several competing frameworks: https://en.wikipedia.org/wiki/List_of_input_methods_for_Unix_platforms

The top ones are IBus, SCIM, Fcitx, and uim. I'm not sure which one would be best.

i.e. what keys are special?

Steps to reproduce:

• Open the VS Code find bar with command-F
• Type \foo, leaving the input method active
• Press escape

The text \foo should be inserted into the find bar, and the find bar should be left open. Instead, the find bar closes too.

Using a more modern language could make development easier, and SwiftUI could help with menus or autocomplete windows.

This is the only resource I can find: https://www.logcg.com/en/archives/2078.html

Dead keys in the US keyboard, and a few other keyboard layouts I tested, don't work with the input method active. Frustratingly, dead keys do seem to work with the "ABC - Extended" layout, and custom layouts made with Ukelele.

Currently we use the "key binding" approach to receive input data from InputMethodKit. Let's say we press Option+e then o to input ó. With the ABC - Extended layout, we get the following events:

• inputText="´", lastKeyEventWasDeadKey=true
• inputText="ó", lastKeyEventWasDeadKey=false

With the US layout, we get:

• inputText="´", lastKeyEventWasDeadKey=true
• inputText="o", lastKeyEventWasDeadKey=false

Some options on how to fix this:

1. Convince Apple to somehow change how input data is sent or interpreted so that all keyboard layouts behave like ABC - Extended. I don't have much hope of this happening.
2. Use the lower-level "handle all events" approach of receiving data from InputMethodKit, using UCKeyTranslate to handle dead keys ourselves. This could allow us to have a nicer UX by showing an underlined accent when a dead key is pressed instead of having no feedback. However, we'd also have to implement key bindings ourselves, which seems tricky to get right.
3. Guess what the resulting character should be if we detect a dead key with the "key binding" approach. This would probably work for the most "common" keyboard layouts but probably not for all of them, which could be surprising to the user (for example, the ABC - Extended layout maps "№" + "q" to "ƣ", and I'm not sure how we're supposed to guess that).

For instance, in order to share between multiple computers.

For now, you can copy ~/Library/Preferences/com.mathsymbolsinput.inputmethod.MathSymbolsInput.plist in its entirety from one computer to the next, but this will delete any previous custom commands on the target computer. And it only works on Mac.

Would it be possible for the extension to not disable the press-and-hold accent popup? If that's not possible, it would be good to include latex sequences for accented characters in the standard command set.

I tried IMKCandidatesWindow but it doesn't look great. We'll probably have to implement our own window logic.