나는 자주 프로그래밍 포럼을위한 튜토리얼과 기사를 쓰고 싶다. 이 포럼에는 게시물 당 글자 수 제한이 있습니다. 과거에 메모장 ++을 사용하여 게시물을 작성했으며 상태 표시 줄에 라이브 문자 수를 유지합니다. gVim을 더 많이 사용하기 시작했고이 시점에서 메모장 ++로 돌아가고 싶지는 않지만이 문자 수를 갖는 것이 매우 유용합니다. 카운트를 넘어 가면 보통 포스트를 메모장 + +에 붙여 넣고 한계에 도달하기에 충분히 손질 된 시점을 볼 수 있습니다.
:set ruler
도움이 될만한 제안을 보았지만 현재 줄의 현재 열 색인을 통해 문자 수만 제공합니다. 단락 나누기를 사용하지 않으면 좋을 것입니다. 그러나 한 단락에서 수천 문자를 읽는 것이 불편하다는 데 동의 할 것입니다.
도움말을 읽고 rulerformat
작동 한다고 생각 했지만 statusline
형식 을 살펴본 후 현재 버퍼의 문자 수를 제공하는 것을 보지 못했습니다.
나는 이것을 추가하는 플러그인이 있다는 것을 보았지만 여전히 발가락을 gVim에 담그고 있으며 내가하는 일을 이해하기 전에 임의의 플러그인을로드하고 싶지는 않습니다. vim에 내장 된 것을 사용하고 싶지만 존재하지 않으면 존재하지 않습니다.
목표를 달성하려면 어떻게해야합니까? 플러그인과 관련이 있다면 플러그인을 사용하고 얼마나 잘 작동합니까?
답변
를 눌러 g CTRL-G
일반 모드에서 커서 및 파일에 대한 통계를 표시합니다.
리눅스에 있다면 wc -m
현재 파일에서 문자 수를 얻는 데 사용할 수 있습니다
:!wc -m %
실시간으로 업데이트되지 않기 때문에이 명령을 다음과 같이 매핑 할 수 있습니다.
map <F4> :!wc -m %<CR>
답변
:help count-items
교체 알라의 드라이 런을 할 수 있다고 제안합니다.
:%s/./&/gn
(그러면 일치하는 문자 수를 다시보고) strlen()
시각적으로 선택된 텍스트를 멋지게 표현 합니다.
:echo strlen(@")
( “는 이름이없는 레지스터입니다)
상태 표시 줄에서 표현식을 호출하면 %{myfunc()}
좋은 출발점이 될 수 있습니다. 전체 텍스트를 선택한 다음 잡아야하기 때문에 모든 시간을 계산하는 데 약간의 시간이 소요될 수 있습니다. 버퍼의 문자 수 : 버퍼의 모든 텍스트를 시각적으로 선택하고 잡아 당기면 해결책은 다음과 같습니다.
:set statusline=%{strlen(@")}
“-레지스터에있는 문자 수를 제공합니다 (현재 버퍼를 선택하고 잡아 당기는 경우 바이트 수와 동일).
답변
mrucci의 답변 향상 :
다음과 같이 명령 출력을 지정 wc
하여 파일을 먼저 저장하지 않고도 Linux에서 사용할 수 있습니다 :w
.
:w !wc -m
mrucci가 언급 한 것과 매핑 할 수 있습니다.
답변
:help statusline
너에게 준다
o N Byte number in file of byte under cursor, first byte is 1.
Mnemonic: Offset from start of file (with one added)
또한 문제에 대한 좋은 해결 방법입니다. 버퍼의 끝으로 가면 G상태 표시 줄에 표시된 바이트 번호는 문자 수입니다 (물론 멀티 바이트 문자에는 해당되지 않음). 에서 온 곳으로 돌아갑니다 ctrlo.
답변
파일을 저장하기 위해 : w를 사용하는 습관이 있다면, 이렇게 할 때마다 상태는 기록 된 문자 수를 다시보고합니다. 예를 들어,이 문장의 끝에 나는 : w (예,이 메모를 작성하기 위해 gvim을 사용하고 있습니다)를했으며 245C가 기록되었습니다.
답변
다음과 같이 상태 표시 줄에 버퍼의 바이트 수를 표시하는 표현식을 추가 할 수 있습니다.
:set statusline+=\ %{\ line2byte(line(\"$\")+1)-1\ }B
또는 모든 탈출을 피하기 위해 옵션 변수를 직접 변경할 수 있습니다.
:let &statusline .= ' %{ line2byte(line("$")+1)-1 }B'
답변
해결 방법 mrucci의 답변을 수락 할 때까지 사용했습니다.
실수로 파일을 저장하기 위해 : w를 쓰면 명령이 쓴 바이트 수를 출력한다는 것을 알았습니다. 이것은 거의 문자 수이므로 지금까지 충분히 가깝습니다. 나는 mrucci의 대답도 좋아합니다. 단어 개수도 있기 때문에 아마도 이것보다 더 좋습니다.