편집기 — .tbs 를 쓰는 동안 확인하기
.tbs 파일을 쓰는 동안 오타와 타입 오류를 그 자리에서 봅니다. 변환을 돌리고 나서가 아니라
타자를 치는 동안입니다.
| 무엇 |
|---|
| 문법 강조 — 키워드 · 내장 타입 · 선언 이름 · 와이어 태그 · 메타데이터 · 주석 |
진단 — 문법 오류, 이름이 두 번 선언된 것, extends 와 판별자 |
정의로 이동(F12) — 타입 이름과 extends 뒤의 이름에서 그것을 선언한 자리로 |
호버 — 선언 한 줄과 그 위의 /// 문서 |
자동완성 — 줄을 여는 낱말, 멤버의 타입, extends 뒤의 이름, 메타데이터 키, enum 기본값 |
| 정확한 색 — 이름 하나하나를 struct · enum · enum 값 · 멤버 · 내장 타입으로 갈라서 |
두 조각
확장은 서버 없이도 되는 만큼을 하고, 나머지는 도구가 판정합니다.
VS Code 확장 ──(대강의 색)──▶ TextMate 문법
│
└──(진단 · 이동 · 호버 · 자동완성 · 정확한 색)──▶ tabbit lsp
│
▼
변환이 쓰는 그 파서
판정이 편집기에 따로 들어 있지 않습니다. tabbit lsp 는 변환이 돌리는 파서를 그대로
돌리므로, 편집기가 빨간 줄을 긋는 것과 빌드가 거부하는 것이 같은 답입니다.
색이 두 곳에서 나오는 것은 서버가 없을 때에도 읽을 수 있게 하기 위해서입니다. TextMate 문법은 낱말의 생김새만 보므로 타입 자리의 이름을 전부 같은 색으로 칠하고, 서버가 붙으면 그 위에 실제 정체 — struct인지 enum인지 내장 타입인지 — 로 다시 칠합니다.
설치
확장은 도구와 따로 배포됩니다. 릴리즈에서
tbs-v 로 시작하는 태그의 .vsix 를 받아 설치합니다.
code --install-extension tabbit-tbs-0.0.1.vsix
따로인 이유는 둘이 함께 바뀌지 않기 때문입니다. 하이라이팅 하나를 고치는 데 플랫폼 바이너리 6개를 다시 구울 이유가 없고, 도구를 올린다고 바뀌지 않은 확장을 다시 건네야 할 이유도 없습니다.
직접 만들려면 이렇게 합니다.
cd tools/vscode
yarn install
yarn package
code --install-extension tabbit-tbs-0.0.1.vsix
확장은 tabbit 실행 파일을 설정 → PATH → 이 저장소의 빌드 산출물 순으로 찾 습니다.
설치한 도구가 PATH 에 있으면 설정할 것이 없습니다.
자세한 것은 확장의 readme에 있습니다 — 설정 셋, 눈으로 확인하는 절차, 서버가 뜨지 않을 때 볼 곳.
워크북 없이 판정하는 범위
서버는 .tbs 파일만 읽습니다. 그래서 시트가 있어야 판정할 수 있는 것은 여기서
판정하지 않습니다 — foreign 뒤의 테이블 이름이 그렇습니다. 그 이름이 실재하는지는 변환이
판정합니다.
이것은 결손이 아니라 설계입니다. 타입이 .tbs 파일 집합만으로 닫히도록 만들어져 있고, 그래서
편집기가 워크북을 열지 않고도 성립합니다.
타입 이름을 잘못 적은 것도 여기서는 빨간 줄이 아닙니다 — 그 검사 역시 시트를 봅니다. 대신 그 이름만 색을 잃습니다. 옆의 알아본 이름들과 달라 보이는 것이 그때 주어지는 신호입니다.
한 벌은 디렉터리 하나
한 폴더의 .tbs 가 한 벌로 검사됩니다. 폴더가 다르면 서로 아무 상관이 없습니 다 —
레시피가 가리키는 것이 폴더이므로, 편집기가 보는 단위와 변환이 보는 단위가 같습니다.
한 레시피가 폴더 여러 개를 한 벌로 읽으면 그 경계가 편집기에 보이지 않습니다. 폴더를 넘는 참조가 「선언을 찾을 수 없음」으로 잘못 보고됩니다. 편집기 지원의 4.2절에 적어 두었습니다.
다른 편집기
tabbit lsp 는 표준 입출력으로 통신하는 보통의 언어 서버입니다. LSP를 붙일 수 있는 편집기면
tabbit lsp 를 명령으로 두고 .tbs 를 그 서버에 붙이면 됩니다. 색은 따로입니다 —
TextMate 문법을 그 편집기의 형식으로
옮겨야 합니다.