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.*

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.

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.

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:


*And yes, if I copy and paste out of FireFox into TextMate, it shows up with two backticks again.*

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.