Fish-shell: Abreviações

Outra ideia é nomear isso "abreviações" como no Vim, e então decidir o que fazer com os apelidos em outra edição [eu tendo a achar que eles deveriam ser removidos].

Pensei em outro argumento contra:

• Não é possível usar esses "apelidos" em scripts. Não tenho certeza se é uma boa ideia usar apelidos em scripts de qualquer maneira, mas poderíamos ter uma função para expandir "abreviações" e / ou poderíamos enganchar as abreviações de fish em editores para que elas expandissem a entrada lá também.

Gosto da sua proposta, parece legal e suspeita: +1:

Eu também gosto disso.
É uma solução muito limpa para o problema de "completações para aliases" # 393, o que é bastante irritante.
Isso combinado com uma impressão ll (Alias) ao fazer um ll<tab> seria perfeito.

Como alias é apenas um wrapper de script em torno de function hoje, eu gostaria que isso mudasse também para que haja uma diferença distinta entre funções e aliases, uma vez que eles diferem de muitas maneiras depois disso, ex :

• Sintaxe
• Expressibilidade
• Uso

@gustafj Acho que provavelmente é melhor chamar essa ideia de "abreviações" e substituir alias por algo que mostre uma mensagem de erro útil apontando para function e abbreviate . Pensamentos?

Outra nota:

Eu pretendia que isso afetasse apenas o comando em uma linha de comando, porque seria realmente irritante se g continuasse se expandindo para git na posição de argumento. No entanto, podemos querer alguma expansão nas posições dos argumentos também, por exemplo com sudo (o que significaria que você poderia usar sudo com abreviações - algo que você não pode fazer com aliases!) E certos casos de conclusões inequívocas, como quanto aos aliases do próprio git ou se você digitar parte de uma opção longa. No entanto, acertar pode ser complicado e só atrapalharia se as conclusões estivessem desatualizadas e se você realmente quisesse sudo g not sudo git agora você tem que fazer algo como sudo (echo git) . Talvez pudéssemos dizer que os argumentos citados nunca se expandem, então você poderia dizer sudo "g" . Não tenho certeza se isso seria muito mágico e surpreendente ou, na verdade, exatamente o que se poderia esperar e intuir. Pensamentos? :-)

Abreviações soam bem para mim (mas sou um usuário regular do vim, então posso ser tendencioso ...).
Quando penso nisso, há muitas coisas "interessantes" que podem ser feitas com isso, mas (como você já observou) existem armadilhas escondidas neste campo minado também: /

Eu acho que pode ser problemático / irritante se for completamente automático e em qualquer lugar na linha de comando, principalmente porque desfazer a abreviatura pode ser entediante se ela se expandir para algo que você não quer e particularmente se ela se expandir para uma longa string.

Algumas idéias minhas:
Deve ser automático usando space ou deve ser acionado por uma opção via tab ou outra coisa?
Deve ser apenas para strings simples ex g para git ?
Deve ser aplicável apenas para o primeiro item da linha de comando ou em qualquer lugar?
Deve ser possível fazer string -> conversões de valor ex d para a data atual Tue May 14 20:23:03 CEST 2013 ?
Deve ser possível expandir subshells ex vim (find . -iname '*cfg')<tab> dá

foo.cfg bar/poo.cfg foo/bar/more/beer.cfg
> vim

Reflexões sobre seus pensamentos!

Deve ser automático pelo uso de espaço ou deve ser acionado por uma opção via tab, ou outra coisa?

Eu não acho que isso funcione com nada _sem_ espaço (e digite) porque o objetivo é obter a experiência perfeita que você obtém com aliases onde você não precisa pensar em algo ser um alias ou não, e a guia não funciona porque g<Tab> deve completar comandos que começam com g . Se adicionarmos uma nova ligação, digamos CTRL-X, agora temos três tipos de conclusões: normais, sugestões automáticas e abreviações. Eu realmente acho que isso precisa ser feito com espaço ou não precisa.

Deve ser apenas para strings simples ex g para git?

Na posição de comando, deve ser possível incluir argumentos em uma abreviatura. Por exemplo gc expandindo para git commit --all ou o que você quiser. Basicamente, penso nas abreviações como sendo exatamente como apelidos, exceto que se expandem ao vivo na linha de comando.

Deve ser aplicável apenas para o primeiro item da linha de comando ou em qualquer lugar?

Apenas na posição de comando é provavelmente um bom começo. Então, podemos _talvez_ experimentar os casos de uso de posição de argumento que sugeri antes.

Deve ser possível fazer string -> conversões de valor ex d para a data atual Ter 14 de maio 20:23:03 CEST 2013?

Você quer dizer em posição de argumento? echo d expandindo para ecoar a data? Eu realmente acho que se fizermos abreviações de posição de argumento, ele precisa ser usado de forma muito conservadora e _somente_ quando o argumento é um comando (como no caso de sudo ) ou quando o comando tem seu próprio sistema de alias (como no caso de git ) e expandir teria exatamente o mesmo efeito que não expandir (portanto, expandimos apenas para usabilidade).

Deve ser possível expandir subshells ex vim (find . -iname '*cfg')<tab>

Acho que é uma questão de conclusões e não de abreviações, já que não acho que abreviações envolvam tab e expandir subshells no espaço é provavelmente uma má ideia. No entanto, não tenho certeza se isso pode funcionar para conclusões porque você já pode completar nomes de variáveis ​​sem expandi-los.

Mas pode ser útil. Como eu imagino fazer rm *.png , expandindo o curinga e removendo alguns dos arquivos da lista.

Que tal: temos um sistema genérico de "expansão" ou "abreviação" semelhante ao sistema de completação; ligamos CTRL-X ou algo para expandir tokens; e na posição de comando também expandimos as abreviações automaticamente. Isso também poderia fazer os casos de uso de sudo e git funcionarem de forma menos intrusiva, tornando essas expansões explícitas.

É uma proposta muito maior do que a minha ideia original, no entanto. :piscadela:

