I’ve encountered a really strange bug with potentially serious consequences, though unfortunately I can’t reproduce the most serious consequence I encountered (a crash while editing the file). Nonetheless, it happened, and I’m pretty sure it’s related to this more “minor” bug.
Sorry for the long post; I investigated it as best I could, and included all of that info here.
In the file included as plaintext at the bottom, \u should evaluate to a macro that takes a single argument and puts it between a floor bracket on the right and a ceiling bracket on the left (<assign|u|<macro|x|<around*|\<lceil\>|<arg|x>|\<rfloor\>>>>). Typing \u and hitting enter should produce ⌈⌋ with the cursor in between the brackets.
If you use this assign statement in a fresh file, it works as expected. But if you use it in this file, it produces a pale red question mark where the argument should be (as shown in the file). My understanding is that this is a consequence of <u> being mistakenly inserted instead of <u|>. If you put the cursor after the occurrence of ⌈?⌋ when viewing the included source in TeXmacs, you can reproduce this behavior. (Earlier, and you’re likely to be before the assign statement for u.)
So here’s the weird part. If you delete one of the preceding paragraph breaks, the behavior of the \u input changes and becomes “normal”. (I also see the view change and zoom out slightly; not sure if this is a clue as to what’s happening.)
There was also an assign statement in the preamble from when I was playing around with the “create macro” gui. In investigating this bug, I discovered that deleting that assign statement had no effect on the bug, but deleting the paragraph break that had appeared in the preamble did fix the \u problem. (So, if you’re wondering why there’s a stray paragraph break in the preamble, it’s because it was inserted by the macro-creator gui process, but then I manually deleted the assign statement to minimize the example.)
At least, this is what’s happening for me. Can someone else who’s on a mac reproduce this behavior with their installation, to make sure it’s not a local problem?
Thanks!
EDIT: There’s another weird thing in this file which I thought was related, but which is a separate bug. If you hit the right arrow key to navigate to the end of the file, your cursor turns into a green bar that stretches the length of the page vertically on the left side. This seems related to a different assign statement (for downwards) that comes after the ⌈?⌋, which is strangely inaccessible via arrow-key navigation despite being visible in the source. This seems to be because the assign statement is of the form <assign|downwards<math|>| ... >; the <math|> trips it up. All I can say is that this occurred through normal editing in TeXmacs, not through unusual editing of source as plaintext or anything like that, so a user can accidentally produce this strange “unreachable” assign statement and never be able to fix it within TeXmacs. Should I go to Savannah to post about this bug? It’s unlikely to happen, sure, but it happened naturally and without trying to me, and the crucial part is that I had to go into the plaintext source to fix my mistake, which I don’t think should happen. Deleting the downwards assign statement does not fix the \u bug, though.
assign-bug.tm as plaintext
<TeXmacs|2.1.1>
<style|generic>
<\body>
<\hide-preamble>
\;
</hide-preamble>
\;
\;
\;
\;
\;
\;
\;
\;
\;
<assign|u|<macro|x|<around*|\<lceil\>|<arg|x>|\<rfloor\>>>>
<u>
<assign|downwards<math|>|<macro|x|<around*|\<lceil\>|<arg|x>|\<rfloor\>>>>
</body>
<\initial>
<\collection>
<associate|page-medium|papyrus>
</collection>
</initial>
(To insert a summary tag in the forum post editor, click the gear in the bar just above the text field, then click “hide details” to get a template; to get a code block use three backticks before and after the text on separate lines, as usual!)