Vim 전문가가 왜 탭보다 버퍼를 선호합니까?

버퍼를 이해 하지 못합니다 . 같은 탭에서 3 개의 파일을 열고 창을 닫을 때 일반적으로 다음에 이상한 스왑 파일이 남아 있고 성가신 메시지가있는 파일 중 하나를 열 때 짜증이납니다. 그러나 나는 이러한 것들이 내가 놓친 생산성 너바나이며, 플레 비안들이 사용할 수있는 탭이라는 것을 다시 한번 읽었습니다.

Vim 전문가에게 물어보십시오. 탭보다 버퍼를 사용하면 어떤 이점이 있습니까? 나는 그 차이가 어떻게 크게 다른지 알지 못하지만 Vim 운영의 초급-중급 수준에서만 나 자신을 고려할 것입니다. 가 :ls :b#훨씬 빠르게보다가 정말 gt주위에 보내고? 나는 이것보다 더 깊이 가야한다고 생각합니다.

ZyX가 #vim에서 말했듯이,이 질문은 "Vim 전문가들이 왜 따뜻한 것보다 맛있는 것을 선호합니까?" .

"Vim 전문가"는 탭보다 버퍼를 선호하지 않습니다. 버퍼를 파일 프록시로 사용하고 탭 페이지를 작업 영역으로 사용합니다. 버퍼와 탭 페이지는 서로 다른 목적을 가지므로 서로 선호하는 것은 의미가 없습니다.

버퍼와 탭의 문제 는 독립적 인 사실의 조합으로 인한 혼란 중 하나입니다 .

1. 대부분의 "현대"텍스트 편집기 및 IDE는 탭 은유를 사용하여 로드 된 파일을 나타냅니다. 이 은유는 정보 시스템의 역할을하며 사용자에게 열려있는 파일과 상태를 표시하고 대화 형 장치로서 사용자가 열린 파일을 조작 (재주문, 선택, 닫기 등) 할 수 있습니다. 많은 한계에도 불구하고 탭은 어디에나 있고 사람들은 그들에게 익숙 하며 어디에서나 기대 합니다.

2. Vim 은 사용자가 임시 "작업 공간"을 만들 수있는 방법으로 7.0의 탭 페이지 를 소개 했습니다. 기능, 특정 옵션, 특정 명령 또는 :help섹션에 탭 페이지를 파일 프록시로 사용할 수 있거나 사용할 것을 제안하는 것은 없습니다.

   물론 "탭 페이지" 의 이름 과 모양을 제외하고는 많은 혼란을 초래합니다.

3. :set hidden기본적으로 비활성화되어 있고 찾기가 쉽지 않은을 사용 하지 않으면 Vim은 현재 버퍼를 쓰거나 변경 사항을 포기하지 않고 다른 버퍼로 전환 할 수 없습니다. 이 옵션을 모르는 새로운 사용자는 무거운 창 사용 또는 탭 페이지와 같은 가장 가까운 "탭과 같은"기능으로 전환 할 수밖에 없습니다.

"탭 페이지"는 특히 문서를 읽는 것이 시간 낭비라는 아이디어가 지배하는 시대에 그 기능에 대한 불행한 이름 선택입니다.

Vim에서 탭 페이지는 창 위에 구축 된 추상화이며 버퍼 자체 위에 구축 된 추상화입니다. 각각의 새로운 레벨은 유용한 기능을 추가하지만 작업 흐름을 제한합니다.

"버퍼 웨이"

버퍼 기반 워크 플로를 사용하면 작업중인 파일이 단일 차원을 따라 배포됩니다. 당신은 당신의 버퍼를 순환 할 수 있습니다, 당신은 그것의 이름의 일부 (완료) 또는 숫자를 입력하여 특정 버퍼에 액세스 할 수 있습니다, 당신은 버퍼 사이를 번갈아 할 수 있습니다, 당신은 매우 쉽게 대상을 지정할 수 있습니다. 기본적으로 마찰이 없습니다.

