Disable syntax highlighting #5352

New Issue

OVERLORD · 2026-02-05T09:59:47+03:00

OVERLORD commented

2026-02-05 09:59:47 +03:00

Originally created by @profiteroles1 on GitHub (Jul 10, 2025).

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

Originally created by @profiteroles1 on GitHub (Jul 10, 2025). ### 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? - [x] 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_

OVERLORD added the > Markdown Editor 🔨 Feature Request labels 2026-02-05 09:59:47 +03:00

OVERLORD closed this issue

2026-02-05 09:59:49 +03:00

OVERLORD commented

2026-02-05 09:59:52 +03:00

@ssddanbrown commented on GitHub (Jul 11, 2025):

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.

@ssddanbrown commented on GitHub (Jul 11, 2025): 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.

OVERLORD commented

2026-02-05 09:59:53 +03:00

@profiteroles1 commented on GitHub (Jul 17, 2025):

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!

@profiteroles1 commented on GitHub (Jul 17, 2025): > Hi [@profiteroles1](https://github.com/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](https://github.com/BookStackApp/BookStack/issues/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!

OVERLORD commented

2026-02-05 09:59:55 +03:00

@ssddanbrown commented on GitHub (Jul 23, 2025):

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.

@ssddanbrown commented on GitHub (Jul 23, 2025): 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.

OVERLORD commented

2026-02-05 09:59:58 +03:00

@profiteroles1 commented on GitHub (Jul 30, 2025):

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 commented on GitHub (Jul 30, 2025): > Thanks for confirming [@profiteroles1](https://github.com/profiteroles1). > > Within [#5725](https://github.com/BookStackApp/BookStack/pull/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!

OVERLORD commented

2026-02-05 09:59:59 +03:00

@profiteroles1 commented on GitHub (Oct 8, 2025):

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!

@profiteroles1 commented on GitHub (Oct 8, 2025): 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!

OVERLORD commented

2026-02-05 10:00:01 +03:00

@ssddanbrown commented on GitHub (Oct 11, 2025):

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.

@ssddanbrown commented on GitHub (Oct 11, 2025): 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.

OVERLORD commented

2026-02-05 10:00:03 +03:00

@profiteroles1 commented on GitHub (Oct 13, 2025):

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!

@profiteroles1 commented on GitHub (Oct 13, 2025): > Hi [@profiteroles1](https://github.com/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!

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/BookStack#5352