feat: configure cursor appearance by editing mode

This commit is contained in:
2026-10-26 15:01:19 +01:00
parent 846803a3e2
commit ce434a1c17
13 changed files with 356 additions and 51 deletions
+3 -23
View File
@@ -1,26 +1,6 @@
- [x] improve: conflict resolution view.
- two-pane mode:
- currently, we display the two panes as if it were a diff, where the left side will be displayed as if the code in question will be removed, and the left pane will display the code in question as if it will be added.
- this doesn't really make sense, since code on either side (either version) will be added/removed.
- i'm wondering if it would make sense to display in both panels both changes that would and changes that would add code, meaning:
- if some code would be removed, it would display in red with a minus
- if some code would be added, it would display in green with a plus
- this would be the case for both panes
- probably something similar for three-pane mode would make sense.
- [x] improve: code commenting format. example of comment in current format:
<attachment>
Comment 14 [unresolved] source/sema/resolve.hon (after) 22:9–22:19 @ working:a3b4159a340b3546e2108bc2dc0e7c302fc6d84b
[8]Builtin
can't we do `[_]Builtin` here instead for array size inference? if not, this is probably an oversight in the brolang compiler 🤔
</attachment>
- would probably be nice to instead do this though, if possible, i.e. wrapping the code snippet in question in a codeblock annotated with the right language, e.g.:
<attachment>
Comment 14 [unresolved] source/sema/resolve.hon (after) 22:9–22:19 @ working:a3b4159a340b3546e2108bc2dc0e7c302fc6d84b
```hon
[8]Builtin
```
can't we do `[_]Builtin` here instead for array size inference? if not, this is probably an oversight in the brolang compiler 🤔
</attachment>
- [x] improve: editing - color the cursor to match the current mode.
- enabled by default but should be configurable.
- should also be able to configure the cursor character used based on mode (default is just the block cursor as it is now).
- [ ] feature: diff view - GitHub code review integration after the local review UX is usable.
- publish local reviews explicitly: general PR comments, inline line/range comments, review summaries, approval, and requests for changes.
- preserve explicit PR identity and reviewed commit IDs; validate anchors against GitHub's PR diff and recheck the PR head before submission.