1. 8 개의 버퍼가 열리고 하나만 표시됩니다.

   

2. 번호로 전환 :

   

3. 이름으로 전환 :

   

버퍼는 Vim의 파일 프록시입니다. 파일 측면에서 생각하면 버퍼 측면에서 생각합니다.

"창문 방법"

당신은 단지 버퍼를 사용하면 윈도우 기반의 워크 플로우와 함께, 귀하의 "파일은"모두가 마찬가지로 동일한 단일 "가상"차원을 따라 분포 하고 다른 두 "실제"차원에서. 그러나 이러한 차원이있는 데카르트 공간은 거의 완전히 분리되어 있습니다. 다른 버퍼로 이동하는 것은 여전히 ​​"다른 파일로 이동"을 의미하지만 다른 창으로 이동하는 것은 아닙니다. 원하는 파일에 해당하는 버퍼가 해당 창에 표시 될 수 있지만 다른 탭 페이지 또는 다른 탭 페이지에 표시되거나 전혀 표시되지 않을 수도 있습니다.

Windows에서는 열린 파일 간 탐색이 및로도 너무 복잡하거나 단순 'switchbuf'해 :sb집니다. 대부분 기본적으로 동일한 것에 대해 두 가지 명령 세트를 사용해야하기 때문에 버퍼에 액세스해야합니다.

아래 설명과 같이 Windows를 사용하지만 다른 사람의 워크 플로에서 버퍼를 대체하는 데 필요한 것은 없습니다.

여기에 Vim colorscheme을 작업 중입니다. 두 개의 창은 동일한 버퍼의 다른 뷰입니다. 상단은 색상 표에 사용 된 색상 코드 표와 함께 참조로 사용되며 하단은 내가 작업하는 곳입니다.

Windows는 파일 프록시로 설계되지 않았으며 파일 프록시로 만들 수 없습니다. "컨테이너"또는 "뷰포트"는 버퍼로보기를 제공하도록 설계되었습니다. 그 이상도 이하도 아닌.

"탭 방식"

탭 기반 워크 플로를 사용하면 기본적으로 Vim의 탭 페이지의 특성을 완전히 무시하면서 이전 편집기에서 익숙했던 사용자 경험을 모방하려고합니다. 이 전략이 일반적으로 매우 생산적이지 않다는 사실을 잊어 버린 경우 Windows와 마찬가지로 Vim 이 많은 유연성 을 잃지 않으면 서 "하나의 파일 = 하나의 탭"패러다임을 고수하는 것도 불가능 합니다.

여전히 위와 동일한 파일을 사용하여 작업 한 결과 표선은 실질적인 이점이없는 상당한 공간을 차지합니다. 내 모든 파일과 모든 탭이 호출 javascript*.vim되어 3gt올바른 위치에있게되고 이름으로 특정 탭에 도달하는 것은 불가능하고 확신 할 수 없습니다 . 또한 레이블이 매우 유용하지만 완벽하게 논리적 일 수 있다는 사실에 덧붙여서 [Quickfix List]... 파일 / 버퍼를 탭 페이지에 묶는 실질적인 방법이 없기 때문에 기본적으로 탭 페이지 사이를 탐색하는 실용적인 방법은 하나뿐입니다. / buffers / files : 사이클링.

그리고 예, 내 탭은 8 개의 탭으로 가득 차 있습니다 .20이 있는지 상상해보십시오!

1. 8 개의 탭 페이지에서 8 개의 버퍼가 열립니다 (잘못된)

   

2. 두 가지 특정 작업을위한 두 개의 탭 (오른쪽)

   

탭 페이지는 하나 이상의 창을 포함하도록 설계된 "컨테이너"또는 "뷰포트"이며 버퍼 자체를 포함하도록 설계된 "컨테이너"입니다.

결론적으로

"Vim 전문가"(내가 하나 인 것처럼 말할 수 있다고 가정하자) 는 탭보다 버퍼를 선호하지 않습니다. Vim은 설계된대로 디자인되어 있고 그 디자인에 완벽하게 익숙합니다.

