Quando exatamente <arquivo> difere de <amatch>?

A documentação diz:

<afile>    When executing autocommands, is replaced with the file name
           for a file read or write.
<abuf>     When executing autocommands, is replaced with the currently
           effective buffer number (for ":r file" and ":so file" it is
           the current buffer, the file being read/sourced is not in a
           buffer).
<amatch>   When executing autocommands, is replaced with the match for
           which this autocommand was executed.  It differs from
           <afile> only when the file name isn't used to match with
           (for FileType, Syntax and SpellFileMissing events).

No entanto, se eu tivesse isso autocmd:

autocmd BufNewFile * echo expand('<amatch>') expand('<afile>')

E aberto, digamos .zshrcem /tmp( cd /tmp; vim .zshrc), recebo:

/tmp/.zshrc .zshrc

Eles não são os mesmos. O que está acontecendo?

%é fiel ao que eu realmente digitei. vim ./.zshrccom expand('%')adicionado ao acima autocmdme dá:

/tmp/.zshrc .zshrc ./.zshrc

autocmd

— muru
fonte

Você acha que a diferença pode ser <afile>apenas o nome do arquivo <amatch>e o caminho completo para o arquivo?

— nobe4

@ Nobe4 sim, é sempre assim que acontece. %, no entanto, é fiel ao que eu realmente mencionei. Mas não tenho certeza se posso confiar %aqui. : /

— muru

Se você digitar, vim /tmp/.zshrcelas são as mesmas strings. Se seu cwd for, /tmpvocê obterá um caminho absoluto e um caminho relativo e, embora não sejam as mesmas seqüências de caracteres, eles são os mesmos caminhos.

— Martin Tournoij 26/08/2015

@Carpetsmoker eu digitei simplesmentevim .zshrc

— #

Na expansão, você pode ter: expand('<amatch>') == expand('%:p')e expand('<afile>') == expand('%'). O que você acha ? Edit: Acabei de ver sua edição, a expand('<afile>') == expand('%')não se aplica mais

— nobe4 26/08/2015

<amatch>é exatamente o que corresponde ao autocmdpadrão. Para autocmds que correspondem aos nomes de arquivos, os links simbólicos são resolvidos, o resultado é canônico e o caminho completo é retornado.

<afile>é o caminho completo canônico como acima, mas o resultado também é reduzido, que é essencialmente o mesmo que fnamemodify(file, ':.')(os detalhes exatos estão mais envolvidos, mas a descrição anterior é precisa para todos os casos "normais").

Assim, em geral expand('<afile>') == expand('<amatch>:.')( editar: desde que, naturalmente, eles se refiram à mesma coisa).

— Sato Katsura
fonte

Esse parece ser o comportamento, sim. Mas você tem alguma coisa para apoiar esta resposta?

— muru

@muru: Você quer dizer, além da minha boa aparência e do meu sorriso perfeito? ;) Sim, acho que sim: fontes <arquivo> e <amatch> .

— Sato Katsura

Em geral, afile não é o mesmo quemat, pois pode ser bem diferente dependendo do evento de comando automático.

— Christian Brabandt

@ChristianBrabandt Sim. O ponto da questão é, eles podem ainda ser diferentes para autocmds onde <afile>e <amatch> que se referem à mesma coisa (ou seja, para um arquivo), ao contrário do que o manual implica. Minha resposta explica como e por que eles diferem nesse caso específico. Melhor agora? :)

— Sato Katsura