- Replace the [Monaco Editor](https://microsoft.github.io/monaco-editor/)
with [CodeMirror 6](https://codemirror.net/). This editor is used to
facilitate the 'Add file' and 'Edit file' functionality.
- Rationale:
- Monaco editor is a great and powerful editor, however for Forgejo's
purpose it acts more like a small IDE than a code editor and is doing
too much. In my limited user research the usage of editing files via
the web UI is largely for small changes that does not need the
features that Monaco editor provides.
- Monaco editor has no mobile support, Codemirror is very usable on mobile.
- Monaco editor pulls in large dependencies (for language support) and
by replacing it with Codemirror the amount of time that webpack needs
to build the frontend is reduced by 50% (~30s -> ~15s).
- The binary of Forgejo (build with `bindata` tag) is reduced by 2MiB.
- Codemirror is much more lightweight and should be more usable on
less powerful hardware, most notably the lazy loading is much faster
as codemirror uses less javascript.
- Because Codemirror is modular it is much easier to change the
behavior of the code editor if we wish to.
- Drawbacks:
- Codemirror is quite modular and as seen in `package.json` and in
`codeeditor.ts` we have to supply a lot more of its features to have
feature parity with Monaco editor.
- Monaco editor has great integrated language support (features that
an lsp would provide), Codemirror only has such language support to an
extend.
- Monaco editor has its famous command palette (known by many as its
also available in VSCode), this is not available in code mirror.
- Good to note:
- All features that was added on top of the monaco editor (such as
dynamically changing language support depending on the filename)
still works and the theme is based on the VSCode colors which largely
resembles the monaco editor.
- The code editor is still lazy-loaded (this is painfully clear by
reading how imports are passed around in `codeeditor.ts`).
- This change was privately tested by a few people, a few bugs were
found (and fixed) but no major drawbacks were noted for their usage of
the web editor.
- There's a "search" button in the top bar, so that search can be used
on mobile. It is otherwise only accessible via
<kbd>Ctrl</kbd>+<kbd>f</kbd>.
Co-authored-by: Beowulf <beowulf@beocode.eu>
Co-authored-by: Gusted <postmaster@gusted.xyz>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10559
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Reviewed-by: 0ko <0ko@noreply.codeberg.org>
Co-committed-by: Beowulf <beowulf@beocode.eu>
Fix#3638
This is a manual Forgejo-specific version of the Gitea PR https://github.com/go-gitea/gitea/pull/30862. The weekly Forgejo PR #3772 could not cherry-pick this commit due to conflicts (eg subsequent CodeSpell changes).
Only occurs with Webkit in Safari over eg `http://192..`. (not localhost).
See https://webkit.org/blog/10855/async-clipboard-api/
---
**Before**
**After**
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/3805
Reviewed-by: Otto <otto@codeberg.org>
Co-authored-by: David Davies-Payne <d2p@me.com>
Co-committed-by: David Davies-Payne <d2p@me.com>
More about codespell: https://github.com/codespell-project/codespell .
I personally introduced it to dozens if not hundreds of projects already and so far only positive feedback.
```
❯ grep lint-spell Makefile
@echo " - lint-spell lint spelling"
@echo " - lint-spell-fix lint spelling and fix issues"
lint: lint-frontend lint-backend lint-spell
lint-fix: lint-frontend-fix lint-backend-fix lint-spell-fix
.PHONY: lint-spell
lint-spell: lint-codespell
.PHONY: lint-spell-fix
lint-spell-fix: lint-codespell-fix
❯ git grep lint- -- .forgejo/
.forgejo/workflows/testing.yml: - run: make --always-make -j$(nproc) lint-backend checks-backend # ensure the "go-licenses" make target runs
.forgejo/workflows/testing.yml: - run: make lint-frontend
```
so how would you like me to invoke `lint-codespell` on CI? (without that would be IMHO very suboptimal and let typos sneak in)
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/3270
Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org>
Co-authored-by: Yaroslav Halchenko <debian@onerussian.com>
Co-committed-by: Yaroslav Halchenko <debian@onerussian.com>
- `e.error` can be undefined in some cases which would raise an error
inside this error handler, fixed that.
- The displayed message mentions looking into the console, but in my
case of error from `ResizeObserver` there was nothing there, so add this
logging. I think this logging was once there but got lost during
refactoring.
(cherry picked from commit 6d9b7253a2de00b5dfc27550cf7e015e819d6fd2)
Gitea treat JS errors seriously, so sometimes the JS errors caused by
3rdparty code (eg: browser extensions) would also be reported on Gitea
UI: TypeError: WeakMap key undefined (caused by extension DarkReader's
bug) #28861
To avoid fill the user's screen with a lot of error messages, this PR
merges the same error messages into one, like this:
```js
<div class="page-content">
<div class="... js-global-error" data-global-error-msg-compact="testmsg1" data-global-error-msg-count="2">test msg 1 (2)</div>
<div class="... js-global-error" data-global-error-msg-compact="testmsg2" data-global-error-msg-count="1">test msg 2</div>
</div>
```
In GitHub, we can not rerun jobs if the workflow is disabled.
---------
Co-authored-by: silverwind <me@silverwind.io>
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Partially for #24457
Major changes:
1. The old `signedUserNameStringPointerKey` is quite hacky, use
`ctx.Data[SignedUser]` instead
2. Move duplicate code from `Contexter` to `CommonTemplateContextData`
3. Remove incorrect copying&pasting code `ctx.Data["Err_Password"] =
true` in API handlers
4. Use one unique `RenderPanicErrorPage` for panic error page rendering
5. Move `stripSlashesMiddleware` to be the first middleware
6. Install global panic recovery handler, it works for both `install`
and `web`
7. Make `500.tmpl` only depend minimal template functions/variables,
avoid triggering new panics
Screenshot:
<details>
</details>
fixes: https://github.com/go-gitea/gitea/issues/21733
Uncaught Error: Language id "vs.editor.nullLanguage" is not configured
nor known
Note that this monaco-editor worked fine on 0.33.0 and broke on 0.34.0.
If upstream fixed, remove this code.
Signed-off-by: Xinyu Zhou <i@sourcehut.net>
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
* ROOT_URL issues: some users did wrong to there app.ini config, then:
* The assets can not be loaded (AppSubUrl != "" and users try to access http://host:3000/)
*The ROOT_URL is wrong, then many URLs in Gitea are broken.
Now Gitea show enough information to users.
* JavaScript error issues, there are many users affected by JavaScript errors, some are caused by frontend bugs, some are caused by broken customized templates. If these JS errors can be found at first time, then maintainers do not need to ask about how bug occurs again and again.
* Some people like to modify the `head.tmpl`, so we separate the script part to `head_script.tmpl`, then it's much safer.
* use specialized CSS class "js-global-error", end users still have a chance to hide error messages by customized CSS styles.