• "Vim 전문가"에는 2, 30 또는 97 개의 버퍼가로드되어 있으며 공간 분포를 처리 할 필요가없는 것에 매우 만족합니다.

• 두 파일을 비교하거나 현재 버퍼의 한 부분에서 작업하면서 다른 버퍼를 참조로 유지해야하는 경우 "Vim 전문가"는 창을 사용합니다.

• 현재 시각을 그대로 유지하면서 프로젝트의 다른 부분에서 잠시 작업해야하는 경우 "Vim 전문가"는 새로운 탭 페이지를로드합니다.

나는 별도의 탭의 모든 버퍼를 유지하는 데 사용하지만, 나는 끊임없이 피곤 성장 gt및 gT주위 사방 -ing.

또한 버퍼를 관리하기가 너무 어렵다고 생각했습니다.

이전 의견을 완전히 바꿔 놓은 몇 가지 기술은 다음과 같습니다.

• 버퍼 관리 : :b. 당신은 이것에 놀라 울 정도로 빠릅니다. 바닐라 Vim을 사용하여 파일 간을 빠르게 전환하는 vim 참조 (플러그인 없음)
• 점프 / 변경 목록 ( ctrl o/ i및 g;)
• 대체 파일 ( ^)
• tpope 의 Unimpaired 플러그인 . 버퍼를 통해 비행하기위한 편리한 매핑.

일반적인 워크 플로는 다음과 같습니다.

• Vim을 열고 :e(보통 정규 표현식과 함께 :e src/**/F*Bar.js) 버퍼를 여는 데 사용하십시오.
• 다른 파일을 열어야합니다. 그것도 사용하십시오 :e. 이 버퍼와 현재 열려있는 버퍼 사이를 전환하려면 별도의 창에서 사용 :sp하거나 :vsp열 것입니다.
• 위의 글 머리 기호 목록의 기술을 사용하여 버퍼 사이를 전환하는 3-5 파일을 얻을 때까지 반복하십시오.
• 버퍼로 "다시 시작"하려면 Vim을 닫고 다시여십시오.

일주일 정도 지나면 이러한 새로운 패턴을 강요 한 후, 어떤 버퍼를 열 었는지, 몇 번의 자동 스트로크만으로 버퍼 중 하나에 도달하는 방법을 시각화하는 것이 훨씬 쉬워 졌다고 생각했습니다.

탭의 단점은 한 번에 하나의 내용 만 볼 수 있다는 것입니다. 따라서 브라우저에서와 같이 사용하면 여러 버퍼를 나란히 보거나 동일한 파일의 개별 부분을 분할하여 볼 때 손실됩니다. 따라서 많은 작업 공간을 분리 할 때만 탭을 사용하는 것이 좋습니다 (예 : Java 프로젝트 용 작업 목록, 할 일 목록 용 작업 목록, 측면 스크립트에서 세 번째로 해킹하는 작업).

설명하는 문제로 인해 Vim을 잘못 사용하고있는 것 같습니다. (대부분) 단일 전용 인스턴스가 있습니다. 그런 다음 숨겨지는 버퍼는 다시 편집하면 버퍼가 다시 나타납니다 (이제 버퍼 목록을 사용하여 호출 할 수 있음). 그러면 스왑 파일 메시지가 없습니다. 또는 프로젝트 / 파일 / 편집 세션마다 별도의 Vim 인스턴스를 사용하지만 :quit파일 작업이 끝나면 각 인스턴스 를 완전히 습관화 하십시오.

또 다른 팁은 버퍼 이름을 : buffer의 인수로 사용할 때 전체 이름을 지정할 필요가 없습니다. 그러나 둘 이상의 버퍼가 주어진 인수와 일치하면 버퍼가 전환되지 않습니다.

버퍼 이름의 모든 조각을 일치시키는 데 사용할 수 있습니다. 당신은 버퍼가있는 경우 예를 들어, request_manager.java및 queue_manager.java다음 :buffer que또는 :b que둘 다 일치하지만 queue_manager.java로 전환됩니다 그것은 처음에 일치한다.

