Editor externo

Um cliente Git é onde você lê código; raramente é onde você o conserta. A distância entre notar um problema num diff e ter o cursor naquela linha no seu editor é uma busca de arquivo e uma rolagem — toda vez.

Aponte o Gitcito para o seu editor uma vez e essa distância some: clique com o botão direito numa linha na visão de arquivo ou de blame e ela abre lá, naquela linha.

Escolhendo um

Configurações → Geral → Editor externo. O dropdown lista os editores que o Gitcito consegue encontrar nesta máquina — ele procura primeiro pelo comando de cada editor e depois, no macOS, pelo bundle da aplicação em /Applications e ~/Applications. A varredura roda toda vez que você abre as Configurações, então um editor instalado cinco minutos atrás aparece sem precisar reiniciar.

Reconhecidos de fábrica:

O limite que vale conhecer

Pular para uma linha precisa do comando do editor, não do ícone dele. Um bundle .app do macOS é lançado através do open, que aceita um caminho e mais nada — então um editor encontrado só como bundle abre o arquivo no topo, e o Gitcito diz isso embaixo do dropdown em vez de fingir o contrário.

O conserto é do lado do editor: o Shell Command: Install 'code' command in PATH do VS Code, o symlink subl do Sublime, o Toolbox → Settings → Shell scripts da JetBrains. Assim que o comando existir, escolha o editor de novo e o pulo para a linha funciona.

Onde as ações aparecem

As ações de linha só aparecem onde o número da linha ainda significa alguma coisa: um arquivo mostrado num commit antigo, ou um blame rebobinado para uma revisão anterior, tem linhas que não correspondem mais ao que está em disco, então o Gitcito não oferece pulo ali em vez de te mandar para o lugar errado.

Projetos do Xcode e outros pacotes

MyApp.xcodeproj é um diretório. O Git sabe disso, e a árvore de arquivos também sabia — até começar a atrapalhar: expandi-lo para achar project.pbxproj, project.xcworkspace e uma pasta por desenvolvedor dentro de xcuserdata são três cliques de ruído por algo que você nunca ia editar na mão.

Agora eles aparecem com um ícone de pacote e clicar na linha abre o pacote, como um duplo clique no Finder faria. A seta continua ali, então na única vez em que você precisa do project.pbxproj — um conflito de merge, quase sempre — você desce nele como antes.

Reconhecidos: .xcodeproj, .xcworkspace, .xcframework, .framework, .app, .appex, .dSYM, .playground, .xcuserdatad.

Não reconhecidos, de propósito: .xcassets e .lproj. Também são pacotes, mas as pessoas editam os arquivos lá dentro, então fechá-los custaria mais do que economiza.

Os limites

O pacote abre pelo sistema, não pelo seu editor. Um .xcodeproj entregue a um editor de texto abre como uma pasta de property lists, que não é o que quem clicou queria — então o Gitcito entrega ao que o sistema associa a ele, o que num Mac com Xcode instalado é o Xcode. Sua escolha de editor não muda; ela continua valendo para qualquer arquivo comum.

É uma convenção de nomes, não uma marca do sistema de arquivos. O Gitcito olha a extensão, então um diretório que você chamou de notes.app também fecha, e no Linux ou Windows — onde são pastas comuns — clicar abre o gerenciador de arquivos em vez de uma IDE.

Um comando seu

Escolha Comando personalizado para qualquer coisa fora da tabela — um script wrapper, um lançador de desenvolvimento remoto, um editor de terminal iniciado pelo seu próprio shim.

Os templates são divididos em espaços e cada token é substituído uma vez — um caminho com espaço continua sendo um argumento só, e nada é re-parseado depois, então um nome de arquivo nunca pode virar sintaxe. Quatro marcadores: {path}, {line}, {col}, {repo}.

Um marcador sem valor leva a flag dele junto: --line {line} {path} rodado sem linha vira apenas o caminho, nunca um --line solto que engoliria o nome do arquivo como argumento. Um template sem {line} simplesmente significa que o Gitcito não vai oferecer ações precisas por linha para aquele editor.

O que isto não é

Isto não é a configuração de "Abrir com" um app, que mostra o seletor do sistema e lembra um app para abrir qualquer coisa — uma imagem, um PDF, uma pasta no Finder. O editor é o mais específico dos dois, então onde os dois estão configurados o editor ganha no ícone de fim de linha da árvore de arquivos; os dois continuam listados no menu de botão direito.

O Gitcito nunca lança o seu editor sozinho, e fechar o Gitcito nunca o fecha: o editor é iniciado destacado, como um processo próprio.