Espaço como gatilho parece bom para mim, provavelmente oferece a melhor experiência do usuário.
Expandir *.png parece interessante;)
Eu mesmo não gosto de muitos vínculos diferentes para coisas diferentes, talvez "tabulação dupla" possa ser usada em vez de um novo vínculo.
Ex ....*.png<tab> dá press <tab> again to expand *.png (o mesmo para subshells).

Mas pode ser melhor limitar esta proposta a: abreviações para a posição de comando, expandindo usando espaço.
E tem "expandir subshells / curingas" e suporte a sudo separadamente?

Não tenho certeza se a tabulação dupla funcionaria, pois atualmente circula entre as conclusões. O Vim parece ter CTRL +] para expandir abreviações sem digitar um espaço ...

Acho que se fizermos expansões ao vivo, então as abreviações devem ser implementadas com isso de alguma forma, para que as ideias sejam relacionadas. Mas se não fizermos expansões ao vivo, as abreviações ainda devem ser consideradas por conta própria. Portanto, não tenho certeza do que fazer aqui. :-)

Sim, você está certo sobre <tab> , estava pensando apenas em subshells (onde atualmente não faz nada).
Pode ser possível alterar o comportamento atual de <anything><space><tab> que atualmente percorre todos os arquivos disponíveis no diretório atual (primeiro imprimindo todos eles).
Ex

> ls <tab>
a.cfg  b.cfg  c.cfg  d.cfg
> ls <tab>
> ls a.cfg<tab>
> ls b.cfg<tab>