워크 플로에서 탭, Ctrl- P및 Vim 세션을 사용하고 있으며 1 년이 넘습니다.

• 나는 한 )과 (각각 "이전 탭으로 이동" "다음 탭으로 이동"과 매핑. tn새 탭을 엽니 다. 또한 일을 체계적으로 유지하는 데 도움이되는 탭을 사용합니다.

• 나는 현재 작업중 인 스토리 / 버그와 관련된 파일 그룹에 대해 Vim 세션을 사용합니다. 일반적으로 범주별로 수행됩니다. 프로세스 중에이 세션을 덮어 씁니다.

• 아직 Ctrl- 보다 나은 것을 찾지는 못했지만 찾기 P위해 모든 파일을 처리하는 데 약간의 시간이 걸립니다.

더미에 2c를 던져 넣습니다.

TLDR; :b *part-of-filename*버퍼 목록에서 필요한 파일을 찾는 가장 좋은 방법입니다. 즉, 파일이 더 빠르며 버퍼 번호, 탭 또는 파일 추적 창보다인지 부하가 ​​적습니다.

버퍼를 30 개 열어 두는 것은 아무것도 아닙니다 (즉, 하우스 키핑을하지 않았 음). 버퍼 사용의 장점은 전혀 속도를 늦추지 않는다는 것입니다. 사실, 필요한 파일을 연 후 4 일이 지나면 전화를 걸고 :b *part-of-filename*마술처럼 나타나 동료와 토미 수집가 모두에게 깊은 인상을 남깁니다.

버퍼는 파일 용입니다.

효과적이려면 :

• 엄청나게 선택된 루트 디렉토리에서 중요한 첫 번째 파일을여십시오
• 다음으로 파일 열기 :e
• 사용하다 ls좋은 정신 모델을 처음 시작할 때 항상 하십시오 (정신적으로나 문자 적으로 볼 수없는 것을 파악할 수는 없습니다)
• 절대 :q불면
• 입력 :b근육 메모리에
• :b1 처음 열었던 파일에 적합합니다. 그렇지 않으면 숫자와 문자가 서투르게됩니다.
• :b# 마지막 파일로 전환하기에 좋습니다.
• :bd#임시 파일로 전환하고 필요한 작업을 수행하고으로 다시 전환 :b#한 다음 임시 파일을 닫고 싶을 때 유용 합니다.
• :b *part-of-filename* 그렇지 않으면 목록에서 필요한 파일을 찾는 가장 좋은 방법입니다. 즉, 파일이 더 빠르며 파일을 추적하기위한 버퍼 번호, 탭 또는 창보다 부하가 적습니다.

유일한 성가심은 :b *part-of-filename*때로는 파일을 아직 열지 않았으므로 :e path/to/full-filename먼저 돌아 가야한다는 것 입니다.

탭은 실제로 관련이없는 파일을 구별하기위한 것입니다.

또는 특정 창 레이아웃을 편리하게 유지하십시오 (면책 조항 : 나는 이것을 직접 사용하지 않았습니다).

또는 파일이 거의 사용되지 않지만 예상대로 필요합니다. 나를 위해, 그것은 일반적 commitMessage으로 내가 일할 때 주석을 달아 주는 파일이므로 커밋을 할 때 너무 많은 생각을 할 필요가 없습니다. (운이 좋으면 그렇지 않으면 ) gt보다 빠릅니다.:b com<enter>:b com<tab><enter>

• :tabe commitMessage
• gt또는 gT근육 기억 좋아하는

창 분할은 정보를 시각적으로 비교하기위한 것입니다

또는 중요한 정보에 즉시 액세스 할 수 있습니다 (진실로, 정보가 어떻게 든 :e로그 파일 로 실시간 업데이트 해야하는 것이 아니라면 일반적으로 내용을 현재 파일로 가져 와서 처리합니다).

• :vsp또는 C-w v수직 분할을 엽니 다. 즉 왼쪽 | 그런 다음 :b또는 :e을 사용 하여 원하는 파일을 가져옵니다.
• :sp또는 C-w s수평 분할을 엽니 다. 즉 위 / 아래
• C-w C-w 즉, 더블 Ctrl-w, 사용 가능한 창을 중심으로 회전
• C-w c 현재 창 닫기
• C-w o 다른 모든 창을 닫고 전류 만 유지

이것들을 추가 .vimrc하고 사랑스러운 버퍼를 시작 하십시오 .

:nnoremap <Tab> :n<cr>
:nnoremap <S-Tab> :N<cr>

당신은 앞으로주기 할 수있는 그런 식으로 /에서 그들을 통해 이전 버전과 일반 모드 를 통해 Tab/ ShiftTab.

몇 년 전에 kien / tabman.vim 과 같은 구현을 제안하고 싶습니다 . 다음을 명확하게합니다.

• 어딘가에 조심스럽게 숨겨져있는 많은 버퍼를 가질 수 있습니다.
• 의도적으로 탭은 독창적 인 방식으로 버퍼를 표시하기위한 것입니다.
  • 적절한 tabline 플러그인을 사용하면 모든 숨겨진 버퍼를 맨 윗줄 (tabline)에 표시 할 수 있습니다.
  • vim-airline을 사용한 경험에 따라 새 탭을 만들 때 탭 라인에 관련 정보가 거의 표시되지 않습니다.
  • 두 개의 태그가 테이블 라인 슬롯을 나란히 차지하고 나머지 수평 공간을 낭비합니다.
  • 최악의 경우, 더 이상 숨겨진 버퍼가 무엇인지 전혀 알지 못합니다.

이 마법 플러그인은 재발견되어 왔으며, Vim 구성을 오랫동안 유지해 왔습니다. 숨겨진 버퍼를 모두 표시하는 것을 계속 찾고 있지만 TabMan은 버퍼가 다른 탭에 어떻게 배열되어 있는지에 대한 조감도입니다.

Vi에서 탭과 버퍼는 서로 다른 두 가지 표준입니다. 이 세 가지 정의를 읽으십시오.

A buffer is the in-memory text of a file
A window is a viewport on a buffer.
A tab page is a collection of windows.

자세한 내용은이 기사를 읽으십시오 https://joshldavis.com/2014/04/05/vim-tab-madness-buffers-vs-tabs/

"선택한"버퍼를 탭으로로드하여 탭간에 빠르게 (TAB / S-TAB) 전환 할 수 있습니다. 작업 공간의 프레임 워크는 여기에 맞습니다. 버퍼 VS 탭은 대부분 가시성입니다. 중요한 파일이나 작업 파일을 창과 탭에 표시하고 경로를 기억하거나 필요에 따라 검색하고 다시로드하는 데 시간을 소비하지 않고 현재 백그라운드에서 활용할 필요가없는 파일을 숨길 수 있습니다. 이를 통해 하나의 VIM 세션에서 여러 작업 또는 프로젝트를 처리 할 수 ​​있습니다. 메모리 부족 시스템에서는 이것이 중요했지만 모든 편집 작업을 하나의 응용 프로그램 프레임에 집중시키는 데에도 도움이됩니다. 또한 버퍼 이동 단축키가로 설정되어 있습니다.Ctrl -Right / Left로 있으므로 다양한 버퍼를 빠르게 이동할 수 있습니다.

결론적으로, 화면 영역만큼 많은 용도로 일부 창으로 분할 할 수 있지만 여러 탭에서 여러 창 설정을 유지할 수 있으므로 작업 영역이 확장되고 워크 플로우가 향상되어 하나 이상의 파일을 회전시키는 복잡한 작업을 편리하게 분할 할 수 있습니다 .

스왑 파일의 경우 VIM에 모든 파일을 지정한 한 폴더에 보관하도록 지시 할 수 있습니다. 이를 위해 :set directory.