## File: README.md

# VimR — Neovim GUI for macOS

[Download](https://github.com/qvacua/vimr/releases) • [Documentation](https://github.com/qvacua/vimr/wiki)




## About

VimR is a Neovim GUI for macOS written in Swift.

The goal is to build an editor that uses Neovim inside with some of the convenient
GUI features similar to those present in other editors.

There are other Neovim GUIs for macOS,
see the [list](https://github.com/neovim/neovim/wiki/Related-projects#gui), so why VimR?

- Play around with [Neovim](https://github.com/qvacua/neovim),
- Play around with the main idea of Redux architecture, and
- (most importantly) have fun!

If you feel chatty, there is a chat room: <https://matrix.to/#/#vimr:matrix.org>

If you want to support VimR financially, use [Github's Sponsor](https://github.com/sponsors/qvacua).

## Download

Pre-built Universal signed and notarized binaries can be found under [Releases](https://github.com/qvacua/vimr/releases).

## Requirements

- macOS 13.0 or later
- Development: Xcode 26

## Reusable Components

VimR is built with a modular architecture. The following Swift packages can be used independently:

* [NvimView](https://github.com/qvacua/vimr/tree/master/NvimView): SwiftPM module containing an NSView which bundles everything needed to embed Neovim in a Cocoa app, including the Neovim binary and runtime files.
* [NvimApi](https://github.com/qvacua/vimr/tree/master/NvimApi): Synchronous and asynchronous API for Neovim.
* [Commons](https://github.com/qvacua/vimr/tree/master/Commons): Common utilities and helpers used across the project.
* [Tabs](https://github.com/qvacua/vimr/tree/master/Tabs): Tab bar component.
* [Workspace](https://github.com/qvacua/vimr/tree/master/Workspace): Workspace management component.
* [Ignore](https://github.com/qvacua/vimr/tree/master/Ignore): Gitignore-style pattern matching using [wildmatch](https://github.com/davvid/wildmatch).

## Features

* Markdown preview
* Generic HTML preview (retains the scroll position when reloading)
* Fuzzy file finder a la Xcode's "Open Quickly..."
* Trackpad support: Pinching for zooming and two-finger scrolling.
* Ligatures: Turned off by default. Turn it on in the Preferences.
* Command line tool.
* (Simple) File browser
* Flexible workspace model a la JetBrain's IDEs

## How to Build

Clone this repository. Install `homebrew`, then in the project root:

```bash
git submodule update --init

xcode-select --install # install the Xcode command line tools, if you haven't already
brew bundle # install dependencies, e.g., build tools for Neovim
clean=true notarize=false trust_plugins=true ./bin/build_vimr.sh
```

*   `trust_plugins=true`: Skips the interactive package plugin validation (SwiftLint), allowing the build to proceed in a non-interactive shell.
*   `notarize=false`: Skips the Apple notarization process and performs an ad-hoc signature instead.

The built application will be located at `./build/Build/Products/Release/VimR.app`.

For convenience, you can use the helper script to build and overwrite the application in `/Applications`:

```bash
./bin/build_and_install_local_release.sh
```

## Development

See [DEVELOP.md](DEVELOP.md).

## License

[MIT](https://github.com/qvacua/vimr/blob/master/LICENSE)

---

## File: bin/README.md

## How to use

* `cd` into `${PROJECT_ROOT}/bin`, this directory.
* Install pyenv and pyenv-virtuelenv.
* Install Python 3.9.7 using pyenv.
* Create a virtualenv with the name `com.qvacua.VimR.bin`.
* Ensure that you're running the Python in the virtualenv by
    ```bash
    pyenv which python
    /${HOME}/.pyenv/versions/com.qvacua.VimR.bin/bin/python
    ```
* Install the requirements
    ```bash
    pip install -r requirements.txt
    ```

---

## File: ci/README.md

* Install Jenkins (via brew)
* Install plugins
    - Job DSL
    - AnsiColor
* Set the `git` binary in *Manage Jenkins* -> *Global Tool Configuration*
* Set `PATH` for Jenkins (necessary for e.g. `git-lfs`) in *Manage Jenkins* -> *Configure System* -> *Global properties* -> *Environment variables"
* Add a free style job `vimr_setup_jobs` with one step to process a Job DSL file at `ci/create_build_job.groovy`.
  - Approve script at *Manager Jenkins* -> *In-process Script Approval*.

---

To test the job creation using local git repository, use `file:///Users/.../vimr-repo` as repository and add "-Dhudson.plugins.git.GitSCM.ALLOW_LOCAL_CHECKOUT=true" to `/opt/homebrew/opt/jenkins/bin/jenkins`:

```bash
#!/bin/bash
export JAVA_HOME="${JAVA_HOME:-/opt/homebrew/opt/openjdk/libexec/openjdk.jdk/Contents/Home}"
exec "${JAVA_HOME}/bin/java" "-Dhudson.plugins.git.GitSCM.ALLOW_LOCAL_CHECKOUT=true" "-jar" "/opt/homebrew/Cellar/jenkins/2.435/libexec/jenkins.war" "$@"
```

---

## File: docs/notes-on-cocoa-text-input.md

# Some Notes on Cocoa's Text Input

To use Cocoa's text input system, e.g. the 2-Set Korean input, your view has to implement the [NSTextInputClient](https://developer.apple.com/reference/appkit/nstextinputclient) protocol. Apple's documentation is very scarce, so we're writing down some of our findings.

## Simple Case

For simple cases like `ü`, which can be entered by `Opt-u` + `u`, it's quite straightforward:

1. Enter `Opt-u`.
1. `hasMarkedText()` is called to check whether we already have marked text.
1. `setMarkedText("¨", selectedRange NSRange(1, 0), replacementRange: NSRange(NSNotFound, 0))` is called. In this case the first argument is an `NSString`, `selectedRange` tells us where to put the cursor relative to the string: in this case after `¨`. The range `replacemenRange` tells us whether the string should replace some of the existing text. In this case no replacement is required.
1. Enter `u`.
1. `hasMarkedText()` is called again.
1. `insertText("ü", replacementRange: NSRange(NSNotFound, 0))` is called to finalize the input. It seems that for the replacement range `(NSNotFound, 0)` we should replace the previously marked text with the final string. So in this case we must first delete `¨` and insert `ü`.

## Korean (Hangul, 한글)

Let's move to a bit more complicated case: Korean. In this case more methods are involved:

* `selectedRange()`: all other additional methods seem to rely on this method. Ideally we should return `NSRange(CursorPosition, 0)` when nothing is selected or `NSRange(SelectionBegin, SelectionLength)` when there's a selection.
* `attributedSubstringForProposedRange(_:actualRange:)`: for entering only Hangul, this method can be ignored.

Let's assume we want to enter `하태원`: (`hasMarkedText()` is called here and there...)

1. `selectedRange()` is called multiple times when changing the input method from US to Korean. This is also the case when starting the app with Korean input selected.
1. Enter `ㅎ`.
1. `setMarkedText("ㅎ", selectedRange: NSRange(1, 0) replacementRange:NSRange(NotFound, 0))` is called.
1. Enter `ㅏ`.
1. `attributedSubstringForProposedRange(_:actualRange:)` and `selectedRange()` are called multiple times: again, for only Hangul, ignorable.
1. `setMarkedText("하", selectedRange: NSRange(1, 0), replacementRange: NSRange(NotFound, 0))` is called: delete `ㅎ` and insert `하`; not yet finalized.
1. Enter `ㅌ`
1. `attributedSubstringForProposedRange(_:actualRange:)` and `selectedRange()` are called multiple times: ignore.
1. `setMarkedText("핱", selectedRange: NSRange(1, 0), replacementRange: NSRange(NotFound, 0))` is called: delete `하` and insert `핱`; not yet finalized.
1. Enter `ㅐ`
1. `attributedSubstringForProposedRange(_:actualRange:)` and `selectedRange()` are called multiple times: ignore.
1. `setMarkedText("하", selectedRange: NSRange(1, 0), replacementRange: NSRange(NotFound, 0))` is called: delete `핱` and insert `하`; not yet finalized.
1. `insertText("하", replacementRange: NSRange(NotFound, 0))` is called to finalize the input of `하`.
1. `attributedSubstringForProposedRange(_:actualRange:)` and `selectedRange()` are called multiple times: ignore.
1. `setMarkedText("태", selectedRange: NSRange(1, 0), replacementRange: NSRange(NotFound, 0))` is called: Since the replacement range is `NotFound`, append the marked text `태` to the freshly finalized `하`.
1. ...

## Hanja (한자)

Let's consider the even more complicated case: Hanja in Korean. In this case the `selectedRange()` and `attributedSubstringForProposedRange(_:actualRange:)` play a vital role and also

* `firstRectForCharacterRange(_:actualRange)`: this method is used to determine where to show the Hanja popup. The character range is determined by `selectedRange()`.

Let's assume we want to enter `河`: (again `hasMarkedText()` is called here and there...)

1. Enter `ㅎ`.
1. `setMarkedText("ㅎ", selectedRange: NSRange(1, 0) replacementRange:NSRange(NotFound, 0))` is called.
1. Enter `ㅏ`.
1. `attributedSubstringForProposedRange(_:actualRange:)`, `selectedRange()` and `hasMarkedText()` are called multiple times: again, for only Hangul, ignorable.
1. `setMarkedText("하", selectedRange: NSRange(1, 0), replacementRange: NSRange(NotFound, 0))` is called: delete `ㅎ` and insert `하`; not yet finalized.
1. Enter `Opt-Return`.
1. `setMarkedText("하", selectedRange: NSRange(1, 0), replacementRange: NSRange(NotFound, 0))` is called again.
1. `selectedRange()` is called: here we should return a range which can be consistently used by `attributedSubstringForProposedRange(_:actualRange)` and `firstRectForCharacterRange(_:actualRange)`.
1. `insertText("하", replacementRange: NSRange(NotFound, 0))` is called even we are not done yet... So our view thinks we finalized the input of `하`.
1. `attributedSubstringForProposedRange(_:actualRange)` is called multiple times to get the Hangul syllable to replace with Hanja. The proposed range can be very different in each call.
1. Only if the range from `selectedRange()` could be somehow consistently used in `attributedSubstringForProposedRange(_:actualRange)`, then the Hanja popup is displayed. Otherwise we get the selector `insertNewlineIgnoringFieldEditor` in `doCommandBySelector()`.
1. `setMarkedText("下" , selectedRange: NSRange(1, 0), replacementRange: NSRange(1, 1))` is called: the replacement range is not `NotFound` which means that we first have to delete the text in the given range, in this case the finalized `하` and then append the marked text.
1. Selecting different Hanja calls the usual `setMarkedText(_:selectedRange:actualRange)` and `Return` finalizes the input of `河`.

## Chinese Pinyin

suppose we want to enter 中国

1. we should enter the pinyin `zhongguo`, then `<Space>` to confirm it.
2. each char input triggers: setMarkedText, markedRange, firstRect, attributedSubstringForProposedRange
3. finally setMarkedText("zhong guo", selectedRange: NSRange(10, 0), replacementRange: NSRange(NotFound, 0)) iscalled:
4. then after `<Space>` enter, insertText("中国", replacementRange: NSRange(NotFound, 0)) is called
5. many selectedRange and attributedSubstring(forProposedRange:actualRange:) calls.

this seems right simple. but when in markedtext state(before confirming it),
1. we can use number to select other candidates
2. we can use `=`, `-`, ``, `<DOWN>`, `<Left>`, `<Right>` to choose candidate, and vim shouldn't handle it.
3. we can use `<Left>`, `<Right>` to move in marked text, and insert char in middle of markedText. even complicate, the move is not by char, but by word.

each marked text or marked cursor changes, setMarkedText will called, with selectedRange point to the marked cursor position(may be middle, not the text end)

so these key shouldn't be handle by vim directly when in marked text state.

and finally we confirmed all markedtext, then a `insertText` will be called

## Other Writing System

Not a clue, since I only know Latin alphabet and Korean (+Hanja)...