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

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. 두 가지 특정 작업을위한 두 개의 탭 (오른쪽)

   

Tab pages are "containers" or "viewports" designed to contain one or more windows, themselves also "containers" designed to contain buffers.

In conclusion

"Vim experts" (let's assume I can speak as if I was one) don't prefer buffers over tabs: they just use Vim as it was designed and are perfectly comfortable with that design:

• "Vim experts" have 2, 30 or 97 buffers loaded and are very happy they don't have to deal with spatial distribution;

• when they need to compare two files or work in one part of the current buffer while keeping another as a reference, "Vim experts" use windows because that's how they are meant to be used;

• when they need to work for a while on a separate part of the project without messing with their current view, "Vim experts" load a brand new tab page.

---

I used to keep every buffer in a separate tab, but I grew tired of constantly gt and gT-ing around everywhere.

I also felt that buffers were too difficult to manage.

Here are some techniques that totally changed my earlier opinion:

• Buffer management: :b. You get surprisingly fast at this. See vim, switching between files rapidly using vanilla Vim (no plugins)
• Jump/Change lists (ctrl o/i and g;)
• Alternate file (^)
• tpope's Unimpaired plugin. Convenient mappings for flying through your buffers (among others).

Here is my typical workflow:

• Open Vim, and use :e (usually with a regex like :e src/**/F*Bar.js) to open a buffer
• Realize I need to open another file. Use :e for that as well. If I want to toggle between this buffer and the currently open buffer I will use :sp or :vsp to open it in a separate window.
• Repeat until I've got the 3-5 files that I will be switching between using the techniques in the above bulleted list to fly between your buffers.
• If I want to "start over" with my buffers, just close Vim and re-open.

I felt that after a week or so of forcing these new patterns, it became much easier to visualize which buffers I had open, and how to get to any one of them in only a few automatic strokes.

---

The downside of tabs is that you can only see the contents of one at a time. So if you use them like in a browser, you're losing out on viewing multiple buffers side by side, or even viewing separate parts of the same file in splits. Therefore, many recommend to use tabs only to segregate different workspaces (e.g. have one for a Java project, another for a todo list, a third to hack on a script on the side).

The problems you describe make it appear that you're using Vim wrong. Either have (mostly) a single, dedicated instance. Then, buffers that become hidden will simply "reappear" if you re-edit them (and you can now use the buffer list to recall them), and there won't be swap file messages. Or, use separate Vim instances per project / file / edit session, but then make it a habit to fully :quit each instance when you're done with the file.

---

Another tip, when using the buffer name as the argument to :buffer, you don't have to specify entire names. However, if more than one buffer matches the given argument, the buffers won't be switched.

Any fragment of the buffer name can be used to match. For example, if you have the buffers request_manager.java and queue_manager.java then :buffer que or :b que matches both of them, but will switch to queue_manager.java as it matches at the beginning.

---

I use tabs, Ctrl-P and Vim sessions in my workflow and have for over a year now:

• I have ) and ( mapped to "go to next tab" and "go to previous tab" respectively. tn opens a new tab. I also make use of tabm to help keep things organized.

• I use Vim sessions for groups of files relating to the current story/bug I'm working on, usually done by category. These sessions get overwritten during the course of the process.

• I have yet to find anything better than Ctrl-P, but it does take a bit to process all the files for finding.

---

Add these to your .vimrc and start loving buffers:

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

That way you can cycle forward/backward through them in normal mode via Tab/ShiftTab.

---

I load "selected" buffers as tabs to quickly (TAB/S-TAB) toggle between them. The framework of workspaces fits here as for me buffers VS tabs is mostly the visibility thing. I can pop important/work files in windows and tabs and hide the ones I don't currently need to utilize in the background on the fly without having to remember paths or take time to search and load them up again once the need arises. This allows for handling several tasks or projects in one VIM session, I guess this used to be important in low-memory machines but is also good for concentrating all editing tasks under one application frame. I also have buffer shifting shortcuts set to Ctrl-Right/Left so I can quickly shift through various buffers as well.

Bottom line, one can only split up to some windows for his uses as much as screen estate goes, but one can hold multiple windows settings in several tabs thus expanding one's workspace and improving workflow allowing the convenient division of complicated tasks revolving more than one file.

For the swap files, you can tell VIM to keep all of them in one folder of your designation. For this use :set directory.

---

I would like to suggest a brillent implementation from a good number of years ago: kien/tabman.vim. It clarifies the following:

• One can have as many buffers that are carefully hidden, somewhere;
• By design, tabs are meant to display bufferes in creative ways.
  • With some proper tabline plugin, one can display all the hidden buffers at the top row (tabline);
  • Per my experience with vim-airline, the tabline will show very few relevant information when I create a new tab.
  • Two tags will occupy the tabline slot, side by side, wasting the rest of the horizontal spaces
  • Worst still, I no longer have any idea of what are the buffers that are hidden.

It has been a wonderful rediscovery of this magic plugin, which should have been staying in my Vim configuration for a good number of years as well. While I would continue to look for some thing that also displays all the hidden buffers, TabMan is my superman when it comes to having a bird's eye view of how buffers were arranged across different tabs.

---

Tabs and Buffers are two different standards in Vi. Read these three definitions:

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/

참고 URL : https://stackoverflow.com/questions/26708822/why-do-vim-experts-prefer-buffers-over-tabs