About Gitea editors #7037

New Issue

2025-11-02T07:14:05-06:00

GiteaMirror commented

2025-11-02 07:14:05 -06:00

Originally created by @lunny on GitHub (Mar 20, 2021).

I think we should clarify all the types of editors on Gitea UI before we have any decision. There are three editors on ui of Gitea

issue/comment/release editor
Now gitea is using EasyMDE with a switch to textarea (no turn back).
Wiki editor
Currently gitea is using the same editor as first one.
file editor
Now gitea is using monaco, but for markdown file it's not perfect.
Hooks editor
Also use monaco

Originally created by @lunny on GitHub (Mar 20, 2021). I think we should clarify all the types of editors on Gitea UI before we have any decision. There are three editors on ui of Gitea * issue/comment/release editor Now gitea is using EasyMDE with a switch to textarea (no turn back). * Wiki editor Currently gitea is using the same editor as first one. * file editor Now gitea is using monaco, but for markdown file it's not perfect. * Hooks editor Also use monaco

GiteaMirror added the outdated/theme/markdown type/summary labels 2025-11-02 07:14:05 -06:00

GiteaMirror closed this issue

2025-11-02 07:14:05 -06:00

GiteaMirror commented

2025-11-02 07:14:06 -06:00

@silverwind commented on GitHub (Mar 21, 2021):

There's also the hooks editor which uses monaco.

@silverwind commented on GitHub (Mar 21, 2021): There's also the hooks editor which uses monaco.

GiteaMirror commented

2025-11-02 07:14:06 -06:00

@silverwind commented on GitHub (Mar 21, 2021):

I think we have two style of editors to support:

Simple Markdown editor with preview mode. I think it should be plain textarea with toolbar.
Full-Blown Code editor. Currently using monaco but I think we could in the future replace it with full VSCode if there is a suitable module to use, similar to GitHub CodeSpaces, but more integrated in the UI.

@silverwind commented on GitHub (Mar 21, 2021): I think we have two style of editors to support: - Simple Markdown editor with preview mode. I think it should be plain textarea with toolbar. - Full-Blown Code editor. Currently using monaco but I think we could in the future replace it with full VSCode if there is a suitable module to use, similar to GitHub CodeSpaces, but more integrated in the UI.

GiteaMirror commented

2025-11-02 07:14:06 -06:00

@ronasuti commented on GitHub (Mar 23, 2021):

Full-Blown Code editor. Currently using monaco but I think we could in the future replace it with full VSCode if there is a suitable module to use, similar to GitHub CodeSpaces, but more integrated in the UI.

There's code-server, which is basically just as easy to install as Gitea and both play nicely together running on the same server (running both as services on Ubuntu 20.04, using Caddy and no-IP to have nice domain names). At the moment, having both Gitea and code-server on the same machine means duplicating git repos on the same machine which could get silly. Code-server is deliberately a bit un-opinionated for how it's hosted or wrapped, and some projects exist that do interesting things with that in mind:

OOTB CodeServer, which includes a Github auth proxy, LXC container wrapping of the code-server instance(s), and monitoring for these moving parts
Colab Code, which allows you to run code-server from within a Colab instance (or anywhere you can run Python, presumably)
VSCode Live, which provides Live Share features with concurrent users, almost on the level of Google Drive
Pomerium code-server, which wraps code-server in Pomerium, an Identity-Aware proxy server, which allows you to run multiple completely different web services and have enterprise-class SSO (SAML, among many others) and advanced access controls stretching across them

Some way to integrate code-server "into"/"alongside" a Gitea server would be really cool, Theia is another candidate but has problems with both more complicated architecture (I've never managed to get either Gitpod or Eclipse Che to run on my server, which is why I'm using code-server) and way more limited extension and feature support compared to code-server.

