libvim

libvim 무엇입니까?

libvim Vim 모달 편집을 모델링하고 최소한의 C 기반 API를 제공하는 것을 목표로 하는 Vim의 포크입니다. 여기에는 사용자 인터페이스가 전혀 포함되어 있지 않으며(터미널 UI도 포함하지 않음) 주로 Vim 키 입력에 충실한 빠른 버퍼 조작 엔진 역할을 담당합니다. 아직 진행 중인 작업이며 안정화해야 할 작업이 많이 남아 있습니다.

터미널 Vim을 찾고 있다면 neovim을 확인하거나 GUI Vim을 찾고 있다면 Onivim 2를 확인하세요.

왜?

libvim 주로 Onivim 2용으로 만들어졌습니다. v1, v2 및 다른 프로젝트 간에 'UI Vims'를 여러 번 구현한 후 제가 원했던 추상화는 터미널 UI와 완전히 분리된 일종의 순수 기능적 Vim이었습니다. 여기서 'vim'은 '는 (editor state, input) => (new editor state) 의 함수입니다. Onivim 2는 렌더링 레이어를 완벽하게 처리하므로 이 Vim 모델은 순수 함수로 버퍼 조작에만 집중할 수 있습니다.

이를 위해 libvim Vim 작업을 위한 간단한 C API를 공개하고 버퍼 변경 사항, 메시지 등의 수신을 지원합니다.

다음을 담당합니다.

• 버퍼 관리 및 조작
• 입력에 대한 응답으로 버퍼 조작
• VimL 구문 분석 및 소싱
• 키 재매핑 처리

다음 사항에 대해서는 책임을 지지 않습니다 :

• 모든 종류의 UI 렌더링(터미널 등)
• 마우스 지원
• 구문 강조
• 맞춤법 검사
• 터미널 지원
• 완성
• 입력 방법(IME)

이들 모두는 라이브러리 소비자가 처리하도록 의도되었으며 libvim 빠른 버퍼 조작 작업에 집중하게 됩니다.

libvim WebAssembly뿐만 아니라 크로스 플랫폼(Onivim 2가 필요하기 때문에!)을 빌드합니다. v1 튜토리얼을 브라우저 기반 환경으로 이식하고 싶습니다.

'추상화된 Vim'의 다른 흥미로운 응용 프로그램도 있습니다:

• WebAssembly 빌드는 브라우저/웹사이트에서 Vim 모드를 구현하는 데 유용할 수 있습니다.
• 네이티브 빌드는 Vim 네이티브 바인딩을 원하는 애플리케이션에 유용할 수 있습니다. 예를 들어 readline 구현을 위한 좋은 기반이 될 것입니다.

API

API 사용법의 예를 보려면 Normal_mode_motion과 같은 apitest를 확인하세요. 전체 API는 여기에서 사용할 수 있습니다: libvim.h

API의 핵심은 단일 키를 사용하고 상태 시스템에 의해 동기식으로 처리되는 vimInput 입니다. 버퍼 업데이트, 메시지 등과 같은 '부작용'은 vimSetBufferUpdateCallback 과 같은 콜백을 통해 구독할 수 있습니다.

이 라이브러리는 활발하게 개발 중이며 현재는 이전 버전과의 호환성을 보장하지 않습니다. API 사용에 따른 책임은 본인에게 있습니다.

컴파일 중

esy 설치

esy 네이티브 코드의 npm 과 같습니다. 아직 설치하지 않은 경우 다음을 실행하여 설치하세요.

 npm install -g [email protected]

소스 가져오기

• git clone https://github.com/onivim/libvim
• cd src

종속성 설치

• esy install
• esy '@test' install

건물

• esy build

테스트 실행

• esy '@test' build

개발

esy 워크플로는 일회성 빌드에 적합하지만 매번 월드를 다시 빌드하므로 개발 중에는 점진적인 워크플로를 사용하는 것이 더 좋습니다.

점진적으로 테스트 구축 및 실행

• cd src
• make apitest/autoindent.test.exe
• cd apitest
• ./autoindent.test.exe

Onivim 2에 대한 변경 사항 테스트

