(I’ve titled this question as I have because I imagine the answer would apply to any input method that has multikey character inputs, such as rfc1345, not just ipa-x-sampa). If it turns out this is not the case, I’ll retitle the question before accepting an answer.

I’m using the ipa-x-sampa input method for the first time—in the past I’ve usually used the rfc1345 input method or (insert-char), but right now I’m doing some phonetics-heavy work for which X-SAMPA is much-better suited. (For those who haven’t tried it: the ipa-x-sampa input method takes standard ASCII X-SAMPA input and inserts IPA characters.)

X-SAMPA uses postfix diacritics (e.g., “ë” is typed e_" or e_") for characters that can also go alone (e.g., e which is... e). But it also has characters that have alternates expressed by non-diacritic postfixes. So for instance, “r” is r, but “ɹ” (the alveolar approximant, or “North American ‘r’”) is typed r\ or r\.

Emacs shows the difference here in that when you type an e, it comes out right away and you’re back to typing the next character, but when you type r, the r is underlined (as in other input methods, that means “waiting for disambiguating input”) and the minibuffer shows the potential disambiguating keys. (This particular behavior of the minibuffer seems peculiar to ipa-x-sampa, as input methods that have dozens of potential legal following characters, like rfc1345, do not show potential completions. Or this may be a matter of some arbitrary limit or whether the list of legal following characters can fit in the minibuffer, I’m not sure.)

My question is this: if I type one of those and have the underline and minibuffer prompt, how do I say, “that's all, I just want an ‘r’”? rSPC gives me r with the space, which I can delete. And C-g also terminates the r, but of course beeps and potentially cancels an operation in progress. So, is there a standard way in these input methods to say “I’m done with this character now”?

There aren’t many places where it matters—for the most part, X-SAMPA was designed such that it should be unambiguously convertible into IPA. But this isn’t 100% true.¹ For instance, the string tS can be rendered either as t͡ʃ(two characters, with a tie added separately) or as ʧ (one). In this case, I might have to type tSPCDELS or tC-gS.

It seems to me C-g should be right, as I know that (keyboard-quit) only cancels a single function—meaning if you’re in the midst of a function calling another interactive function, only the top-of-stack interactive is explicitly cancelled—but character continuation apparently doesn’t count; if I start an isearch with C-s and type tC-g, the isearch is cancelled, so I only know of the SPCDEL working in this case.²

¹ X-SAMPA is more or less unambiguous in its most-common use cases of phonemic transcriptions and marked-language use. It only becomes ambiguous in close phonetic transcription and interlingual use.

This is why, for instance, in modern natural-sounding text-to-speech systems that accept X-SAMPA or IPA for pronunciation hints, even in places where you can write the X-SAMPA two different ways in IPA, both variants of the IPA will produce identical output speech, while in older, artificial-sounding, ones, the two would produce different speech—the older ones didn’t have to know what language they were speaking so could use “foreign” sounds, but the newer TTS systems always speak in a given language so “know” to substitute native sounds when necessary.

² This answered question notes that isearch does not actually “use the minibuffer” proper, and only uses the input method already set when invoked. This is true but, I think, irrelevant to my question.

  • 1
    The way some input methods handle this is by saying 'repetition == insertion', so in your case e.g. 'rr' => r, 'tt' => t. You'd have to extend ipa-x-sampa definition in ipa.el to get that behaviour.
    – rpluim
    Commented Oct 3, 2019 at 9:25
  • 1
    @rpluim That’s good to know about some other input methods. Checking rfc1345, though, there are cases like this, such as &ul and &ulR, so it seems to be endemic to input methods that have variable key-sequence-length characters. Also, in rfc1345, every special character is introduced with &, but && produces &&. And there are variable-length cases where the last character is a duplicate of the penultimate one.
    – Trey
    Commented Oct 3, 2019 at 18:14


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Browse other questions tagged or ask your own question.