Disable syntax highlighting

[profiteroles1]

Describe the feature you'd like

Hi there, I'm looking for a way to disable the syntax highlighting in the commonmark editor. As there's already a live preview, the value of syntax highlighting seems somewhat questionable. Some of our users are complaining that the syntax highlighting and code completion requires extra work to edit out the closing tags if they're adding tags to pre-existing content

Describe the benefits this would bring to existing BookStack users

Many users prefer no code completion. It is helpful in the admin interface for editing the page header, but not in the page editor. Would be amazing if it could be configurable per-user.

Can the goal of this request already be achieved via other means?

No

Have you searched for an existing open/closed issue?

• I have searched for existing issues and none cover my fundamental request

How long have you been using BookStack?

1 to 5 years

Additional context

No response

[ssddanbrown]

Hi @profiteroles1,

I've thought about adding an option to the markdown editor menu to enable/toggle a simple plain-text textarea input instead of the codemirror editor, as a way to help with #693 while also providing better compatibility with other potential browser extensions.

It sounds like something like that may also help here? (Since that would have no active code features at all).
I'm not confident we'll be able to (reliably, need to test things) provide the editor toolbar actions & shortcuts in such a textarea, but as a worse case you could temporarily switch back to the full editor to use those features.

[profiteroles1]

Hi @profiteroles1,

I've thought about adding an option to the markdown editor menu to enable/toggle a simple plain-text textarea input instead of the codemirror editor, as a way to help with #693 while also providing better compatibility with other potential browser extensions.

It sounds like something like that may also help here? (Since that would have no active code features at all). I'm not confident we'll be able to (reliably, need to test things) provide the editor toolbar actions & shortcuts in such a textarea, but as a worse case you could temporarily switch back to the full editor to use those features.

Hi @ssddanbrown, yes, a toggle that allows the user to switch to a plain textarea input would be greatly appreciated by our user base!

[ssddanbrown]

Thanks for confirming @profiteroles1.

Within #5725 I've now added a plaintext input option which you can toggle on/off instead of the default codemirror input.
This will be part of the next feature release.

[profiteroles1]

Thanks for confirming @profiteroles1.

Within #5725 I've now added a plaintext input option which you can toggle on/off instead of the default codemirror input. This will be part of the next feature release.

Amazing, thank you!

[profiteroles1]

Hi there @ssddanbrown. Thank you SO much for implementing this. We just upgraded and my team has been trying it out and everyone is much happier working this way.

We've noticed a minor quirk involving uploading images. In the markdown editor, dragging an image to the edit area turns the cursor into an insert symbol, and it is possible to drag the image where the user desires the image tag to be placed. When the plaintext input is used, the image tag ends up wherever the cursor was left when the user moves focus away from the window.

Is this a limitation of the plaintext editor, or can that "live insert" cursor be replicated here? The current approach is a bit counterintuitive.

Thanks again!

[ssddanbrown]

Hi @profiteroles1 Drag and drop positioning will be less accurate, and potentially buggy in the plaintext editor since I've essentially had to define logic to guess where the cursor is via calculating an estimation of where a position is relative to text, and there is less capability (without adding a lot of extra complexity) for handling position in a plain native input. Things will tend to become less reliable as content gets longer too.

If it's a particular pain point, you could raise a new issue for it with a specific replication scenario, to potentially be looked into further by me (or any others) when at a convenient time.

[profiteroles1]

Hi @profiteroles1 Drag and drop positioning will be less accurate, and potentially buggy in the plaintext editor since I've essentially had to define logic to guess where the cursor is via calculating an estimation of where a position is relative to text, and there is less capability (without adding a lot of extra complexity) for handling position in a plain native input. Things will tend to become less reliable as content gets longer too.

If it's a particular pain point, you could raise a new issue for it with a specific replication scenario, to potentially be looked into further by me (or any others) when at a convenient time.

Hi @ssddanbrown thanks so much for taking the time to explain. I'm assuming the markdown editor loads JS libs to make this easier, and so I understand not wanting to saddle the plaintext flavor with a full syntax highlighter if nothing is highlighted. On the other hand, our whole use case is to add images to books with the plaintext editor, so I'm hoping for a solution. Thank you as always for the generosity and care you put into this codebase!