Por que os especialistas em Vim preferem buffers em vez de guias?

Eu não entendo buffers. Quando abro 3 arquivos na mesma aba e fecho minha janela, geralmente fico aborrecido ao descobrir na próxima vez que abro um desses arquivos que existem arquivos de troca estranhos persistentes e que me transmitem mensagens incômodas. Mas, repetidamente, li que essas coisas são o nirvana da produtividade que estou perdendo e que foram feitas guias para os plebeus usarem.

Por isso, pergunto a você, especialista em Vim: quais são as vantagens de usar buffers sobre guias? Não vejo como a diferença possa ser profundamente diferente, mas me consideraria apenas no nível iniciante-intermediário na operação do Vim. É :ls :b#realmente muito mais rápido do que isso gt? Eu sinto que deve ser mais profundo do que isso.

Como o ZyX disse no #vim, essa pergunta soa como "Por que os especialistas em Vim preferem saboroso do que quente?".

Os "especialistas em Vim" não preferem buffers em vez de guias: eles usam buffers como os proxies de arquivos e as guias como os espaços de trabalho. Buffers e guias têm propósitos diferentes, portanto, preferir um ao outro não faz sentido algum.

O problema com buffers e guias é de confusão , causado por uma combinação de fatos independentes.

1. A maioria dos editores de texto e IDEs "modernos" usa uma metáfora de tabulação para representar arquivos carregados. Essa metáfora atua como um sistema de informação - mostra ao usuário quais arquivos são abertos e seu estado - e como um dispositivo interativo - permite ao usuário manipular (reordenar, selecionar, fechar ...) esses arquivos abertos. Apesar de suas muitas limitações, as guias estão em todos os lugares e as pessoas estão acostumadas a elas e as esperam em todos os lugares.

2. O Vim introduziu as guias na 7.0 como uma maneira de seus usuários criarem "espaços de trabalho" ad-hoc. Nada em seus recursos, opções específicas, comandos específicos ou :helpseções sugere que as guias possam ou devam ser usadas como proxies de arquivo.

   Nada, exceto o nome e a aparência das "guias", é claro, o que leva a muita confusão.

3. Sem :set hidden, que é desativado por padrão e não é muito fácil de encontrar, o Vim torna impossível mudar para outro buffer sem gravar o atual ou abandonar suas alterações. Os novos usuários, que desconhecem essa opção, não têm escolha a não ser recorrer ao uso intenso de janelas ou ao recurso "semelhante a guia" mais próximo que podem encontrar: guias.

"Página de guia" é uma escolha infeliz de nome para esse recurso, especialmente em uma época dominada pela idéia de que ler a documentação é uma perda de tempo.

No Vim, as guias são uma abstração criada em cima de janelas, elas mesmas uma abstração criada em cima de buffers. Cada novo nível adiciona recursos úteis, mas restringe seu fluxo de trabalho.

O "caminho do buffer"

Com um fluxo de trabalho baseado em buffer, os arquivos com os quais você está trabalhando são distribuídos em uma única dimensão. Você pode percorrer seus buffers, acessar um buffer específico digitando parte de seu nome (com conclusão) ou seu número, alternar entre buffers, segmentá-los facilmente. Basicamente, não há atrito.

1. Oito buffers abertos, apenas um visível:

   

2. Mudando por número:

   

3. Mudando por nome:

   

Buffers são proxies de arquivo do Vim. Se você pensa em termos de arquivos, pensa em termos de buffers.

O "caminho da janela"

Com um fluxo de trabalho baseado em janela, seus "arquivos" são distribuídos ao longo da mesma dimensão "virtual" única como seriam se você usasse apenas buffers e ao longo de duas outras dimensões "físicas". Mas os espaços cartesianos nos quais essas dimensões são encontradas são quase completamente separados: mover para outro buffer ainda significa "mover para outro arquivo", mas mover para outra janela não. O buffer que corresponde ao arquivo desejado pode ser exibido nessa janela, mas também pode ser exibido em outro, talvez em outra página da guia, ou de modo algum.

