Why Markdown Symbols Appear Only in the Word Under the Cursor

In Live mode, the cursor’s position determines what you see. Markdown markers should normally stay hidden and appear only when you edit them.

Then how can we tell when you are “editing”?

At first, mote used the entire paragraph as its basis. When the cursor entered a paragraph, it displayed every marker in that paragraph.

The implementation was simple, but the screen became noisy. You had only placed the cursor to edit one bold word, yet even the link and code three lines later reverted to raw text. Your eyes were focused on one place, but the entire paragraph moved.

Look at the syntax, not the paragraph

Now mote shows only the syntax touching the cursor.

The raw text appears only when the cursor is between the opening and closing markers. The positions immediately before and after the markers are included in the range as well. Placing the cursor there is also an action intended to edit the syntax.

As soon as the cursor moves even one character away, it returns to its rendered appearance. A 120 ms opacity transition is used when it appears and disappears. Because the transition has a defined beginning and end, nothing remains once it is complete.

Even when a paragraph contains bold text, a link, and inline code together, the others do not move. Only the syntax touched by the cursor changes, and the redrawn area is limited to that single line. The entire document is not parsed again.

The same principle applies to italics, bold, strikethrough, highlights, subscripts, superscripts, code, math, links, images, and footnote references.

Line-prefix markers work a little differently. Because # and > determine the nature of the entire line, they maintain the same appearance wherever the cursor is on the line. By contrast, a list’s - is revealed only when the cursor is over the marker. Once the cursor passes the space and moves into the text, it immediately returns to a bullet.

When text is selected, only syntax overlapping the selection changes to raw text. If selecting three characters turned the entire line into source text, it would actually become harder to tell what had been selected.

Markers follow the appearance of the text, too

Revealed markers inherit the syntax’s styling.

The ** around bold text appears bold, and the * around italics appears italicized. The ~~ around strikethrough text also has a line through it.

Previously, every marker was displayed in gray. As a result, the moment you placed the cursor in bold text, the word looked as though it had been trapped inside gray brackets. The information that the text being edited was bold also disappeared temporarily.

Applying the text’s styling to its markers made the meaning clear. The word remains bold, and the asterisks serve only as indicators of its boundaries.

Gray is used only for block markers such as #, >, and bullets. These markers describe the nature of the line rather than the text.

The principle is simple. Markers attached to text are shown as part of the text, while markers that define a line are shown like the background.

Only asterisks are automatically paired

When you type one asterisk, a closing asterisk appears with it. If you type another asterisk, the pair grows into one for bold text.

If you type a closing asterisk after entering the content, the cursor moves past the existing marker instead of creating a new one. This rule also resolved the problem of four asterisks appearing at a time.

However, an asterisk typed immediately after a character or another asterisk is treated as the user manually closing the syntax. In this case, no pair is created.

Underscores and tildes are not paired automatically. That is because they could interfere with text people commonly type, such as snake_case, __init__, and ~/path. They act as pairs only when wrapping selected text.

The caret should be less noticeable than the text

At first, the caret was blue, the accent color. Now it uses the same ink color as the body text.

A blue bar works well in a short input field. In a document, however, the text is the main character. The caret only needs to show how far you have typed. The accent color is reserved for selections and search results.

Its width is determined by dividing the caret height by the body-text ink height and rounding to an integer. This produces 1 px in body text and increases to 2 px only in large headings. If a fractional width is used as-is, it is split across two pixel columns, making it look thick and blurry rather than thin.

Its height follows the character height rather than the line spacing. Body text is 18 px, h3 is 24 px, h2 is 29 px, and h1 is 36 px. The caret alone tells you whether the cursor is in body text or a heading.

Blinking is documented as the sole exception to the rule against keeping a repeating source active while idle. When the window loses focus, blinking stops, and the selection also recedes to 45 % alpha.

We kept the shift

When markers appear, the text after them shifts slightly. We decided not to eliminate this movement.

We also tested reserving space by continuously displaying hidden markers in faint gray. But this left gray afterimages around bold text, and strikethrough lines protruded beyond their words. It became an awkward state that was neither the rendered view nor the raw source.

Instead, line-prefix markers with drawn boxes, such as bullets and task boxes, shift the line by the difference between the source and rendered widths, so the body text does not move when the marker is revealed. The heading # and quote > are allowed to push the body text. That decision was based on familiarity with editors that behave this way.

Links can cause a larger visual change because their addresses may be long. So normally, only the link text is shown, with a small arrow appended to it. You can tell that it is a link, but the address appears only when you edit it.

If you need to inspect the raw text precisely, you can use Source mode. Live mode is not a place that shows every marker; it opens only the place you are editing now.

mote does not guess the user’s intent. If the cursor is inside the syntax, it shows the markers; if the cursor is outside, it hides them. Guessing is convenient when it is correct, but when it is wrong, it is difficult to understand why. Using position as the sole criterion makes the result predictable every time.

Deciding when to show markers is ultimately deciding where the user’s eyes should remain.