다음과 같이 Onivim 2 package.json 에 해상도를 추가하여 로컬로 빌드된 Onivim 2에 대해 로컬로 빌드된 libvim 테스트할 수 있습니다.

 "resolutions" : {
	...
	"libvim" : " link:../libvim/src "
}

libvim/src 폴더를 가리키는지 확인하세요.

참고: Onivim 2에서 바이너리가 최신 상태가 아닐 수 있는 이 워크플로의 문제를 확인했으므로 각 변경 후에 rm -rf _esy && esy i 실행하여 종속성을 다시 빌드하는 것이 좋습니다.

FAQ

libvim Neovim이 아닌 Vim을 기반으로 하는 이유는 무엇입니까?

저는 Neovim 팀이 수행하는 작업의 열렬한 팬입니다(그리고 팀은 Onivim 프로젝트를 엄청나게 지원했습니다). 이상적으로는 Neovim을 사용하거나 libnvim 기반으로 libvim 구현했을 것입니다. 사실, 처음으로 이 '최소 추상화'를 구축하려고 시도했을 때 Neovim의 libnvim 기반으로 하려고 했습니다. 조사 기간을 2일로 제한했고 몇 가지 심각한 장애물에 부딪혔습니다. 우리의 빌드 환경은 Windows에서 약간 까다롭습니다(Cygwin + MingW 크로스 컴파일러 툴체인을 기반으로 함) - 해당 환경에서 Neovim + deps를 빌드하는 데 몇 가지 문제가 발생했습니다. . 이러한 급증을 기반으로 해당 툴체인에서 작동하려면 최대 3~4주가 걸릴 것으로 예상했습니다.

이는 Neovim 문제가 아닙니다. CMake 의 종속성 사용 및 활용은 좋은 결정입니다. 이는 OCaml 빌드 시스템의 결과입니다. Cygwin + MingW 크로스 컴파일러 툴체인은 모든 종속성에 의해 잘 처리되지 않습니다(Win32와 Unix의 이상한 하이브리드이기 때문에 #ifdef가 잘못되거나 잘못된 종속성을 가져오는 경우가 많으며 엄청난 시간 낭비가 될 수 있음) 이러한 문제를 해결하기 위해 노력하고 있습니다).

대조적으로 Vim은 해당 환경에서 쉽게 컴파일할 수 있었습니다(참고: 누구든지 크로스 플랫폼, esy 지원 Neovim 패키지 구축에 관심이 있다면 이 패키지를 다시 방문할 수 있습니다!). 저는 Onivim v1 튜토리얼을 웹으로 포팅하기 위한 WebAssembly 빌드에도 관심이 있습니다. WebAssembly로 컴파일된 이 C 추상 라이브러리가 완벽하게 적합할 것입니다.

빌드 문제 외에도 Neovim과 Vim은 모두 동기식 기능 API를 제공하기 위해 리팩토링이 필요합니다.

• Neovim은 해당 API를 제공하기 위해 단락시키거나 제거해야 하는 이벤트 루프를 핵심에서 사용합니다.
• Vim은 기능적 API를 지원하려면 반전이 필요한 차단 입력을 사용합니다.

이 모든 작업의 ​​동기는 복잡성과 오류 모드를 줄이기 위해 Onivim v2에서 RPC 계층을 제거하는 것이었습니다. 결국 이는 순전히 제약 조건 기반의 기술 결정이었습니다. nvim 사용하여 esy 크로스 플랫폼을 통해 구축 가능한 유사한 API를 얻을 수 있다면 기꺼이 사용하겠습니다 :)

지원

libvim 에 관심이 있고 개발을 지원하고 싶다면 다음을 고려하세요.

• Onivim 2 선주문
• Patreon 지원

기여

libvim 더 좋게 만드는 데 도움을 주고 싶다면 CONTRIBUTING.md 파일을 참조하세요.

기여할 수 있는 장소:

• 테스트 사례를 추가하는 데 도움을 주세요.
• libvim 에 필요하지 않은 코드나 기능을 제거하도록 도와주세요.
• Vim에서 패치를 포팅하는 데 도움을 주세요

특허

libvim 코드는 MIT 라이선스에 따라 라이선스가 부여됩니다.

또한 타사 코드, 특히 Vim 및 기타 코드에 따라 달라집니다. 라이선스 세부정보는 ThirdPartyLicenses.txt를 참조하세요.