Com o Windows, a navegação entre arquivos abertos se torna muito complexa ou simplista, mesmo com 'switchbuf'e :sb. Principalmente porque você é forçado a usar dois conjuntos de comandos para o que é essencialmente a mesma coisa: acessar um buffer.

O Windows tem seu uso, conforme descrito abaixo, mas eles não têm o necessário para substituir os buffers no fluxo de trabalho de ninguém.

Aqui estou trabalhando em um esquema de cores Vim. As duas janelas têm visões diferentes do mesmo buffer: a superior serve como referência, com uma tabela dos códigos de cores usados ​​no esquema de cores, e a inferior é onde trabalho:

O Windows não é projetado como proxies de arquivo e não pode ser transformado em um: são "contêineres" ou "viewports" projetados para oferecer uma visualização em um buffer. Nem mais nem menos.

O "caminho da guia"

Com um fluxo de trabalho baseado em guias, você basicamente tenta imitar a experiência do usuário com a qual está acostumado em seu editor anterior, ignorando completamente a própria natureza das páginas de guias do Vim. Se esquecermos por um momento que essa estratégia geralmente é muito improdutiva, também é impossível, assim como no Windows, forçar o Vim a aderir ao paradigma "um arquivo = uma guia" sem perder muita flexibilidade.

Ainda trabalhando com os mesmos arquivos acima, a tabline ocupa um espaço significativo para praticamente nenhum benefício. Todos os meus arquivos e todas as minhas guias são chamados, javascript*.vimentão não posso fazer isso 3gte ter certeza de que acabarei no lugar certo e é impossível alcançar uma guia específica por nome. Acrescente a isso o fato de que seu rótulo pode muito bem ser inútil, mas perfeitamente lógico [Quickfix List]… Como não há uma maneira prática de vincular um arquivo / buffer a uma página de guia, você basicamente tem apenas uma maneira prática de navegar entre as páginas de guia. / buffers / arquivos: ciclismo.

E sim, minha tabline está cheia de apenas 8 tabs, imagine se eu tivesse 20!

1. Oito buffers abertos em oito guias (incorretas)

   

2. Duas guias para duas tarefas específicas (direita)

   

As páginas da guia são "contêineres" ou "viewports" projetadas para conter uma ou mais janelas; elas também são "contêineres" projetadas para conter buffers.

Em conclusão

Os "especialistas em Vim" (suponha que eu possa falar como se eu fosse um) não preferem buffers em vez de abas: eles apenas usam o Vim como ele foi projetado e estão perfeitamente confortáveis ​​com esse design:

• Os "especialistas em Vim" têm 2, 30 ou 97 buffers carregados e estão muito felizes por não terem de lidar com a distribuição espacial;

• quando eles precisam comparar dois arquivos ou trabalhar em uma parte do buffer atual, mantendo outra como referência, os "especialistas em Vim" usam o Windows porque é assim que eles devem ser usados;

• quando eles precisam trabalhar por um tempo em uma parte separada do projeto sem mexer com a visualização atual, os "especialistas em Vim" carregam uma nova página de guia.

Eu costumava manter cada tampão em uma aba separada, mas eu cresci cansado de constantemente gte gTing ao redor em toda parte.

Eu também senti que os buffers eram muito difíceis de gerenciar.

Aqui estão algumas técnicas que mudaram totalmente minha opinião anterior:

• Gerenciamento de buffer: :b . Você é surpreendentemente rápido nisso. Veja o vim, alternando entre arquivos rapidamente usando o vanilla Vim (sem plugins)
• Saltar / alterar listas (ctrl o / ie g;)
• Arquivo alternativo ( ^)
• Plugin impecável do tpope . Mapeamentos convenientes para voar através de seus buffers (entre outros).

Aqui está o meu fluxo de trabalho típico:

• Abra o Vim e use :e(geralmente com um regex como :e src/**/F*Bar.js) para abrir um buffer
• Percebo que preciso abrir outro arquivo. Usar:e para isso também. Se eu quiser alternar entre esse buffer e o buffer aberto no momento, usarei :spou :vsppara abri-lo em uma janela separada.
• Repita até que eu tenha os 3 a 5 arquivos que alternarei entre as técnicas da lista com marcadores acima para voar entre os buffers.
• Se eu quiser "começar de novo" com meus buffers, feche o Vim e abra novamente.