@ronasuti commented on GitHub (Mar 23, 2021): > * Full-Blown Code editor. Currently using monaco but I think we could in the future replace it with full VSCode if there is a suitable module to use, similar to GitHub CodeSpaces, but more integrated in the UI. There's [code-server](https://github.com/cdr/code-server), which is basically just as easy to install as Gitea and both play nicely together running on the same server (running both as services on Ubuntu 20.04, using Caddy and no-IP to have nice domain names). At the moment, having both Gitea and code-server on the same machine means duplicating git repos on the same machine which could get silly. Code-server is deliberately a bit un-opinionated for how it's hosted or wrapped, and some projects exist that do interesting things with that in mind: 1. [OOTB CodeServer](https://github.com/nullpo-head/Out-of-the-Box-CodeServer), which includes a Github auth proxy, LXC container wrapping of the code-server instance(s), and monitoring for these moving parts 2. [Colab Code](https://github.com/abhishekkrthakur/colabcode), which allows you to run code-server from within a Colab instance (or anywhere you can run Python, presumably) 3. [VSCode Live](https://github.com/coderpair/vscode-live), which provides Live Share features with concurrent users, almost on the level of Google Drive 4. [Pomerium code-server](https://www.pomerium.io/guides/vs-code-server.html#background), which wraps code-server in Pomerium, an Identity-Aware proxy server, which allows you to run multiple completely different web services and have enterprise-class SSO (SAML, among many others) and advanced access controls stretching across them Some way to integrate code-server "into"/"alongside" a Gitea server would be really cool, Theia is another candidate but has problems with both more complicated architecture (I've never managed to get either Gitpod or Eclipse Che to run on my server, which is why I'm using code-server) and way more limited extension and feature support compared to code-server.

GiteaMirror commented

2025-11-02 07:14:06 -06:00

@silverwind commented on GitHub (Mar 23, 2021):

Yeah, I've seen code-server before but it seems like a can of worms to me because it requires a backend server so it would probably be a nightmare to integrate into gitea. I think if we consider integrating some version of VSCode, it must be client-side only which could be integrated with the existing gitea API with some glue code.

@silverwind commented on GitHub (Mar 23, 2021): Yeah, I've seen code-server before but it seems like a can of worms to me because it requires a backend server so it would probably be a nightmare to integrate into gitea. I think if we consider integrating some version of VSCode, it must be client-side only which could be integrated with the existing gitea API with some glue code.

GiteaMirror commented

2025-11-02 07:14:07 -06:00

@techknowlogick commented on GitHub (Mar 23, 2021):

FWIW Gitpod.io is working on supporting arbitrary git repos, which would allow gitea integration (they also are a $5/mo sponsor on opencollective, so who knows maybe they are planning on tighter integration?)

@techknowlogick commented on GitHub (Mar 23, 2021): FWIW Gitpod.io is working on supporting arbitrary git repos, which would allow gitea integration (they also are a $5/mo sponsor on opencollective, so who knows maybe they are planning on tighter integration?)

GiteaMirror commented

2025-11-02 07:14:07 -06:00

@ronasuti commented on GitHub (Mar 24, 2021):

There’s an architecture I can think of that, while a tad janky, would work with little modification of either code-server or Gitea.

As far as I understand, Gitea runs on top of Git in a fairly traditional fashion: edits made, even to the local repo storage for Gitea, don’t show up in Gitea on a repo’s page unless you commit the changes as it only shows what has been committed. In that case, a fairly simple plugin could allow code-server, ran by the Gitea user in a naive single-instance setup, to show local Gitea repos in the UI and open those locally stored repos to edit them in-place. As far as I know, that wouldn’t cause problems and would allow for the actual code-server “server” to stay out of Gitea. The only code on Gitea’s side would be a way to embed the code-server front end (which is distinct from the server) and hook it up to the code-server backend running separately if you want it to fully replace the current Monaco editor. The only serious problem I can see in this is that code-server doesn’t support multi-tenancy beyond just spinning up more instances in VMs.

@ronasuti commented on GitHub (Mar 24, 2021): There’s an architecture I can think of that, while a tad janky, would work with little modification of either code-server or Gitea. As far as I understand, Gitea runs on top of Git in a fairly traditional fashion: edits made, even to the local repo storage for Gitea, don’t show up in Gitea on a repo’s page unless you commit the changes as it only shows what has been committed. In that case, a fairly simple plugin could allow code-server, ran by the Gitea user in a naive single-instance setup, to show local Gitea repos in the UI and open those locally stored repos to edit them in-place. As far as I know, that wouldn’t cause problems and would allow for the actual code-server “server” to stay out of Gitea. The only code on Gitea’s side would be a way to embed the code-server front end (which is distinct from the server) and hook it up to the code-server backend running separately if you want it to fully replace the current Monaco editor. The only serious problem I can see in this is that code-server doesn’t support multi-tenancy beyond just spinning up more instances in VMs.

GiteaMirror commented

2025-11-02 07:14:07 -06:00

@ronasuti commented on GitHub (Mar 24, 2021):

The only “correct” way I can think of supporting this to scalable, HA deployments would be to run Gitea in a Kubernetes or Docker Swarm cluster, then allowing Gitea to spin up (and down) code-server containers and issue them one per editing user.

@ronasuti commented on GitHub (Mar 24, 2021): The only “correct” way I can think of supporting this to scalable, HA deployments would be to run Gitea in a Kubernetes or Docker Swarm cluster, then allowing Gitea to spin up (and down) code-server containers and issue them one per editing user.

GiteaMirror commented

2025-11-02 07:14:07 -06:00

@silverwind commented on GitHub (Aug 20, 2022):

CodeMirror 6 might be a possible replacement for Monaco, it's a from-scratch rewrite of CodeMirror 5. Need to test how it behaves on Mobile and how the language support is (I think Monaco is still better in terms of language support and IntelliSense).

@silverwind commented on GitHub (Aug 20, 2022): [CodeMirror 6](https://marijnhaverbeke.nl/blog/codemirror-6.html) might be a possible replacement for Monaco, it's a from-scratch rewrite of CodeMirror 5. Need to test how it behaves on Mobile and how the language support is (I think Monaco is still better in terms of language support and IntelliSense).

GiteaMirror commented

2025-11-02 07:14:07 -06:00

@lunny commented on GitHub (Apr 3, 2023):

I will close this as #23876 merged.

@lunny commented on GitHub (Apr 3, 2023): I will close this as #23876 merged.

GiteaMirror commented

2025-11-02 07:14:08 -06:00

@silverwind commented on GitHub (Apr 3, 2023):

Yeah for code editor, last I checked, Monaco is still the must featureful editor around. CodeMirror 6 lacks on a few fronts like language support.

@silverwind commented on GitHub (Apr 3, 2023): Yeah for code editor, last I checked, Monaco is still the must featureful editor around. CodeMirror 6 lacks on a few fronts like language support.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#7037