Mas eu prefiro ter "expansões ao vivo" usando uma nova combinação de teclas do que viver sem ela;)
Expandir *.cfg para a.cfg b.cfg c.cfg d.cfg parece realmente útil.
Mas, então, todas as formas de expansões possíveis devem ser expansíveis, não apenas caracteres curinga, preenchimento de colchetes (que eu preferiria ver removido ... mas esse é um problema diferente # 354)

Mas, então, todas as formas de expansões possíveis devem ser expansíveis, não apenas caracteres curinga, preenchimento de colchetes (que eu preferiria ver removido ... mas esse é um problema diferente # 354)

Acordado em ambas as contas. Eu me pergunto se as aspas duplas deveriam ser expansíveis também ... echo "hello $USER" -> echo "hello dag" .

Acho que o que estamos falando aqui é na verdade "avaliação" mais do que "expansão", enquanto por outro lado as abreviações não são sobre avaliação, então essas idéias são provavelmente separadas e farei uma nova edição para a outra e editarei este um pouco.

Aqui está um protótipo básico de trabalho:

function __fish_expand_abbreviation
    if test (count (commandline -poc)) -eq 0
        switch (commandline -t)
            case g
                commandline -t git
            case gc
                commandline -t 'git commit'
        end
    end
end

bind \  '__fish_expand_abbreviation; commandline -i " "'
bind \n '__fish_expand_abbreviation; commandline -f execute'

Um problema que notei é que se você pressionar Enter para executar uma linha de comando abreviada, a forma expandida é destacada como um erro (comando desconhecido), mesmo incluindo os argumentos.

Gostei muito disso, então implementei uma forma de gerenciar essas abreviações.

No final, acho que isso deve ser tratado da mesma forma que as conclusões e funções são tratadas. Com sua própria pasta de abreviações onde pode ser salvo.

Esta é a implementação atual:

function __fish_expand_abbreviation
  if test (count (commandline -poc)) -eq 0
    set -l token (commandline -t)

    if abbreviations -q $token
      commandline -t (abbreviations $token)
    end
  end
end

function abbreviations --description 'List, show and query abbreviations'
  if test (count $argv) = 0
    printf '%s\n' $fish_abbreviations
    return
  end

  set -l abbreviation_index 0
  set -l expanded_abbreviation

  for i in $fish_abbreviations
    set abbreviation_index (math $abbreviation_index + 1)
    echo $i | read -l abbreviation command

    if test $abbreviation = $argv[-1]
      set expanded_abbreviation $command
      break
    end
  end

  if test -n "$expanded_abbreviation"
    switch $argv[1]
      case -q --query
        return 0
      case -e --erase
        set -e fish_abbreviations[$abbreviation_index]
      case '*'
        echo $expanded_abbreviation
      end
  else
    return 1
  end
end

function abbreviate --description 'Define a new abbreviation'
  if test (count $argv) -lt 2
    echo 'abbreviate: Takes two arguments. First abbreviation and then expanded command'
    return 1
  end

  echo $argv | read -l abbreviation command

  eval "function $abbreviation; $command \$argv; end"
  abbreviations -e $abbreviation

  set -U fish_abbreviations $fish_abbreviations "$argv"
  return 0
end

Então você faz algo assim:

abbreviate !    'sudo'
abbreviate tf   'tail -f'
abbreviate l    'ls -la'
abbreviate l.   'ls -d .*'
abbreviate g    'git'
abbreviate gs   'git status'

Atualização 1: Adiciona capacidade de remover abreviações e armazená-las em uma variável universal.
Atualização 2: crie funções para abreviações também

Observando como as funções funcionam, podemos apresentar:

• abbred
• abbrsave

O que basicamente seria clonar essas funções.

Agradável! Não estou _bastante_ convencido de que precisamos de um diretório ~/.config/fish/abbreviations e do acompanhamento abbr{ed,save} . Ao contrário das funções e completações, eles não são realmente lentos para carregar individualmente e precisam apenas de uma única linha para ser definida. Eu acho que eles são mais parecidos com bind , talvez pudéssemos ter uma função fish_[user_]abbreviations como a função fish_user_key_bindings , que carrega na primeira vez que o peixe tenta expandir uma abreviação? ( [user_] para consistência, mas não tenho certeza se devemos enviar abreviações padrão?)

A única razão que posso pensar para ter vários arquivos para abreviações é se você disser uma abreviatura para cada comando git existente e alguns com argumentos, de forma que você os deseja separados de todos os outros. Mas não é assim que as funções de carregamento lento e as conclusões funcionam: elas são carregadas com base no nome do comando, então, se fizéssemos isso para as abreviações, acabaríamos com um arquivo para cada abreviatura, cada arquivo contendo apenas uma linha de código !

Outra ideia é fazer algo como as variáveis ​​universais, talvez até usando universais (como set -U fish_abbreviations ). Talvez haja um caso de uso para abreviações locais do host? Não tenho certeza.

Você tem alguns pontos positivos e estou inclinado para o caminho fish_user_abbreviations .

A outra abordagem seria ter conclusões semelhantes em que você coloca todas as abreviações relacionadas em um arquivo, mas isso pode ser mais difícil de mapear.

Eu estava planejando usar set -U fish_abbreviations no início, mas gosto de ter a configuração mantida pelo git, então prefiro defini-la em algum lugar, como uma configuração. Mas o bom com uma variável universal seria que você pode adicionar conclusões em tempo real, sem qualquer hazle, como ( abbred , abbrsave ). Basta fazer um abbreviate .

Uma solução seria deixar o comando garantir que as abreviações sejam adicionadas de forma exclusiva e sobrescrever as existentes. Em seguida, ele seria inicializado com fish_user_abbreviations e os usuários podem adicionar outros personalizados à variável universal, se quiserem.

Eu tenho isso agora:
set -q fish_abbreviations ; or fish_user_abbreviations

Mas isso não funcionará se eu continuar mantendo o arquivo.

Atualizei minhas funções anteriores para usar variáveis ​​universais e adicionei a possibilidade de apagá-las e também verificar antes de adicionar novas, se elas existem.

Eu estava pensando em torná-lo mais interativo, como perguntar se deveria substituir a abreviatura atual. Mas, uma vez que também pode ter um script, eu não queria fazer isso. Analisarei a determinação do modo interativo.

Bem, veja o que acontece com as conclusões: até mesmo elas são carregadas para um único comando. Se o processo de linha de comando atual for git então completions/git.fish será carregado. Quando você tem nomes de comando separados, você deve fazer arquivos separados, veja, por exemplo, as conclusões para [ef]grep que estão na verdade em uma função que é chamada de cada um desses três arquivos de conclusão.

Com abreviações, não vejo nenhuma maneira de saber pela abreviatura qual arquivo carregar, a menos que o nome do arquivo _ seja_ a abreviação. E então você não pode ter várias abreviações em um arquivo. Acho que poderíamos carregar todos os arquivos de abreviações no início ou na primeira tentativa de expandir as abreviações, mas isso é diferente de como as funções e conclusões são carregadas e pode ser potencialmente lento se você tiver muitos arquivos de abreviações.

Nova ideia: abbreviate -U para fazer uma abreviatura universal e abbreviate -g ou apenas abbreviate para fazer uma abreviatura global? Se fizermos isso, talvez devamos considerar fazê-lo por bind também ...

Além disso, acho que abbreviate deve apenas substituir qualquer abreviação existente, o mesmo que bind e function e set ...

Todos são pontos válidos. Acho que faz sentido apenas substituir como todas as outras funções fazem.

Também gosto da sugestão com universal e global, que dá flexibilidade para escolher como lidar com suas abreviações / encadernações. Não tenho certeza de como implementar isso, porém, e estou pensando que talvez isso deva ser um recurso embutido para melhorar o desempenho.

Sim, eu estava apenas fazendo um protótipo em script de peixe para experimentá-lo. Provavelmente não deseja que um script lento seja acionado toda vez que você digitar um espaço. :piscadela:

Sim, ainda está funcionando muito bem. Estou usando há cerca de 1 dia e não consigo mais me imaginar vivendo sem ele, haha: sorriso:

:corar:

Outro problema que notei é que se você fizer C-a em uma linha de comando não vazia e digitar uma abreviação, ela não será expandida no espaço, pois você está no meio de uma palavra. Então, digamos que você faça make install oops precisa de root C-a ! agora você tem ![cursor]make install e digitar o espaço não expande a abreviação ! . Vou tentar contornar isso com commandline -C .

Um terceiro problema, que pode ser um recurso, é que ele só é expandido quando você digita um espaço ou insere após uma abreviatura. Portanto, não por exemplo, se você digitar um espaço C-a ! C-e . Isso pode ser um recurso porque torna possível evitar a expansão de abreviações, mas acho que é um pouco complicado e, em vez disso, deveríamos ter como um comando para executar uma linha de comando literalmente, um pouco como o comando command mas também contabilizando para funções de shell e embutidos. Ou alguma sintaxe especial, como \g na posição de comando é interpretada como g e não expandida. A sintaxe especial também não é muito suspeita, mas já temos espaço antes do comando especial para significar "não logar no histórico", então dê de ombros.

Quarto, e este é um obscuro, se você fizer como no parágrafo anterior, então você tem uma abreviatura não expandida seguida por um espaço, então faça C-a e espaço, a abreviação é expandida e um espaço extra é inserido depois disso! Novamente, pode ser necessário verificar a posição do cursor com commandline -C .

Ah e, o primeiro problema que mencionei em um comentário anterior, isso só acontece se a abreviatura não expandida for um comando desconhecido. Portanto, uma abreviatura gc expande para git commit e tudo se destaca como um erro, ao pressionar Enter (sem espaço), mas uma abreviação gs expande para git status e realça corretamente, porque aparentemente eu tenho o ghostscript instalado:

> which gs
/usr/bin/gs

Também estou me perguntando se abreviações deveriam ser destacadas como "comandos" conhecidos, mesmo antes de você apertar o espaço ... Atualmente, se eu digitar g ele fica vermelho até digitar um espaço, mas se eu digitar git ele destaca como conhecido antes mesmo de um espaço.

Todos esses problemas provavelmente poderiam ser resolvidos melhor se fizermos isso nas partes do C ++.

Solução tola para problemas de realce de sintaxe: crie um alias / função para cada abreviatura. :rindo:

Na verdade, talvez seja uma boa ideia fazer de qualquer maneira, hm ... Significa que as abreviações funcionarão em scripts, em eval , com type ... Não tenho certeza.

Sua solução alternativa é o que estou usando atualmente, mas não tenho certeza se é isso que deveria fazer no final, ou se eles deveriam ser usados ​​dentro de eval ou type . Para mim, eles devem ser apenas uma coisa de entrada. Mas eu acho que pode não fazer mal deixá-los ser executados para obter suporte fácil para, digamos, sudo.

Portanto, estou usando a implementação atual há algum tempo e estes são os problemas descobertos com esta solução até agora (eles não estão relacionados à abordagem: +1 :):

1. Ao colar texto, o último espaço é inserido no início da linha, por exemplo, echo this is a test torna-se _echo this is atest quando colado, onde _ é um espaço.
2. Ao usar read embutidos, as ligações em enter e space também se aplicam lá. Então, por exemplo, se eu quiser inserir algum comando que não seja para ler, ele se expandirá. Acho que na implementação final isso deve estar desativado por padrão e habilitado por read -s
3. É um pouco lento (~ 0,25-0,5 segundos)

Você pode contornar 1. colando C-y .

Para mim, C-y cola apenas dentro do peixe (do que foi cortado dentro do peixe) e não da área de transferência do meu sistema. Copiar entre terminais ou outros aplicativos.

Acho que abreviações são uma ideia muito legal.

Quero permitir que as pessoas experimentem abreviações para refinar quais devem ser os comportamentos corretos. Eu verifiquei no suporte inicial para abreviações no mestre como 92099c7af23d0cebf52f89de4f9d829825e53ac8 e f9c2a77c67754324f3036ec79501c6131d19562b.

Um exemplo de como usá-lo:

set -U fish_user_abbreviations 'gc=git checkout'
gc

gc será expandido para "git checkout" no espaço ou retorno.

As abreviações são uma lista, portanto, para adicionar uma nova:

set fish_user_abbreviations $fish_user_abbreviations 'grh=git reset --hard'

As abreviações se expandem em "posições de comando" (por exemplo, em subshells ou como argumentos para if), mas não como argumentos. As abreviações também não se expandem nos scripts.

Aqui estão alguns problemas não resolvidos para discussão:

1. "Abreviação" é longa e difícil de soletrar - podemos encontrar um nome melhor? "Alias" seria bom se já não fosse usado para outras coisas. Uma possibilidade é invertê-lo, por exemplo, "expansão". fish_user_expansions parece bom para mim.
2. Como as abreviações devem ser especificadas? A sintaxe gc=git checkout é leve, mas não é usada em nenhum outro lugar em peixes.
3. Podemos querer não expandir na entrada, apenas espaço. Expandir em enter tem a desvantagem de que o usuário não vê o comando que executou antes de se comprometer a executá-lo. Se expandirmos apenas no espaço, os usuários podem digitar a abreviatura, seguida de espaço, seguida de enter, o que não parece muito pesado. Uma segunda possibilidade é fazer a primeira expansão do acionador de entrada, e a segunda entrada realmente executá-la.

Por outro lado, se todas as abreviações forem especificadas pelo usuário, a chance de o usuário executar algo acidentalmente é baixa, portanto, expandir em enter pode ser bom.

1. A forma expandida de uma abreviatura é apenas uma substituição textual e não precisa ser um comando válido. Por exemplo, você pode fazer uma abreviação que resulte em aspas incompatíveis ou parênteses. Acho que esse é um recurso potencialmente útil, mas significa que o fish não pode fazer a verificação de sintaxe em códigos que contenham abreviações, o que significa que talvez nunca possamos usá-los em scripts.
2. A expansão da abreviatura deve sofrer expansão de subcamadas e variáveis ​​antes da substituição? Acho que sim, porque isso os tornaria imensamente flexíveis. Abreviações podem então executar códigos de peixes arbitrários.
3. Se eu clicar em espaço, e a abreviação expandir e eu mudar de ideia, talvez eu deva ser capaz de clicar em excluir e expandir.

Esperançosamente, depois de viver com eles por um tempo, saberemos o que parece certo.

Obrigado, estou executando-o agora e parece funcionar muito bem até agora.

1. Poderíamos usar a abreviatura abbr para abreviar. Quanto a alias , se acharmos que é melhor, talvez pudesse ser substituído por este comportamento. Se as pessoas quiserem usar apelidos em seus scripts, elas podem apenas fazer o agrupamento de funções. Abreviações me parecem exatamente o que as pessoas usam normalmente.
2. Acho que seria bom ter algumas funções auxiliares para definir e também remover abreviações.
   Por exemplo: abbr gc 'git checkout' e abbr -e gc .
   É um pouco complicado fazer essa manipulação por meio da variável na minha opinião. Também seria bom garantir que as abreviações são exclusivas. Então você só precisa definir um novo para atualizá-lo.
3. Eu prefiro o comportamento que é agora, muitas das minhas abreviações como gs para git status não seriam tão úteis se você tivesse que pressionar espaço. No entanto, não haveria problema com duplo enter para realmente executá-lo, conforme você mencionou.
4. Pessoalmente, estou bem em não usá-los em scripts.
5. Sim, isso seria legal. Não consigo pensar em nenhuma abreviatura para usar isso no topo da minha cabeça.
6. Essa também é uma boa ideia, se eu apertar a barra de espaço muito cedo para uma abreviação, por exemplo. Isso também iria bem junto com a sugestão de número 3 como duplo enter (ainda não tenho certeza se eu quero esse enter extra embora).

alias é um invólucro de compatibilidade POSIX de qualquer maneira. Eu não tenho nenhum problema com abreviações. Se você escrever abbr gc 'git checkout' ou algo assim, você deseja conclusões para git checkout qualquer maneira.

usei a implementação de script do terlar nas últimas semanas e mudei para a nova versão nativa hoje, então aqui estão meus dois centavos nos pontos abertos

1. Acho que seria uma ótima ideia deixar alias fazer abreviações agora. Como bônus, ele consertaria as conclusões que não funcionavam nos aliases atuais.
2. o que o terlar disse parece bom
3. Eu realmente me incomodaria se eu precisasse pressionar Enter nas abreviações para executá-las. Seria bom se eles também funcionassem não expandidos como pseudônimos com um único pressionamento de Enter, mas então eu tenho abreviações não expandidas em minha história
4. -
5. a expansão da variável não significaria que o conteúdo das variáveis ​​será colocado no comando e, portanto, em seu histórico? Isso tornaria a reutilização de tais comandos do histórico muito mais baixa, pois eles não contêm mais a variável, mas apenas seu conteúdo anterior. Ou eu entendi mal este ponto?
6. Não me vejo usando o recurso não expandido porque não uso abbreviation mais de 3 caracteres, o que significa que todos estão basicamente na memória muscular e seria mais rápido apenas limpar a linha atual. Isso pode ser diferente agora, visto que a implementação nativa pode ser usada em qualquer lugar e não apenas no início da linha. Mas provavelmente é uma boa ideia, se isso não significa que eu sempre tenho que pressionar espaço ou pressionar duas vezes Enter para expandi-los.

"Abreviação" é longa e difícil de soletrar - podemos encontrar um nome melhor? "Alias" seria bom se já não fosse usado para outras coisas. Uma possibilidade é invertê-lo, por exemplo, "expansão". fish_user_expansions parece OK para mim.

Acordado, mas não vendido em "expansão".

Como as abreviações devem ser especificadas? A sintaxe de verificação gc = git é leve, mas não é usada em nenhum outro lugar em peixes.

Deve ser simplesmente um novo integrado, como complete e bind ou function que o usuário pode chamar, mas cujo armazenamento subjacente é opaco.

Podemos querer não expandir na entrada, apenas espaço. Expandir em enter tem a desvantagem de que o usuário não vê o comando que executou antes de se comprometer a executá-lo. Se expandirmos apenas no espaço, os usuários podem digitar a abreviatura, seguida de espaço, seguida de enter, o que não parece muito pesado. Uma segunda possibilidade é fazer a primeira expansão do acionador de entrada, e a segunda entrada realmente executá-la.

Eu realmente acho que queremos expandir o Enter . Imagino que receberia muitos fish: Unknown command “gc” frustrantes e não imagino que estaria sozinho nisso. Porém, a expansão deve acontecer na linha de comando, antes de ser executada, de forma que você veja a expansão em scrollback e é a forma expandida que acaba no histórico.

A expansão da abreviatura deve sofrer expansão de subcamadas e variáveis ​​antes da substituição? Acho que sim, porque isso os tornaria imensamente flexíveis. Abreviações podem então executar códigos de peixes arbitrários.

Eu acho que não deveria. Normalmente, seria preferível que eles fossem expandidos no momento em que a linha de comando fosse executada. Digamos que eu tenha uma abreviatura para criar notas com carimbo de data / hora. Eu digito a abreviatura e um espaço, e ele se expande para algo como vim 12:34:56.txt . Agora, eu não executo este comando por alguns segundos, e o carimbo de data / hora estará errado. Seria melhor se a abreviatura expandisse para vim (time +%T).txt . Isso faz a coisa certa e também significa que tenho a opção de editar a linha de comando antes de executá-la, por exemplo, para usar um formato de hora diferente. Também o torna repetível; por exemplo kill %firefox pode ser recuperado do histórico e executado novamente mesmo quando o PID foi alterado. Por último, eu diria que é mais consistente com o resto do fish, onde os tokens na linha de comando são avaliados apenas em tempo de execução.

Por outro lado, avaliar o tempo de expansão é estritamente mais poderoso porque podemos optar por sair dele com, por exemplo, escapes, mas sem ele não podemos realmente _optar_. Acho que isso seria melhor resolvido com # 751, pois coloca o usuário no controle da avaliação. Isso ainda não fornece uma maneira de obter o momento _exato_ da expansão da abreviação; seria o momento do usuário expandindo o token individual. Ainda assim, acho que seria mais útil e mais consistente, pois funcionaria não apenas com abreviações, mas com qualquer token na linha de comando que pudesse ser avaliado, no entanto, foi adicionado à linha de comando.

Se eu clicar em espaço, e a abreviação expandir e eu mudar de ideia, talvez eu deva ser capaz de clicar em excluir e expandir.

Acho que isso não deve ser excluído ou retrocedido, porque parte da minha motivação para abreviações é a capacidade de pós-editar _partes_ da expansão antes da execução. Talvez uma ideia melhor seria adicionar um vínculo para "deletar de trás para frente do cursor para o processo atual" conforme definido por commandline -p . Isso resolveria o problema das abreviações (já que elas só se expandem na posição de comando), mas ao mesmo tempo seria muito útil sem abreviações. Isso funcionaria basicamente como Ctrl-U, mas para no início do "processo" atual. Uma variante correspondente a Ctrl-K que pára no _end_ do processo atual pode ser adicionada para consistência e também pode ser útil.

Isso pode ser diferente agora, visto que a implementação nativa pode ser usada em qualquer lugar e não apenas no início da linha.

Eu não tentei a implementação do @terlar , mas é baseada na minha, onde as expansões realmente funcionam corretamente em _qualquer_ posição de comando, não apenas no início da linha, parabéns commandline -p . Na verdade, estou surpreso com o quão bem meu código de prova de conceito funciona bem! : peixe:: coração:

hmm acho que nunca tentei usar abreviações em outras posições de comando.
Sim, os protótipos funcionaram muito bem, o único inconveniente que tive foi o problema de colagem mencionado, mas o recurso era bom demais para não usá-lo.

@ sch1zo A colagem deve funcionar se você usar Ctrl-Y .

esse pode ser o caso, mas na maioria das vezes eu copio / colo selecionando / clique com o botão do meio e o problema está presente. Mas a implementação nativa não tem mais esse problema e já atualizei todas as minhas máquinas para usá-la.

Então, depois de aproximadamente 10 dias usando as abreviações nativas, descobri uma coisa que meio que me incomoda. Se você já tiver um comando digitado e, em seguida, pule para o início da linha para precedê-lo com uma abreviatura, ele não se expandirá e não funcionará em seu estado não expandido. Uma situação comum para mim é a seguinte:
Uma das minhas abreviaturas é !=sudo então agora, quando quero editar algum arquivo de configuração do sistema como em vim /path/to/some/file/I/am/not/allowed/to/write , muitas vezes percebo tarde que preciso do sudo, então normalmente pulo para o início e prefixo ! infelizmente isso não vai expandir a abreviação e me deixar com uma mensagem command not found .
Minha solução atual para isso é apenas adicionar um alias para abreviar, mas, obviamente, seria melhor se expandisse corretamente.

Concordou; precisamos olhar para a posição do cursor quando o espaço é inserido, não simplesmente "o primeiro token". Como alternativa, primeiro insira o espaço e, em seguida, analise novamente a linha de comando e expanda a abreviação.

A confirmação b6f495d1077b7627ea851da33936c77b2d594bb2 deve corrigir o problema que @ sch1zo identificou (com! Para sudo)

Outra coisa a acrescentar a isso: provavelmente devemos fazer ll , la , e apelidos semelhantes por padrão em vez de funções.

Estou redirecionando isso para next-minor pois esse recurso provavelmente será fornecido na próxima versão.

O próximo lançamento provavelmente será em breve, ou seja, no final da próxima semana. Estou apenas limpando a documentação no momento.

As abreviaturas serão incluídas em seu estado atual incompleto. Não quero publicá-los ou documentá-los até que tenhamos o comando abbrev (ou reaproveite alias ). Por esse motivo, estou empurrando de volta para o próximo grande.

Não acho que alias seja um bom termo. Para mim, alias é um nome alternativo ... não algo a ser expandido.

Também não gosto de abbr , pelo mesmo motivo.

Pensei em expand foo "foobar" ... mas parece que o comando expand já existe: / Que pena, acho que expand teria sido o melhor termo.

Que tal unificar apelidos e abreviações? Em vez de introduzir uma nova função ou descontinuar alias , introduza uma opção de configuração para "expandir aliases". A desvantagem aqui é que não gostamos das opções de configuração no fish (mas poderíamos pular a opção de configuração) e (talvez uma coisa boa) isso significa que não podemos misturar os dois comportamentos, embora você ainda possa escrever funções normais para obter o antigo comportamento de alias ... A vantagem é que não temos duas maneiras de fazer coisas semelhantes, é fácil de explicar ("aliases expandem em peixes") e as abreviações funcionam em scripts (porque também são aliases) que também significa que eles não precisam ter letras especiais no realce de sintaxe. E ao mover o mecanismo do alias para o código C ++, podemos evitar a lentidão da implementação do alias atual. Ainda preciso descobrir como fazer completações funcionarem para aliases não expandidos.

Um pedido de recurso ...

Anteriormente, eu estava usando funções para emitir combinações de comando usadas com frequência em um único comando, como git add, git commit e git push em uma operação.

Eu amo o novo recurso de abreviatura. Acho que é enorme e estou tentando mudar para isso. Estou ok com o fato de que é limitado a uma única expansão de comando. No entanto, ainda quero emitir vários comandos de uma vez. Agora posso usar apenas uma abreviatura para o primeiro comando, seguida de um ponto e vírgula, depois a abreviatura para o segundo comando, etc. Funciona bem, na verdade acho que é melhor assim.

Meu pedido é que a expansão seja disparada não apenas por espaço ou enter, mas também por ponto-e-vírgula. Como o ponto-e-vírgula é basicamente equivalente a uma entrada atrasada, estou supondo que isso fará sentido para todos vocês também.

Mal posso esperar para que este recurso seja lançado oficialmente!

Faz sentido para mim.

1a7b33e8fb75dd702730ca9637d760fbd23a4000 expande abreviações em ponto-e-vírgulas.

Obrigado!

Onde os fish_user_abbreviations são armazenados? Quero adicioná-los ao meu repositório dotfiles.

Atualmente é uma variável universal, portanto, é armazenada em ~ / .config / fish / config.fish. Mas este é apenas um hack temporário, até descobrirmos a maneira adequada de armazená-los. Feedback aqui é bem-vindo.

Se desejar, você pode apenas adicionar uma linha ao config.fish como set -g fish_user_abbreviations... para defini-lo manualmente.

Hrm, não vejo essa variável aí.

Usei set -U fish_user_abbreviations 'g=git' . É a maneira certa de colocá-lo no config.fish?

Desculpe, quis dizer que seria armazenado em ~/.config/fish/fishd.[mac_address] . Obviamente sincronizar isso não funcionará (por design), uma vez que é desconectado do MAC.

Para colocá-lo no config.fish, você escreveria `set -g fish_user_abbreviations 'g = git'. -g para global, já que você está configurando-o todas as vezes.

Eu acho que a variável universal é razoavelmente legal, ela só precisa de uma IU melhor envolvida nela.

Se o usarmos como um array, com = para dividir chaves e valores ou ASCII FS ( \x1c ), então uma função de peixe para gerenciá-lo ( abbr ) + / - uma página de interface da web seria útil.

Seria necessário pensar em produzir uma produção apropriada para exportação / transferência.

@ridiculousfish Ahh, obrigado, isso é muito útil! Vou fazer isso por enquanto até que haja um processo de exportação.

A propósito, sou neutro quanto a A) um único arquivo com todas as abreviações ou B) um arquivo separado para cada abreviatura. Talvez inclinado para A, mas não fortemente.

Eu adicionei uma IU básica em torno da implementação existente como abbr - use abbr -h para ver mais. Também adicionei uma IU somente para visualização à interface da web, mas seria bom que ela fizesse mais.

Em vez de usar = como separador, poderíamos apenas usar o primeiro token (separado por espaço?) De cada item do array - isso simplificaria a implementação.

A variável universal é legal, mas se não a estivermos expondo diretamente, pode ser melhor movê-la para __fish_user_abbreviations (e possivelmente avisar sobre defini-la em um nível local ou global).

Eu preferiria space-separated vez de usar = como separador. Especialmente porque esse estilo não é usado em nenhum outro lugar dentro de fish .

Eu concordo que isso deve ser separado por espaços. Faz um pouco mais de sentido e significa que = poderia realmente fazer parte da abreviatura, se desejado. O comando abbr provavelmente deve ser modificado para eliminar o sinalizador --add e apenas receber dois argumentos.

Em relação a $__fish_user_abbreviations , posso simpatizar com esta sugestão, mas é plausível que os usuários possam querer modificar $fish_user_abbreviations sem usar o comando abbr , e prefiro não encorajar qualquer pessoa para modificar diretamente uma variável $__fish_* . Da mesma forma, defini-lo no nível local ou global é perfeitamente legítimo; nem todo mundo quer usar variáveis ​​universais para coisas como essa.

Em uma nota relacionada, read provavelmente deve expandir as abreviações na entrada interativa ao usar o sinalizador --shell .

Minha preocupação em encorajar a modificação da variável fora do comando abbr é que estender o comando para dar suporte ao escopo aumenta sua complexidade em termos de IU, mas não fazer isso leva a resultados potencialmente enganosos. Não há fusão dos escopos de variáveis ​​no momento, o que pode ser confuso - se você definir uma expansão universal e uma expansão global (diferente), ambas devem funcionar? Como você desfaz uma expansão universal no âmbito global, então? Isso é algo que as pessoas gostariam de fazer?

A separação do espaço parece uma boa ideia. Para evitar confusão, adicionar uma nova abreviatura provavelmente deve levar um número ilimitado de argumentos, com o primeiro se tornando a 'palavra' e o restante sendo agrupado para se tornar a 'frase'.

Não há necessidade de fazer nenhum trabalho para "apoiar a definição do escopo". Se abbr simplesmente usar $fish_user_abbreviations , ele usará a variável global se presente, ou a universal caso contrário. É exatamente assim que o leitor funciona. O único problema é que se o usuário definir $fish_user_abbreviations como uma variável local no nível superior, o leitor também verá isso. E a simples correção é adicionar o -S bandeira para o abbr declaração de função, que vai deixá-lo ver as variáveis locais definidas em seu pai. Mas definitivamente não há necessidade de tentar mesclar abreviações (nem nenhuma maneira de fazer isso, exceto excluir temporariamente a variável em outros escopos).

Depois de viver nisso, acho que gostaria de ver as abreviaturas sublinhadas ou destacadas de forma diferente, antes de serem expandidas. Isso me dá alguma confiança de que os digitei corretamente. Pensamentos?

O suporte do separador de espaço está em fbade198b942a666d3fc1110804a7da2c47918f1

Se você clicar no espaço e ele não expandir, você saberá que não o digitou corretamente. Não me oponho a sublinhar ou destacar (certamente seria uma dica extra para que o usuário soubesse por que sua linha de comando acabou de mudar), mas não tenho certeza se entendi por que você precisa ter confiança antes de bater na barra de espaço.

@ridiculousfish Com relação a fbade198b942a666d3fc1110804a7da2c47918f1, as abreviações são novas o suficiente (e não documentadas até o mestre recente) que devemos apenas remover o suporte = .

Estou pensando no caso antes do retorno, não no caso antes do espaço

Parece bom para mim. Suponho que _é_ possível exagerar no realce, resultando em lentidão e sobrecarga de informações desorientadora, mas não acho que seja o caso aqui. Além disso, presumo que ele usaria alguma variável $fish_color_abbr-or-whatever para que pudesse ser facilmente desativado por aqueles que assim o desejassem, por qualquer motivo.

A princípio, eu ia comentar que não achei intuitivo que o comportamento de realce seja diferente para abreviações vs comandos normais, até que percebi que estava incorreto e que era consistente.

Minha confusão veio do fato de que eu estava misturando o realce e o recurso de conclusão sugerida.

Por exemplo, quando eu digito "echo", o destaque fica em vermelho até que eu digite o comando completo, que é como deveria ser. No entanto, a conclusão sugerida antecipa com sucesso o que eu estava prestes a digitar e me garante que estou indo na direção pretendida.

Não recebo esse tipo de feedback para abreviações, o que é lamentável, pois não consigo frequentemente apresentar encurtamentos memoráveis ​​de comandos, particularmente aqueles que se expandem para comandos complexos.

Na verdade, o objetivo para mim é embalar uma ampla gama de comandos em um pequeno namespace (eu atiro para abreviações de aproximadamente 5 caracteres e tenho centenas delas). Por causa disso, confio ainda mais na orientação do shell de que devo digitar um comando válido. Algo que cumpra a função que o preenchimento sugerido ocupa, mas para abreviações em vez de comandos regulares, seria realmente útil, mais do que para comandos padrão, mesmo para mim.

Posso ver a dificuldade de conclusões sugeridas por abreviações. Não seria intuitivo que a abreviatura se expandisse nos comandos reais, uma vez que não seria mais contígua ao que você está digitando. Ainda assim, sinto que poderia ser melhor do que agora.

Pelo menos para mim, incluir a própria abreviatura (não a expansão) nas conclusões sugeridas me coçaria. Só quero ver se estou digitando corretamente o prefixo de uma abreviatura definida. Isso é o suficiente para me dizer que não estou digitando em vão porque me lembrei incorretamente ou digitei incorretamente minha abreviatura.

Tentei estender abbr.fish para lidar com espaços e separadores = , mas não tive muito sucesso em apresentar uma solução robusta sem gastar com ferramentas externas.

Achei que o plano era remover o suporte =? Eu estava pensando em apenas fazer isso e, em seguida, postar uma mensagem na lista de discussão de peixes com um script que munges $ fish_user_abbreviations que as pessoas poderiam executar para alternar para espaços.

Ei pessoal,

Eu queria fazer uma anotação depois de já usar abreviações por um bom tempo.

Eu sou um grande fã e eles tornam minha vida muito mais fácil. Gosto especialmente do fato de que outras pessoas podem ver quais comandos estou emitindo, de uma forma familiar.

Meu único desagrado é que não há histórico para abreviações. Como uso abreviações para quase todos os comandos, isso acabou me fazendo perder a funcionalidade de histórico na maior parte. Embora você possa pensar que as abreviações devam ser curtas o suficiente para não precisar da funcionalidade de histórico, sinto-me faltando um pouco. Tenho mais de 200 abreviações definidas e algumas delas diferem apenas ligeiramente. Ter a história me mostrando aquele que publiquei ontem, por exemplo, seria imensamente útil para as abreviações mais complicadas e usadas com menos frequência. Como eu praticamente vivo com abreviações, tive que recorrer ao uso de funções em vez de onde preciso de suporte de histórico, pois de outra forma não tenho história.

Obrigado novamente pelo recurso.

@binaryphile Muito interessante. Parece que você tem uma ideia de como isso deve ser (ou seja, a IU). Você gostaria de descrevê-lo com mais detalhes?

Boa pergunta. Acho que gostaria que, se alguma expansão fosse acionada, a abreviatura fosse para a lista de histórico. Portanto, se minha abreviatura fosse "gclon" para "git clone", quando eu pressionasse o espaço (ou ponto-e-vírgula), "gclon" seria adicionado ao meu histórico. Eu não alteraria o comportamento normal de armazenar o comando expandido no histórico, então ambos estariam disponíveis.

Depois disso, quando comecei a digitar um prefixo da abrev (como "gcl"), esperaria que "gclon" fosse a primeira opção para o preenchimento automático aparecer.

Idealmente, nesse ponto, eu seria capaz de pressionar alt-f e fazer com que ambos fossem concluídos automaticamente na versão expandida, além de oferecer um novo preenchimento automático desse comando expandido do histórico. Eu gostaria disso porque posso ter inserido mais argumentos após a expansão, e gostaria de tê-los disponíveis com o mínimo de pressionamentos de tecla possível pela mesma rota em que inseri em primeiro lugar (abrev e depois argumentos). Visto que a abreviatura na história não teria os argumentos, alt-f seria o método mais natural para eu avançar ao longo do argumento de conclusão por argumento.

Acho que ctrl-f não mudaria e apenas avançaria para o final da abreviatura, não para a versão expandida, uma vez que não haveria nenhuma indicação visual de para onde você estaria expandindo.

Acabei de fazer um teste noturno para finalmente testar isso! Eu realmente gosto desse recurso e adoro o fato de ter o comando abbr que o acompanha.

Meu feedback é que precisamos de uma boa maneira de exportar para backup dotfile. Estou pensando que tudo isso deve ir em um arquivo no formato abbr --show outputs. abbr --show é bom o suficiente para mim por enquanto, vou apenas enviá-los para um dotfile por enquanto. Mas quero uma maneira fácil de importá-los novamente quando chegar a hora. Portanto, se Fish pudesse importar esse formato agora, seria um bom próximo passo.

Seguir o comando na ajuda para adicionar uma nova abreviatura falha com este erro.

Atualmente você precisa inserir abbr -a "gco git checkout" mas acho que faria mais sentido apoiar o caso descrito no manual.

Ahh obrigado!

48d3536 faz essa alteração.

Acho que devemos deixar o suporte ao separador '=' na próxima versão secundária e desativá-lo depois disso ou (silenciosamente?) Atualizar o fish_user_abbreviations .

Vou fechar isso como corrigido; Eu preenchi o número 2051 para rastrear a migração. Muito obrigado a @dag pelo conceito e a todos aqueles que o testaram - ansiosos para vê-lo lançado em breve!

W00t, obrigado a todos, eu realmente AMO esse recurso !!

Adoro abreviaturas, é uma experiência muito mais amigável do que apelidos. Muito obrigado!

Eu me deparei com este tópico enquanto procurava como armazenar abreviações em dotfiles ^{1 , 2} .
Se alguém tropeçar aqui pelo mesmo motivo, você pode usar abbr -s/--show . Por exemplo

abbr --show >> ~/.config/fish/config.fish

@dideler Estou usando algo semelhante para backup automatizado, também recomendo canalizar para sort .

abbr --show | sort > fish_abbreviation_backup;

Coloco tudo em um arquivo fish_abbreviation_backup e, em seguida, adiciono ao Homeshick para backup. É tudo automatizado e executado no cron. Depois de fazer backup de I source fish_abbreviation_backup para que os peixes mostrem ordem alfabética ao fazer um abbr --show .

Seria bom se o fish mantivesse abreviações em um arquivo, semelhante à forma como faz as coisas com as funções.

atualização: Problema para classificar abreviações ao armazená-las -> https://github.com/fish-shell/fish-shell/issues/2156

Seria bom se os peixes mantivessem abreviações em um arquivo ...

Na página do manual: "Abreviações são armazenadas usando variáveis ​​universais." O que significa que você os encontrará no arquivo _ ~ / .config / fish / fishd.macaddr_ sob o nome de var fish_user_abbreviations . O comando abbr simplesmente manipula essa var universal.

Obrigado, estaria tudo bem em considerar a ideia de mantê-los em ~ / .config / fish / abbreviations.fish para que possamos adicioná-los facilmente aos nossos dotfiles?

@ElijahLynn : O que eu faço é um arquivo chamado "abbrs.fish" em ~ / .config / fish / conf.d /, com o seguinte conteúdo:

if not set -q fish_initialized
    abbr -a alsamixer alsamixer -c0
    abbr -a e emacs -nw
    abbr -a \$PAGER less
    abbr -a mu4e emacs --eval "\(mu4e\)"
    abbr -a pm pulsemixer
    abbr -a rm rm -I
    abbr -a sc systemctl
    abbr -a upo upower -i /org/freedesktop/UPower/devices/battery_BAT0
    abbr -a usc systemctl --user
    # Double-escaping needed
    abbr -a d2 env WINEPREFIX=/home/alfa/.wine32/ wine ~/.wine/drive_c/Program\\ Files\\ \\(x86\\)/Diablo\\ II/Diablo\\ II.exe
    abbr -a c curl -LO -C -
    set -U  fish_user_paths ~alfa/.local/bin $GOPATH/bin
    set -U fish_initialized
end

Eu tenho isso em meus dotfiles e posso simplesmente soltá-lo em qualquer máquina onde ainda não o usei e, se quiser redefinir os abbrs, posso apagá-los todos (faço set -e fish_user_abbreviations; set -e fish_initialized ) e reinicie o peixe.

Obrigado, posso estar perdendo isso, mas parece que você precisa manter isso manualmente e não consegue adicionar e gerenciá-los facilmente com o comando abbr .

Você adiciona o comando abbr lá. Isso pode até ser a saída de uma chamada abbr --show .

Apenas na posição de comando é provavelmente um bom começo. Então, talvez possamos experimentar os casos de uso de posição de argumento que sugeri antes.

Acho que não apenas uma posição no início seria difícil, exemplo: s para sudo e n para nano que pode expandir de s n a sudo nano , mas não na implementação atual.