Senti que, depois de mais ou menos uma semana forçando esses novos padrões, ficou muito mais fácil visualizar quais buffers eu tinha aberto e como chegar a qualquer um deles com apenas alguns golpes automáticos.

A desvantagem das guias é que você só pode ver o conteúdo de uma por vez. Portanto, se você usá-los como em um navegador, estará perdendo a visualização de vários buffers lado a lado ou até a visualização de partes separadas do mesmo arquivo em divisões. Portanto, muitos recomendam usar guias apenas para segregar áreas de trabalho diferentes (por exemplo, uma para um projeto Java, outra para uma lista de tarefas, uma terceira para invadir um script ao lado).

Os problemas que você descreve fazem parecer que você está usando o Vim errado. Ou (principalmente) uma instância única e dedicada. Em seguida, os buffers que ficarem ocultos simplesmente "reaparecerão" se você os editar novamente (e agora você pode usar a lista de buffers para recuperá-los) e não haverá mensagens de arquivo de troca. Ou use instâncias separadas do Vim por projeto / arquivo / sessão de edição, mas, em seguida, crie o hábito de executar totalmente :quitcada instância quando terminar o arquivo.

Outra dica, ao usar o nome do buffer como argumento para: buffer, você não precisa especificar nomes inteiros. No entanto, se mais de um buffer corresponder ao argumento fornecido, os buffers não serão alternados.

Qualquer fragmento do nome do buffer pode ser usado para corresponder. Por exemplo, se você tiver os buffers request_manager.javae, em queue_manager.javaseguida, :buffer queou :b quecorresponder a ambos, mas alternará para queue_manager.java, conforme corresponder no início.

Eu uso as guias Ctrl- Pe as sessões do Vim no meu fluxo de trabalho e já há mais de um ano:

