I tried to narrow it down further and made two more videos. You can see very clearly here how erratic the whole thing is. The videos are much shorter (only 40-50 seconds each) — I was able to reduce them to the essentials. I closed all unnecessary programs and just used Tinderbox; BBEdit is no longer involved. But the error is still there, so it is no copy/paste thing.
The first video was recorded today at 10:34:33. That’s where the error appears:
The second video was actually meant to be a replacement for the first one, because I thought it would make sense to show the keyboard overlay so you can see the keystrokes — that’s why the keyboard is visible in the video. So I did that, but now the error suddenly no longer appears!
As I said, nothing was changed. The Mac is not connected to the network via Wi-Fi or Ethernet. Both TBX are fresh. There are no agents, no action code, or anything else. I also checked the system settings, especially keyboard shortcuts. I disabled everything that contains a ^ character (the error only occurs after using the ^ key).
An observation: a German (?) keyboard is in use. As the caret ^ symbol key seems a factor, in @ShawnMichaels ’ example it is the left key of row two. In the US (en-us) and UK (me, en-gb) keyboards the ^ is Shift+F6. The left key row #2 is in en-us the backtick `` (Markdown doesn’t escape this character!) or in en-gb it is the section marker §. Anyway, this might be a factor.
A further possible key/character mapping issue is that the ^ can be confused with the circumflex diacritic, e.g. â/ I wonder if that bis in the mix here.
Notable in video #1 is that when the ^ is typed there is a yellow highlight. IIRC this indicates a diacritic insertion method where the accent character is typed first and then the accent character, then the OS goes and inserts the correct Unicode accented letter character. Here, I think the OS is misinterpreting the `` as a circumflex as opposed to a caret.
I’m on a deadline here so can’t risk experimenting with keyboard mappings, but this does seem an avenue to investigate. HTH
FYI: for anyone playing along at home, the video recording files kindly being offered up are quite large so I find it helps to download them and play them locally. Played in the browser they can hang.
Yes. This is always the case since I have started to use Tinderbox. Isn´t that normal?
Up till today I was sure, that circumflex ist the name of the accent and carot the same sign without a letter/vowel (a, e…). But no matter if with or without a letter the sign is typed with the same key on the keyboard. The difference is, if you have deadkeys like on the german keyboard, the computer awaits your next keystroke an decides after it which sign is outputted: If you type an “a” after the ^ you get that: â; but if you hit the spacebar, you just get ^
Yes, absolutely.
Thanks for your thoughts. I´ll try to investigate this.
Hm, If you type, on your keyboard, ^+space are you then able to add codes like `^text^ and not have the disappearing text problem?
IOW, I’ve a hunch the issue is that on your keyboard it make not be possible to type a non-diacritic ^ in the way I can on my en-gb keyboard (in my case via ⇧+6).
However, we’ve a fair number of German users here so it seems odd this caret issue hasn’t groped up before as I assume they too use a German keyboard. Aha, another possible edge case. As you using a keyboard built for German language use or are you using a keyboard mapping on a keyboard set up for some other language. IOW, are the labels on the physical keys the same as the one in the overlay? A difference there could be another edge-case cause. There is no user error in doing these things but the effects of doing so may have unexpected consequences, as here. HTH
It’s hard to say for sure because the text doesn’t always disappear – it happens quite erratically. What I’ve noticed so far is that the problem often occurs when I press ^ and then don’t follow it with a space, but instead type an arrow key or just click with the mouse. The ^ symbol itself stays visible as normal, but then – sometimes, not always (as seen in video nr. 3) – the error appears.
I’ll test whether the issue occurs consistently after multiple attempts or not.
From my tests today, I’ve found that the error doesn’t happen if I copy and paste the ^ character instead of typing it. That probably corresponds to how it’s entered on a US/GB keyboard.
That surprises me too, but it took me also quite a while to even figure out what was causing the problem. Plus, the error only appears sporadically (though when it does, it can be pretty disastrous).
As far as I know, one can also use the keyboard layout “German (No Dead Keys)” – then the ^ key should behave like on US/GB keyboards. Until now I never had a reason to switch, but this is clearly a good reason to change the layout. If German users do that, maybe they never encounter that behaviour at all.
It might also never happen if you always finish the ^ with a space (I will test that). So perhaps only a small number of specific cases remain, and even then the error only occurs sometimes, not every time.
However, I have to admit that while I can switch to the NoDeadKeys layout on Windows and Linux, I haven’t found how to do it on macOS yet.
Yes, I’m using a standard Apple keyboard with German key labels, not just a German keyboard layout.
Is the problem reproducible at all if you don’t insert HTML markup in text?
One explanation for the issue might well be that macOS draws a distinction between text that happens to include the character ^ (circumflex accent U+005E) and the combining circumflex accent ( U+0302). The latter is used for entering characters such as ê and modify the preceding character. I’m not sure, though, that all strings containing a combining circumflex are legal: in particular, it’s not clear what happens when it occurs at the start of a string. (Important: the combining circumflex will NOT indicate an export markup tag in Tinderbox; only the circumflex accent will work.)
Absolutely. This can be seen in todays two last screenrecordings. It has nothing to do with HTML.
Yes. There must be a (hidden) distinction, otherwise the behaviour is not explainable for me. Now, after I´ve installed the German (No dead keys) keyboardlayout I wasn´t able to reproduce the error. I’m cautiously optimistic that this (handling ^ as a non-dead key) is the solution to the problem.