Something that is driving me nuts, ever since Ulysses 2, if I type in a sequence of characters like "e\`" the text system automatically converts this to è. Similarly, if I type in "o/" I get ø. I very, very, very rarely need extended characters, and don't mind just using the option keys to get them, but on the other hand these sequences of punctuation come up *a lot*. Consider, you cannot even type in "Gecko/Firefox" without it becoming "GeckøFirefox". There is No Way Around this either. I cannot type in "Gecko /Firefox" and then backspace the extra space, it will still convert. Likewise I use backticks quite a lot in my work, since I use Markdown and enclosing things in \` is how you get an inline `codeblock`. Nearly any in-line codeblock ending in a vowel gets mangled.

I've looked all over the place for disabling this. All auto-correction in Ulysses is disabled. I've even looked all over the OS as well. I'm using "US" keyboard, not "US International", auto-correction is completely turned off. But I'm not sure if it is an OS level thing anyway, because it isn't universal behaviour, just in some applications, including Ulysses. Any thoughts?

*All right, so this forum doesn't render inline code blocks, but the point remains. Ordinarily that is what they are used for, and I use them quite a lot.*

I just tried the character combinations you mentioned, in several keyboard layouts, but I did not get this problem.

The only solution I could think of is, that beside auto-correction you already turned off, there are still some Symbol and Text Substitutions marked (Text tab in system preference "Language and Text", right beside Spelling). But as you wrote, you checked everything.

Yes, that I already checked. Besides there not being any entries in that list which would produce the results I'm seeing, they are all unchecked, and besides I think those all require you to input the necessary characters and then press the spacebar. They don't happen if you so much as backspace one character against another.

so there is no hint how to get this behavior off except that there seems to be something with set up on your computer. As far as I could try the same characters with the setup you described, none of these problems occurred on my computer -- neither with Ulysses nor any other software.

Further oddities: it appears to be strictly *display only*. For example, if I type in:

This is a test, `yerde` case.

I see, "This is a test, \`yerdè case." and the interesting aspect of that is Ulysses syntax highlighting. I have Ulysses set up to display a subtle blue background to code blocks, and in this case the entire \`yerdè part is highlighted, and then halts before " case", meaning the back-tick is still there. I confirmed this by selecting the phrase and pasting it into a text editor that does not do this, and it showed up as expected, as the above code line indicates it should.

So this appears to be happening after processing and is purely a matter of display. There is actually no "è" character at all! Which is really, really weird. What would be the point of that?

Will investigate further. InputManagers come to mind, though why that would only impact some NSText views and not others, I have no clue. Both Ulysses and TextMate are using their own, heavily hacked versions, but TextMate doesn't do this. Neither do applications using stock NSTextView.

Fortunately, what this does appear to mean is that I can just ignore it.

Even if it is just an appearance problem, it is certainly no pleasure to work with something to ignore it. There is one more thing that got into my mind, but I am not sure about how exactly the problem came up:

I had my MarkUp set up in a way that Ulysses had no chance to differ between the end of one certain marked up section and the beginning of another certain mark up.

If you try to write the same test text in a new Ulysses document with a different mark up preset (Ulysses default or something extremely simple) and the problem does not occur, you might solve the problem with a look at your mark up set up?

As said before, I do not get this odd behavior whatever I try to get Ulysses doing it.

Huh, I just looked at this post again and realised *Firefox* is doing it as well. The code line I pasted should have two distinct backticks, but instead it appears with the final e as è. I will check out my preferences tomorrow when I get a chance, but this definitely seems to lend credence to something odd on my computer. I just cannot for the life of me think of what could impact the Gecko rendering engine *and* a Cocoa text engine. Could just be a coincidence? Anyone else using Firefox and seeing this:

Hi, I think I once had something very similar which drove me nuts. Turned out that somehow "sticky keys" was selected under "keyboard" in "universal access" of the system preferences. Could that be it?

That's been turned off the whole time. Besides, this is a display issue not an input issue. When Firefox renders the text above, it displays it incorrectly. I'm leaning more toward some bad combination of tools installed, because this is happening on two different machines for me, so it is probably not an arcane setting somewhere.

I haven't found an easy way to disable this functionality in Mac OS. I usually get this problem by hitting the space bar after the character (^, `, ´, ...). This way the character is printed correctly.
To disable dead keys (i.e., those keys which do not print a character but wait for the next character and check if they can be composed) altogether, you would need to edit the layout of your current keyboard. Mac OS doesn't have any built-in capabilities to do that (as far as I know), but you can alter the keyboard layout with applications such as Ukulele (I haven't tried it myself).