• Eu mapei )e (mapeei para "ir para a próxima guia" e "ir para a guia anterior", respectivamente. tnabre uma nova guia. Também uso o tabm para ajudar a manter as coisas organizadas.

• Uso sessões do Vim para grupos de arquivos relacionados à história / bug atual em que estou trabalhando, geralmente feito por categoria. Essas sessões são substituídas durante o curso do processo.

• Ainda não encontrei nada melhor que Ctrl- P, mas é preciso um pouco para processar todos os arquivos para encontrá-lo.

Joga 2c na pilha.

TLDR; :b *part-of-filename*é a melhor maneira de encontrar um arquivo que você precisa na lista de buffers, ou seja, é MAIS RÁPIDO e tem menos carga cognitiva que os números, guias ou janelas do buffer para rastrear arquivos.

Não é nada para mim ter 30 buffers abertos (ou seja, eu não tenho arrumação doméstica), e a beleza dos buffers usados ​​- bem, é que isso não me deixa mais lento. Na verdade, ele acelera as coisas quando quatro dias depois que eu abri o arquivo eu preciso, ligue:b *part-of-filename* e ele aparece magicamente, impressionando colegas de trabalho e colecionadores.

Buffers são para arquivos.

Para ser efetivo:

• Abra um primeiro arquivo importante a partir de um diretório raiz diabolicamente bem escolhido
• Abra arquivos subsequentes com :e
• Usar ls TODO o tempo em que começar a obter um bom modelo mental (você não pode grocar o que não pode ver, mental ou literalmente)
• Nunca :qsopra
• Entre :bna sua memória muscular
• :b1 é bom para o primeiro arquivo que você sabe que abriu, caso contrário, números e letras ficam desajeitados rapidamente
• :b# é bom para mudar para o seu último arquivo, o que é uma necessidade comum
• :bd#é bom para quando você alterna para um arquivo temporário, faz o que você precisa fazer, retorna :b#e agora deseja fechar esse arquivo temporário
• :b *part-of-filename* caso contrário, é a melhor maneira de encontrar um arquivo que você precisa na lista, ou seja, é MAIS RÁPIDO e tem menos carga cognitiva do que números de buffer, guias ou janelas para rastrear arquivos.

O único incômodo :b *part-of-filename*é que às vezes você ainda não abriu o arquivo e precisa voltar e:e path/to/full-filename primeiro.

As guias são para diferenciar arquivos realmente não relacionados.

Ou mantendo um layout de janelas específico à mão (isenção de responsabilidade: eu nunca o usei para isso).

Ou para arquivos raramente usados, mas previsivelmente necessários. Para mim, geralmente é um commitMessagearquivo que eu anoto enquanto trabalho, para que eu não precise pensar muito na hora de confirmar. gté mais rápido que :b com<enter>(se você estiver com sorte, caso contrário :b com<tab><enter>)

• :tabe commitMessage
• gtou gTtambém um favorito da memória muscular

As divisões de janela são para comparar visualmente informações

Ou ter acesso imediato a informações importantes (sinceramente, a menos que essas informações sejam algo que eu precise atualizar com :eum arquivo de log, geralmente eu apenas puxo o conteúdo para o arquivo atual e lido com ele).

• :vspou C-w vabre uma divisão vertical, ou seja, esquerda | certo, use :bou :epara obter o arquivo que deseja
• :spou C-w sabra uma divisão horizontal, isto é, superior / inferior
• C-w C-w ou seja, duplo Ctrl-w, gira você pelas janelas disponíveis
• C-w c fechar janela atual
• C-w o feche todas as outras janelas, mantenha SOMENTE atualizado

Adicione-os ao seu .vimrce comece a amar buffers:

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

Dessa forma, você pode avançar / retroceder através deles no modo normal via Tab/ ShiftTab.

Gostaria de sugerir uma implementação brilhante de um bom número de anos atrás: kien / tabman.vim . Esclarece o seguinte:

• Pode-se ter tantos buffers cuidadosamente escondidos em algum lugar;
• Por design, as guias são destinadas a exibir bufferes de maneira criativa.
  • Com algum plugin de tabline adequado, é possível exibir todos os buffers ocultos na linha superior (tabline);
  • De acordo com minha experiência com a vim- airlines, a tabline mostrará muito poucas informações relevantes quando eu criar uma nova guia.
  • Duas tags ocuparão o espaço da tabline, lado a lado, desperdiçando o restante dos espaços horizontais
  • Pior ainda, não tenho mais idéia de quais são os buffers ocultos.

Foi uma redescoberta maravilhosa deste plugin mágico, que deveria ter permanecido na minha configuração do Vim por um bom número de anos também. Embora eu continue procurando por algo que também exiba todos os buffers ocultos, o TabMan é o meu super-homem quando se trata de ter uma visão geral de como os buffers foram organizados em diferentes guias.

Guias e buffers são dois padrões diferentes no Vi. Leia estas três definições:

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.

Leia este artigo para mais https://joshldavis.com/2014/04/05/vim-tab-madness-buffers-vs-tabs/

Carrego os buffers "selecionados" como guias para alternar rapidamente (TAB / S-TAB) entre eles. A estrutura dos espaços de trabalho se encaixa aqui, pois para mim, os buffers das guias VS são principalmente a visibilidade. Posso abrir arquivos importantes / de trabalho em janelas e guias e ocultar os que atualmente não preciso utilizar em segundo plano em tempo real, sem ter que lembrar de caminhos ou ter tempo para pesquisar e carregá-los novamente quando necessário. Isso permite lidar com várias tarefas ou projetos em uma sessão do VIM, acho que isso costumava ser importante em máquinas com pouca memória, mas também é bom para concentrar todas as tarefas de edição em um único quadro de aplicativo. Também tenho atalhos de deslocamento de buffer definidos como Ctrl-Direita / Esquerda, para que eu possa alternar rapidamente também entre vários buffers.

Resumindo, é possível dividir até algumas janelas para seus usos tanto quanto a propriedade da tela, mas é possível manter várias configurações de janelas em várias guias, expandindo assim o espaço de trabalho e melhorando o fluxo de trabalho, permitindo a divisão conveniente de tarefas complicadas, revolvendo mais de um arquivo .

Para os arquivos de troca, você pode dizer ao VIM para manter todos eles em uma pasta da sua designação. Para este uso :set directory.