Disable nobreak-char-display in view modes

[astoff]

Distinguishing non-breaking spaces and the like is generally not useful in {markdown,gfm}-view-mode. So these modes should set nobreak-char-display to nil by default. Another option would be to tie this setting to the value of markdown-hide-markup.

I encounter this issue often in Eglot's eldoc buffers, which use gfm-view-mode to prettify markdown text received from an external process. This markdown sometimes contains lots non-breaking spaces. Note the red undelining in all the indented lines of the screenshot below.

Actual Behavior

The global value of nobreak-char-display applies to {markdown,gfm}-view-mode buffers.

Steps to Reproduce

In a scratch buffer, enter a non-breaking space (C-x 8 RET non-breaking space RET). The nobreak-space face will be applied to that character. Now type M-x gfm-view-mode RET. The nobreak-space face remains, but it should disappear.

Backtrace

Not needed.

Software Versions

• Markdown Mode: 2.4
• Emacs: 28.0.60
• OS: Fedora

[astoff]

Ah, now I see this won't solve the Eglot problem, since it copies the gfm-view-mode buffer contents to another buffer. It might still make sense to fix this in markdown-mode, but please feel free to ignore it.

[doolio]

Did you find a solution for this with Eglot?

[astoff]

Yes, this has been fixed on the Eldoc side.

[doolio]

Yes, this has been fixed on the Eldoc side.

Fully? I still see similar "underlining" and "&nbsp" when using the pyright language server. See examples here and here.

[astoff]

I have never used this language server or seen that particular problem. Now, I think this can only be solved on the markdown-mode side.

Eglot already renders correctly asterisks that demarcate list items, turning them into •. So if markdown-mode learns to render the HTML entities, I'm pretty sure all will be fine on the Eglot/Eldoc side. (I'm not necessarily saying that this should be done, and incidentally I'd regard it a bug for a language server to produce unreadable markdown.)

[doolio]

I see, thank you. From the discussion under the second link I shared it seems the pyright team only guarantee to target the markdown renderer supported by the VSCode LSP client.

[astoff]

This is of course dumb; if there was a good reason to mangle the markdown to the point it's unreadable in the raw, then LSP should support transmitting text as HTML instead. Unfortunately, I see LSP more and more as a VS Code interface that others are invited to use at their own peril than a truly editor-agnostic protocol.

[doolio]

Sadly, I think you may be right.