Fish-shell: Abréviations

Une autre idée est de nommer ces "abréviations" comme dans Vim, puis de décider quoi faire des alias dans un autre numéro [j'ai tendance à penser qu'ils devraient être supprimés].

J'ai pensé à un autre argument contre :

• Impossible d'utiliser ces "alias" dans les scripts. Pas sûr que ce soit une bonne idée d'utiliser des alias dans les scripts de toute façon, mais nous pourrions avoir une fonction pour développer les "abréviations" et/ou nous pourrions accrocher les abréviations de fish dans les éditeurs pour qu'elles s'étendent également sur les entrées.

J'aime ta proposition, ça a l'air cool et louche :+1:

J'aime aussi ça.
C'est une solution très propre au problème des "complétions pour les alias" #393 qui est assez ennuyeux.
Ceci combiné avec une impression de ll (Alias) lors d'un ll<tab> serait parfait.

Comme alias n'est qu'un wrapper de script autour de function aujourd'hui, je voudrais que cela change également afin qu'il y ait une différence distincte entre les fonctions et les alias car ils diffèrent à bien des égards après cela, ex :

• Syntaxe
• Expressibilité
• Usage

@gustafj Je pense qu'il est probablement préférable d'appeler cette idée "abréviations" et de remplacer alias par quelque chose qui affiche un message d'erreur utile pointant vers function et abbreviate . Les pensées?

Autre remarque :

Je voulais que cela n'affecte que la commande dans une ligne de commande, car ce serait vraiment ennuyeux si g continuait à s'étendre à git en position d'argument. Cependant, nous pourrions également souhaiter une certaine extension des positions des arguments, par exemple avec sudo (ce qui signifierait que vous pourriez utiliser sudo avec des abréviations - quelque chose que vous ne pouvez pas faire avec des alias !) comme pour les propres alias de git ou si vous tapez une partie d'une option longue. Bien faire les choses peut être délicat cependant, et ne gênerait que si les achèvements sont obsolètes, et si vous vouliez réellement sudo g pas sudo git vous devez maintenant faire quelque chose comme sudo (echo git) . Peut-être pourrions-nous dire que les arguments entre guillemets ne se développent jamais, vous pourriez donc dire sudo "g" . Je ne sais pas si ce serait trop magique et surprenant ou en fait exactement ce à quoi on pourrait s'attendre et avoir l'intuition. Les pensées? :-)

Les abréviations me semblent bonnes (mais je suis un utilisateur régulier de vim, donc je suis peut-être biaisé...).
Quand j'y pense, il y a pas mal de choses "intéressantes" qui peuvent être faites avec ça, mais (comme vous l'avez déjà souligné) il y a aussi des pièges cachés dans ce champ de mines :/

Je pense que cela pourrait être problématique/ennuyeux si c'est complètement automatique et à n'importe quel endroit de la ligne de commande, surtout parce que l'annulation de l'abréviation pourrait être fastidieuse si elle s'étend à quelque chose que vous ne voulez pas et en particulier si elle s'étend à une longue chaîne.

Quelques réflexions personnelles :
Doit-il être automatique en utilisant space ou doit-il être déclenché par une option via tab , ou autre chose ?
Cela ne devrait-il être que pour les chaînes simples ex g pour git ?
Cela ne devrait-il s'appliquer qu'au premier élément de la ligne de commande, ou n'importe où ?
Devrait-il être possible de faire des conversions chaîne -> valeur ex d pour la date actuelle Tue May 14 20:23:03 CEST 2013 ?
Devrait-il être possible d'étendre les sous-shells ex vim (find . -iname '*cfg')<tab> donne

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

Pensées sur vos pensées!

Doit-il être automatique en utilisant l'espace ou doit-il être déclenché par une option via un onglet, ou autre chose ?

Je ne pense pas que cela fonctionne avec quoi que ce soit _mais_ espace (et entrez) parce que le but est d'obtenir l'expérience transparente que vous obtenez avec les alias où vous n'avez pas à penser à quelque chose qui est un alias ou non, et l'onglet ne le fait pas fonctionner soit parce que g<Tab> devrait terminer les commandes qui commencent par un g . Si nous ajoutons une nouvelle liaison, disons CTRL-X, nous avons maintenant trois types de complétions : les normales, les autosuggestions et les abréviations. Je pense vraiment que cela doit être fait avec de l'espace ou pas du tout.

Cela ne devrait-il être que pour les chaînes simples ex g pour git ?

En position de commande, il devrait être possible d'inclure des arguments dans une abréviation. Par exemple, gc développe en git commit --all ou quoi de plus. Fondamentalement, je pense que les abréviations sont exactement comme les alias, sauf qu'elles se développent en direct sur la ligne de commande.

Cela ne devrait-il s'appliquer qu'au premier élément de la ligne de commande, ou n'importe où ?

Seulement en position de commandement est probablement un bon début. Ensuite, nous pouvons _peut-être_ expérimenter avec les cas d'utilisation de position d'argument que j'ai suggérés auparavant.

Devrait-il être possible d'effectuer des conversions chaîne -> valeur ex d pour la date actuelle mar 14 mai 20:23:03 CEST 2013 ?

Vous voulez dire en position d'argumentation ? echo d développant pour faire écho à la date ? Je pense vraiment que si nous faisons des abréviations de position d'argument, il doit être utilisé de manière très prudente et _uniquement_ lorsque l'argument est une commande (comme dans le cas de sudo ) ou lorsque la commande a son propre système d'alias (comme dans le cas de git ) et l'expansion aurait exactement le même effet que la non-expansion (nous ne développons donc que pour la convivialité).

Devrait-il être possible d'étendre les sous-shells ex vim (find . -iname '*cfg')<tab>

Je pense que c'est une question de complétions et non d'abréviations, car je ne pense pas que les abréviations impliquent des tabulations et des sous-shells en expansion sur l'espace sont probablement une mauvaise idée. Cependant, je ne suis pas sûr que cela puisse fonctionner pour les complétions non plus, car vous pouvez déjà compléter les noms de variables sans les développer.

Ça peut être utile quand même. Comme j'imagine faire rm *.png , développer le caractère générique et supprimer certains des fichiers de la liste.

Que diriez-vous de ceci : nous avons un système générique « d'expansion » ou « d'abréviation » similaire au système de complétions ; nous lions CTRL-X ou quelque chose pour étendre les jetons ; et en position de commande, nous développons également automatiquement les abréviations. Cela pourrait également rendre les cas d'utilisation sudo et git moins intrusifs en rendant ces extensions explicites.

C'est une proposition beaucoup plus grande que mon idée originale, cependant. :clin d'œil:

L'espace comme déclencheur me semble bien, donne probablement la meilleure expérience utilisateur.
Développer *.png semble intéressant ;)
Moi-même, je n'aime pas beaucoup de liaisons différentes pour différentes choses, peut-être que "double tabulation" pourrait être utilisé au lieu d'une nouvelle liaison.
Ex ....*.png<tab> donne press <tab> again to expand *.png (le même pour les sous-shells).

Mais il serait peut-être préférable de limiter cette proposition à : des abréviations pour la position de commande, en développant en utilisant l'espace.
Et avoir "expand subshells/wildcards" et le support sudo en tant que support séparé?

Je ne suis pas sûr que la double tabulation fonctionnerait car cela fait actuellement un cycle entre les achèvements. Vim semble avoir CTRL+] pour développer les abréviations sans taper d'espace...

Je pense que si nous faisons des extensions en direct, alors les abréviations devraient être implémentées avec cela d'une manière ou d'une autre, donc les idées sont liées. Mais si nous ne faisons pas d'extensions en direct, les abréviations doivent toujours être considérées comme telles. Je ne sais donc pas quoi faire ici. :-)

Oui, vous avez raison à propos de <tab> , je ne pensais qu'aux sous-shells (où il ne fait rien actuellement).
Il pourrait être possible de modifier le comportement actuel de <anything><space><tab> qui parcourt actuellement tous les fichiers disponibles dans le répertoire actuel (d'abord en les imprimant tous).
Ex

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

Mais je préférerais avoir des "extensions en direct" en utilisant une nouvelle combinaison de touches plutôt que de vivre sans ;)
Étendre *.cfg à a.cfg b.cfg c.cfg d.cfg est vraiment utile.
Mais alors toutes les formes d'extensions possibles devraient être extensibles, pas seulement les caractères génériques, l'achèvement ex accolade (que je préférerais voir supprimé ... mais c'est un problème différent #354)

Mais alors toutes les formes d'extensions possibles devraient être extensibles, pas seulement les caractères génériques, l'achèvement ex accolade (que je préférerais voir supprimé ... mais c'est un problème différent #354)

D'accord sur les deux comptes. Je me demande si les guillemets doubles devraient aussi être extensibles... echo "hello $USER" -> echo "hello dag" .

Je pense que ce dont nous parlons ici est en fait "d'évaluation" plus que "d'expansion" alors que d'un autre côté les abréviations ne concernent pas l'évaluation, donc ces idées sont probablement séparées et je vais faire un nouveau numéro pour l'autre et éditer celui-ci un peu.

Voici un prototype fonctionnel de base :

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'

Un problème que j'ai remarqué est que si vous appuyez sur Entrée pour exécuter une ligne de commande abrégée, le formulaire développé est mis en évidence comme une erreur (commande inconnue), même en incluant les arguments.

J'ai tellement aimé cela, j'ai donc mis en place un moyen de gérer ces abréviations.

En fin de compte, je pense que ceux-ci devraient être traités de la même manière que les complétions et les fonctions. Avec son propre dossier d'abréviations où il peut être enregistré.

Voici l'implémentation actuelle :

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

Ensuite tu fais quelque chose comme ça :

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

Mise à jour 1 : Ajout de la possibilité de supprimer les abréviations et de les stocker dans une variable universelle.
Mise à jour 2 : Créez également des fonctions pour les abréviations

En regardant comment fonctionnent les fonctions, nous pourrions introduire :

• abbred
• abbrsave

Ce qui serait essentiellement de cloner ces fonctions.

Joli! Cependant, je ne suis pas _tout à fait_ convaincu que nous avons besoin d'un répertoire ~/.config/fish/abbreviations et du abbr{ed,save} l'accompagne. Contrairement aux fonctions et aux complètements, ils ne sont pas vraiment lents à charger individuellement et ils n'ont besoin que d'une seule ligne pour être définis. Je pense qu'ils ressemblent plus à bind , peut-être pourrions-nous avoir une fonction fish_[user_]abbreviations comme la fonction fish_user_key_bindings , qui se charge la première fois que fish essaie de développer une abréviation ? ( [user_] par souci de cohérence mais je ne suis pas sûr que nous devrions envoyer des abréviations par défaut ?)

La seule raison à laquelle je peux penser pour avoir plusieurs fichiers pour les abréviations est si vous avez une abréviation pour chaque commande git existante et certaines avec des arguments, vous voulez donc les séparer des autres. Mais ce n'est pas ainsi que fonctionnent les fonctions de chargement paresseux et les complétions : elles sont chargées en fonction du nom de la commande, donc si nous faisions cela pour les abréviations, nous nous retrouverions avec un fichier pour chaque abréviation, chaque fichier ne contenant qu'une seule ligne de code !

Une autre idée est de faire quelque chose comme les variables universelles, peut-être même en utilisant des universelles (comme set -U fish_abbreviations ). Peut-être y a-t-il un cas d'utilisation pour les abréviations de l'hôte local ? Pas certain.

Vous avez de bons points et je penche pour la voie fish_user_abbreviations .

L'autre approche serait d'avoir des complétions similaires où vous mettez toutes les abréviations associées dans un fichier, mais cela pourrait être plus difficile à mapper.

J'avais prévu d'utiliser set -U fish_abbreviations au début, mais j'aime que la configuration soit maintenue par git, je préfère donc les définir quelque part, comme une configuration. Mais la bonne chose avec une variable universelle serait que vous pouvez ajouter des complétions à la volée sans aucun problème, comme ( abbred , abbrsave ). Faites juste un abbreviate .

Une solution serait de laisser la commande s'assurer que les abréviations sont ajoutées de manière unique et écrase celles existantes. Ensuite, il serait amorcé avec le fish_user_abbreviations et les utilisateurs peuvent en ajouter des personnalisés à la variable universelle s'ils le souhaitent.

J'ai ça en ce moment :
set -q fish_abbreviations ; or fish_user_abbreviations

Mais cela ne fonctionnera pas si je continue à maintenir le fichier.

Mise à jour de mes fonctions précédentes pour utiliser la variable universelle et ajout de la possibilité de les effacer et également de vérifier avant d'en ajouter de nouvelles si elles existent.

Je pensais le rendre plus interactif, comme demander s'il devait remplacer l'abréviation actuelle. Mais comme cela pouvait aussi être scénarisé, je ne voulais pas faire ça. Je vais me pencher sur la détermination du mode interactif.

Eh bien, voyez la chose avec les complétions, c'est que même elles sont chargées pour une seule commande. Si le processus de ligne de commande actuel est git alors completions/git.fish est chargé. Lorsque vous avez des noms de commandes séparés, vous devez créer des fichiers séparés, voir par exemple les complètements pour [ef]grep qui sont en fait dans une fonction qui est appelée à partir de chacun de ces trois fichiers de complètement.

Avec les abréviations, je ne vois aucun moyen de savoir à partir de l'abréviation quel fichier charger, à moins que le nom du fichier ne soit l'abréviation. Et puis vous ne pouvez pas avoir plusieurs abréviations dans un seul fichier. Je suppose que nous pourrions charger tous les fichiers d'abréviation au démarrage ou lors de la première tentative d'extension des abréviations, mais c'est différent de la façon dont les fonctions et les complétions sont chargées, et cela pourrait potentiellement être lent si vous avez de nombreux fichiers d'abréviation.

Nouvelle idée : abbreviate -U pour faire une abréviation universelle, et abbreviate -g ou juste abbreviate pour en faire une globale ? Si nous faisons cela, nous devrions peut-être envisager de le faire pour bind aussi...

De plus, je pense que abbreviate devrait simplement écraser toute abréviation existante, comme bind et function et set ...

Tous sont des points valides. Je pense qu'il est logique de simplement écraser comme toutes les autres fonctions le font.

J'aime aussi la suggestion avec universal et global, qui donne la flexibilité de choisir comment gérer vos abréviations/liaisons. Je ne sais pas tout à fait comment implémenter cela, et je pense que cela devrait peut-être être intégré pour améliorer les performances?

Ouais, je ne faisais que le prototyper dans les scripts de poisson pour l'essayer. Je ne veux probablement pas que des scripts lents se déclenchent à chaque fois que vous tapez un espace. :clin d'œil:

Oui, ça marche toujours très bien. Je l'utilise depuis environ 1 jour maintenant et je ne peux plus m'imaginer vivre sans, haha ​​:grin:

:rougir:

Un autre problème que j'ai remarqué est que si vous faites C-a sur une ligne de commande non vide et tapez une abréviation, elle n'est pas étendue sur l'espace puisque vous êtes au milieu d'un mot. Alors disons que vous faites make install oops besoin de root C-a ! maintenant vous avez ![cursor]make install et taper l'espace ne développe pas l'abréviation ! . Je vais essayer de contourner cela avec commandline -C .

Un troisième problème, qui pourrait être une caractéristique, est qu'il n'est développé que lorsque vous tapez un espace ou que vous entrez après une abréviation. Donc pas par exemple si vous tapez un espace alors C-a ! C-e . Cela pourrait être une fonctionnalité car cela permet d'éviter l'expansion des abréviations, mais je pense que c'est un peu bizarre et nous devrions plutôt avoir comme une commande pour exécuter une ligne de commande littéralement, un peu comme la commande command mais aussi la comptabilité pour les fonctions shell et les commandes intégrées. Ou une syntaxe spéciale, comme \g en position de commande est interprétée comme g et non développée. La syntaxe spéciale n'est pas vraiment louche non plus, mais nous avons déjà de l'espace avant la commande special case signifiant "ne pas se connecter à l'historique", alors haussez les épaules.

Quatrièmement, et celui-ci est obscur, si vous aimez dans le paragraphe précédent si vous avez une abréviation non développée suivie d'un espace, alors faites C-a et espace, l'abréviation est développée et un espace supplémentaire est inséré après ça! Encore une fois, vous devrez peut-être vérifier la position du curseur avec commandline -C .

Oh et, le premier problème que j'ai mentionné dans un commentaire précédent, cela ne se produit que si l'abréviation non développée est une commande inconnue. Ainsi, une abréviation gc développe en git commit et le tout est mis en évidence comme une erreur, en appuyant sur Entrée (sans espace), mais une abréviation gs développe en git status et met en surbrillance correctement, car apparemment j'ai installé ghostscript :

> which gs
/usr/bin/gs

Je me demande aussi si les abréviations devraient peut-être être mises en évidence comme des "commandes" connues avant même d'appuyer sur l'espace... Actuellement, si je tape g c'est rouge jusqu'à ce que je tape un espace, mais si je tape git il met en évidence comme connu avant même un espace.

Tous ces problèmes pourraient probablement être mieux traités si nous le faisons dans les parties C++.

Solution stupide pour les problèmes de coloration syntaxique : créez un alias/une fonction pour chaque abréviation. :en riant:

En fait, c'est peut-être une bonne idée de le faire de toute façon, hm... Cela signifie que les abréviations fonctionneront dans les scripts, dans eval , avec type ... Pas sûr.

Votre solution de contournement est ce que j'utilise actuellement, mais je ne sais pas si c'est ce qu'elle devrait faire à la fin, ou si elles devraient être destinées à être utilisées dans eval ou type . Pour moi, ils devraient être une chose d'entrée seulement. Mais je suppose que cela ne ferait pas de mal de les laisser également être exécutés pour obtenir un support facile pour, par exemple, sudo.

J'utilise donc l'implémentation actuelle depuis un certain temps maintenant et voici les problèmes découverts avec cette solution jusqu'à présent (ils ne sont pas liés à l'approche :+1:):

1. Lors du collage de texte, le dernier espace est inséré au début de la ligne, par exemple echo this is a test devient _echo this is atest lors du collage, où _ est un espace.
2. Lorsque vous utilisez read builtin, les liaisons sur enter et space s'appliquent là aussi. Ainsi, par exemple, si je veux saisir une commande non pour lire, elle se développera. Je suppose que dans l'implémentation finale, cela devrait être désactivé par défaut et activé par read -s
3. C'est un peu lent (~0,25-0,5 seconde)

Vous pouvez contourner 1. en collant avec C-y .

Pour moi, C-y ne colle que dans le poisson (à partir de ce qui est coupé à l'intérieur du poisson) et non à partir du presse-papiers de mon système. Copie entre terminaux ou autres applications.

Je pense que les abréviations sont une idée vraiment cool.

Je veux permettre aux gens d'expérimenter avec des abréviations pour affiner ce que devraient être les bons comportements. J'ai enregistré la prise en charge initiale des abréviations dans le maître en tant que 92099c7af23d0cebf52f89de4f9d829825e53ac8 et f9c2a77c67754324f3036ec79501c6131d19562b.

Un exemple d'utilisation :

set -U fish_user_abbreviations 'gc=git checkout'
gc

gc sera étendu à "git checkout" sur l'espace ou le retour.

Les abréviations sont une liste, donc pour en ajouter une nouvelle :

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

Les abréviations se développent en "positions de commande" (par exemple, dans des sous-shells ou en tant qu'arguments de if), mais pas en tant qu'arguments. Les abréviations ne se développent pas non plus dans les scripts.

Voici quelques problèmes non résolus à discuter :

1. "Abréviation" est longue et difficile à épeler - pouvons-nous trouver un meilleur nom ? "Alias" serait bien s'il n'était pas déjà utilisé pour d'autres choses. Une possibilité est de l'inverser, par exemple "expansion". fish_user_expansions me semble correct.
2. Comment spécifier les abréviations ? La syntaxe gc=git checkout est légère mais n'est utilisée nulle part ailleurs dans fish.
3. Nous pouvons vouloir ne pas développer sur entrer, seulement l'espace. L'expansion sur entrée a l'inconvénient que l'utilisateur ne voit pas la commande qu'il a exécutée avant de s'être engagé à l'exécuter. Si nous développons uniquement sur l'espace, les utilisateurs pourraient taper l'abréviation, suivie d'un espace, suivi d'entrée, ce qui ne semble pas trop lourd. Une deuxième possibilité consiste à faire en sorte que la première extension de déclenchement d'entrée soit exécutée et que la seconde entrée l'exécute réellement.

D'un autre côté, si toutes les abréviations sont spécifiées par l'utilisateur, alors le risque que l'utilisateur exécute quelque chose accidentellement est faible, donc étendre sur entrée peut être bien.

1. La forme développée d'une abréviation n'est qu'une substitution textuelle et n'a pas à être elle-même une commande valide. Par exemple, vous pouvez créer une abréviation qui entraîne des guillemets ou des parenthèses incompatibles. Je pense que c'est une fonctionnalité potentiellement utile, mais cela signifie que fish ne peut pas vérifier la syntaxe du code contenant des abréviations, ce qui signifie que nous ne pourrons peut-être jamais les utiliser dans des scripts.
2. L'expansion de l'abréviation elle-même doit-elle subir une expansion de sous-shell et de variable avant la substitution ? Je pense que oui, car cela les rendrait immensément flexibles. Les abréviations pourraient alors exécuter un code de poisson arbitraire.
3. Si j'appuie sur l'espace et que l'abréviation se développe et que je change d'avis, je devrais peut-être pouvoir appuyer sur supprimer et la ré-étendre.

Espérons qu'après avoir vécu avec eux pendant un certain temps, nous saurons ce qui nous convient.

Merci, je l'exécute maintenant et cela semble très bien fonctionner jusqu'à présent.

1. Nous pourrions utiliser l'abréviation abbr pour faire court. Quant à alias , si nous pensons que c'est mieux, il pourrait peut-être être remplacé par ce comportement. Si les gens veulent utiliser des alias dans leurs scripts, ils peuvent simplement faire l'encapsulation de la fonction. Les abréviations me semblent exactement ce que les gens utilisent normalement des alias.
2. Je pense qu'il serait bien d'avoir des fonctions d'aide pour définir et également supprimer les abréviations.
   Par exemple : abbr gc 'git checkout' et abbr -e gc .
   C'est un peu lourd de faire cette manipulation via la variable à mon avis. Il serait également bon de s'assurer que les abréviations sont uniques. Il vous suffit donc d'en définir un nouveau pour le mettre à jour.
3. Je préfère le comportement qui est maintenant, beaucoup de mes abréviations comme gs pour git status ne seraient pas si utiles si vous deviez appuyer sur espace. Cependant, je serais d'accord avec la double entrée pour l'exécuter comme vous l'avez mentionné.
4. Personnellement, je suis d'accord pour ne pas les utiliser dans les scripts.
5. Oui, ce serait cool. Je ne peux pas penser à une abréviation pour l'utiliser au-dessus de ma tête.
6. C'est aussi une bonne idée, si j'ai appuyé trop tôt sur l'espace pour une abréviation par exemple. Cela irait également bien avec la suggestion numéro 3 en tant que double entrée (mais je ne sais toujours pas si je veux cette entrée supplémentaire).

alias est de toute façon un wrapper de compatibilité POSIX. Je n'ai aucun problème à faire des abréviations. Si vous écrivez abbr gc 'git checkout' ou quelque chose comme ça, vous voulez de toute façon des complétions pour git checkout .

j'ai utilisé l'implémentation du script de terlar au cours des dernières semaines et je suis passé à la nouvelle version native aujourd'hui, alors voici mes deux cents sur les points ouverts

1. Je pense que ce serait une bonne idée de laisser alias faire des abréviations maintenant. En bonus, cela corrigerait les achèvements qui ne fonctionnent pas sur les alias actuels.
2. ce que dit Terlar sonne bien
3. Cela me dérangerait vraiment si je devais appuyer deux fois sur Entrée sur les abréviations pour les exécuter. Ce serait plutôt bien s'ils fonctionnent également comme des alias non développés avec une seule pression sur Entrée, mais j'ai des abréviations non développées dans mon historique
4. --
5. l'expansion des variables ne signifierait-elle pas que le contenu des variables sera mis dans la commande et donc dans votre historique ? Cela réduirait considérablement la réutilisation de telles commandes de l'historique, car elles ne contiennent plus la variable mais uniquement leur contenu antérieur. Ou ai-je mal compris ce point ?
6. Je ne me vois pas utiliser la fonction unexpand car je n'utilise pas abbreviation plus long que 3 caractères, ce qui signifie qu'ils sont tous essentiellement dans la mémoire musculaire et qu'il serait plus rapide d'effacer simplement la ligne actuelle. Cela pourrait être différent maintenant, vu que l'implémentation native peut être utilisée n'importe où et pas seulement au début de la ligne. Mais c'est probablement une bonne idée si cela ne signifie pas que je dois toujours appuyer sur espace ou appuyer deux fois sur Entrée pour les développer.

"Abréviation" est longue et difficile à épeler - pouvons-nous trouver un meilleur nom ? "Alias" serait bien s'il n'était pas déjà utilisé pour d'autres choses. Une possibilité est de l'inverser, par exemple "expansion". fish_user_expansions me semble correct.

D'accord, mais pas vendu sur "expansion".

Comment spécifier les abréviations ? La syntaxe gc=git checkout est légère mais n'est utilisée nulle part ailleurs dans fish.

Il devrait simplement s'agir d'une nouvelle fonction intégrée, tout comme complete et bind ou d'ailleurs function que l'utilisateur peut appeler mais dont le stockage sous-jacent est opaque.

Nous pouvons vouloir ne pas développer sur entrer, seulement l'espace. L'expansion sur entrée a l'inconvénient que l'utilisateur ne voit pas la commande qu'il a exécutée avant de s'être engagé à l'exécuter. Si nous développons uniquement sur l'espace, les utilisateurs pourraient taper l'abréviation, suivie d'un espace, suivi d'entrée, ce qui ne semble pas trop lourd. Une deuxième possibilité consiste à faire en sorte que la première extension de déclenchement d'entrée soit exécutée et que la seconde entrée l'exécute réellement.

Je pense vraiment que nous voulons développer Enter . J'imagine que j'aurais beaucoup de fish: Unknown command “gc” frustrants et je n'imagine pas que je serais seul dans ce cas. Cependant, l'expansion doit se produire sur la ligne de commande, avant son exécution, de sorte que vous verrez l'expansion en défilement et que c'est la forme développée qui se retrouve dans l'historique.

L'expansion de l'abréviation elle-même doit-elle subir une expansion de sous-shell et de variable avant la substitution ? Je pense que oui, car cela les rendrait immensément flexibles. Les abréviations pourraient alors exécuter un code de poisson arbitraire.

Je pense que ça ne devrait pas. Il serait généralement préférable de les développer au moment de l'exécution de la ligne de commande. Disons que j'ai une abréviation pour créer des notes horodatées. Je tape l'abréviation et un espace, et il se développe en quelque chose comme vim 12:34:56.txt . Maintenant, je n'exécute pas cette commande pendant quelques secondes et l'horodatage sera erroné. Il serait préférable que l'abréviation soit étendue à vim (time +%T).txt . Cela fait la bonne chose et signifie également que j'ai la possibilité de modifier la ligne de commande avant de l'exécuter, par exemple pour utiliser un format d'heure différent. Cela le rend également reproductible; par exemple, kill %firefox peut être rappelé de l'historique et réexécuté même lorsque le PID a changé. Enfin, je dirais que c'est plus cohérent avec le reste de fish, où les jetons sur la ligne de commande ne sont évalués qu'au moment de l'exécution.

D'un autre côté, l'évaluation au moment de l'expansion est strictement plus puissante car nous pouvons nous en désabonner avec par exemple des échappements, mais sans cela, nous ne pouvons pas vraiment _opt in_. Je pense que cela serait mieux résolu par #751, car cela donne à l'utilisateur le contrôle de l'évaluation. Cela ne fournit toujours pas un moyen d'obtenir le moment _exact_ de l'expansion de l'abréviation; ce serait le moment où l'utilisateur étendrait le jeton individuel. Néanmoins, je pense que ce serait plus utile et plus cohérent, car cela fonctionnerait non seulement avec des abréviations, mais avec n'importe quel jeton de la ligne de commande pouvant être évalué, quelle que soit la manière dont il a été ajouté à la ligne de commande.

Si j'appuie sur l'espace et que l'abréviation se développe et que je change d'avis, je devrais peut-être pouvoir appuyer sur supprimer et la ré-étendre.

Je pense que cela ne devrait pas être sur la suppression ou le retour arrière, car une partie de ma motivation pour les abréviations est la possibilité de post-éditer des _parties_ de l'extension avant l'exécution. Une meilleure idée serait peut-être d'ajouter une liaison pour "supprimer en arrière du curseur au processus actuel" tel que défini par commandline -p . Cela résoudrait le problème des abréviations (puisqu'elles ne se développent qu'en position de commande) mais en même temps serait vraiment utile sans abréviations. Cela fonctionnerait essentiellement comme Ctrl-U mais s'arrêterait au début du "processus" actuel. Une variante correspondant à Ctrl-K qui s'arrête à la _fin_ du processus en cours pourrait être ajoutée par souci de cohérence et pourrait également être utile.

Cela pourrait être différent maintenant, vu que l'implémentation native peut être utilisée n'importe où et pas seulement au début de la ligne.

Je n'ai pas essayé l' implémentation de commandline -p . En fait, je suis impressionné par le fonctionnement de mon code de preuve de concept brut ! :poisson: :coeur:

hmm suppose que je n'ai jamais vraiment essayé d'utiliser des abréviations dans d'autres positions de commande.
Oui, les prototypes ont très bien fonctionné, le seul inconvénient que j'ai eu était le problème de collage mentionné, mais la fonctionnalité était trop bonne pour ne pas l'utiliser.

@sch1zo Le collage devrait fonctionner si vous utilisez Ctrl-Y .

c'est peut-être le cas, mais la plupart du temps, je copie/colle en sélectionnant/clic du milieu et là, le problème était présent. Mais l'implémentation native n'a plus ce problème et j'ai déjà mis à jour toutes mes machines pour utiliser celle-ci.

Donc, après environ 10 jours d'utilisation des abréviations natives, j'ai trouvé une chose qui me dérange un peu. Si vous avez déjà tapé une commande, puis sautez au début de la ligne pour la faire précéder d'une abréviation, elle ne se développe pas et ne fonctionnera pas dans son état non développé. Une situation courante pour moi est la suivante :
L'un de mes abréviations est !=sudo alors maintenant, quand je veux éditer un fichier de configuration système comme dans vim /path/to/some/file/I/am/not/allowed/to/write je me rends souvent compte tard que j'ai besoin de sudo, donc je saute généralement au début et ajoute ! malheureusement, cela ne développera pas l'abréviation et me laissera un message command not found .
Ma solution de contournement actuelle consiste simplement à ajouter un alias pour l'abréviation, mais il serait préférable qu'il se développe correctement.

D'accord; nous devons regarder la position du curseur lorsque l'espace est entré, pas simplement "le premier jeton". Alternativement, insérez d'abord l'espace, puis analysez la ligne de commande et développez l'abréviation.

Commit b6f495d1077b7627ea851da33936c77b2d594bb2 devrait résoudre le problème identifié par @sch1zo (avec ! pour sudo)

Une autre chose à ajouter à cela : nous devrions probablement créer des alias ll , la et similaires par défaut au lieu de fonctions.

Je recible cela sur next-minor car cette fonctionnalité sera probablement livrée avec la prochaine version.

La prochaine version est susceptible d'être très bientôt, c'est-à-dire d'ici la fin de la semaine prochaine. Je nettoie juste la documentation pour le moment.

Les abréviations seront incluses dans leur état actuel et incomplet. Je ne veux pas les publier ou les documenter avant d'avoir la commande abbrev (ou de réutiliser alias ). Pour cette raison, je repousse cela au prochain majeur.

Je ne pense pas que alias soit un bon terme. Pour moi, un alias est un nom alternatif... pas quelque chose à développer.

Je n'aime pas non plus abbr , pour la même raison.

J'ai pensé à expand foo "foobar" ... mais il semble que la commande expand existe déjà :/ Dommage, je pense que expand aurait été le meilleur terme.

Que diriez-vous d'unifier les alias et les abréviations ? Au lieu d'introduire une nouvelle fonction ou de déprécier alias , introduisez une option de configuration pour "développer les alias". L'inconvénient ici est que nous n'aimons pas les options de configuration dans fish (mais nous pourrions éventuellement ignorer l'option de configuration) et (peut-être une bonne chose) cela signifie que nous ne pouvons pas mélanger les deux comportements bien que vous puissiez toujours écrire des fonctions normales pour obtenir l'ancien comportement des alias... L'avantage est que nous n'avons pas deux façons de faire des choses similaires, c'est facile à expliquer ("les alias se développent dans les poissons") et les abréviations fonctionneront en fait dans les scripts (car ce sont aussi des alias) qui signifie qu'ils n'ont pas non plus besoin d'être mis en casse spéciale dans le surligneur de syntaxe. Et en déplaçant la machinerie des alias vers le code C++, nous pouvons éviter la lenteur de l'implémentation actuelle des alias. Encore faut-il trouver comment faire fonctionner les complétions pour les alias non développés.

Une demande de fonctionnalité...

J'utilisais auparavant des fonctions pour émettre des combinaisons de commandes fréquemment utilisées dans une seule commande, telles que git add, git commit et git push en une seule opération.

J'adore la nouvelle fonction d'abréviation. Je pense que c'est énorme et j'essaie d'y passer. Je suis d'accord avec le fait que cela se limite à une seule extension de commande. Cependant, je veux toujours émettre plusieurs commandes en une seule fois. Maintenant, je peux simplement utiliser une abréviation pour la première commande, suivie d'un point-virgule, puis de l'abréviation pour la deuxième commande, etc. Cela fonctionne bien, en fait, je pense que c'est mieux ainsi.

Ma demande est que l'expansion soit déclenchée non seulement par espace ou entrée mais aussi par point-virgule. Étant donné que le point-virgule est fondamentalement équivalent à une entrée différée, je suppose que cela aura également du sens pour vous tous.

J'ai hâte que cette fonctionnalité soit disponible dans une version officielle !

Cela a du sens pour moi.

1a7b33e8fb75dd702730ca9637d760fbd23a4000 développe les abréviations sur les points-virgules.

Merci!

Où sont stockées les fish_user_abbreviations ? Je veux les ajouter à mon dépôt dotfiles.

C'est actuellement une variable universelle, elle est donc stockée dans ~/.config/fish/config.fish. Mais ce n'est qu'un hack temporaire jusqu'à ce que nous trouvions la bonne façon de les stocker. Les commentaires ici sont les bienvenus.

Si vous le souhaitez, vous pouvez simplement ajouter une ligne à config.fish comme set -g fish_user_abbreviations... pour le définir manuellement.

Hrm, je ne vois pas cette variable là-dedans.

J'ai utilisé set -U fish_user_abbreviations 'g=git' . Est-ce la bonne façon de l'introduire dans config.fish ?

Désolé, je voulais dire qu'il serait stocké dans ~/.config/fish/fishd.[mac_address] . Évidemment, la synchronisation ne fonctionnera pas (par conception) car elle est désactivée sur le MAC.

Pour le mettre dans config.fish, vous écririez `set -g fish_user_abbreviations 'g=git'. -g pour global, puisque vous le définissez à chaque fois.

Je pense que la variable universelle est raisonnablement soignée, elle a juste besoin d'une meilleure interface utilisateur qui l'entoure.

Si nous l'utilisons comme un tableau, soit avec = pour diviser les clés et les valeurs, soit en ASCII FS ( \x1c ), alors une fonction fish pour le gérer ( abbr ) + /- une page d'interface web serait utile.

Il faudrait réfléchir à la production d'une production appropriée pour l'exportation/le transfert.

@ridiculousfish Ahh, merci, c'est très utile ! Je le ferai pour l'instant jusqu'à ce qu'il y ait un processus d'exportation.

Btw, je suis neutre pour avoir soit A) un seul fichier avec toutes les abréviations ou B) un fichier séparé pour chaque abréviation. Peut-être penché vers A mais pas fortement.

J'ai ajouté une interface utilisateur de base autour de l'implémentation existante en tant que abbr - utilisez abbr -h pour en voir plus. J'ai également ajouté une interface utilisateur en lecture seule à l'interface Web, mais ce serait bien que cela fasse plus.

Au lieu d'utiliser = comme séparateur, nous pourrions simplement utiliser le premier jeton (séparé par des espaces ?) de chaque élément du tableau - cela simplifierait l'implémentation.

La variable universelle est intéressante, mais si nous ne l'exposons pas directement, il serait peut-être préférable de la déplacer vers __fish_user_abbreviations (et éventuellement d'avertir de la définir à un niveau local ou global).

Je préférerais space-separated au lieu d'utiliser = comme séparateur. D'autant plus que ce style n'est utilisé nulle part ailleurs dans fish .

Je suis d'accord que cela devrait être séparé par des espaces. Cela a un peu plus de sens, et cela signifie que = pourrait en fait faire partie de l'abréviation si vous le souhaitez. La commande abbr devrait probablement être modifiée pour supprimer le drapeau --add et prendre simplement deux arguments à la place.

En ce qui concerne $__fish_user_abbreviations , je peux sympathiser avec cette suggestion, mais il est plausible que les utilisateurs veuillent modifier eux-mêmes $fish_user_abbreviations sans utiliser la commande abbr , et je préfère ne pas encourager à quiconque de modifier directement une variable $__fish_* . De même, la situer au niveau local ou global est parfaitement légitime ; tout le monde ne veut pas utiliser des variables universelles pour ce genre de choses.

Sur une note connexe, read devrait probablement développer les abréviations sur la saisie interactive lors de l'utilisation du drapeau --shell .

Mon souci d'encourager la modification de la variable en dehors de la commande abbr est que l'extension de la commande pour prendre en charge la portée augmente sa complexité en termes d'interface utilisateur, mais ne pas le faire conduit à des résultats potentiellement trompeurs. Il n'y a pas de fusion des étendues de variables à l'heure actuelle, ce qui pourrait être déroutant - si vous définissez une expansion universelle et une expansion globale (différente), devraient-elles toutes les deux fonctionner ? Comment désamorcer une expansion universelle dans la portée mondiale, alors ? Est-ce quelque chose que les gens voudraient faire un jour ?

La séparation de l'espace semble être une bonne idée. Afin d'éviter toute confusion, l'ajout d'une nouvelle abréviation devrait probablement prendre un nombre illimité d'arguments, le premier devenant le « mot » et le reste réuni pour devenir la « phrase ».

Il n'y a aucun besoin de faire des travaux pour "soutenir la portée". Si abbr utilise simplement $fish_user_abbreviations , il utilisera la variable globale si elle est présente, ou l'universelle sinon. C'est exactement ainsi que fonctionne le lecteur. Le seul problème est que si l'utilisateur définit $fish_user_abbreviations comme variable locale au niveau supérieur, le lecteur le verra également. Et la solution simple est d'ajouter le -S drapeau à abbr déclaration de fonction, ce qui laisser voir les variables locales définies dans son parent. Mais il n'est certainement pas nécessaire d'essayer de fusionner les abréviations (ni aucun moyen de le faire, à moins de supprimer temporairement la variable à d'autres portées).

Après avoir vécu cela, je pense que j'aimerais que les abréviations soient soulignées ou mises en évidence différemment, avant qu'elles ne soient développées. Cela me donne une certaine confiance que je les ai tapés correctement. Les pensées?

La prise en charge du séparateur d'espace est dans fbade198b942a666d3fc1110804a7da2c47918f1

Si vous appuyez sur l'espace et qu'il ne se développe pas, vous savez que vous ne l'avez pas tapé correctement. Je ne suis pas opposé au soulignement ou au surlignage (ce serait certainement un indice supplémentaire pour faire savoir à l'utilisateur pourquoi sa ligne de commande vient de changer), mais je ne suis pas sûr de comprendre pourquoi vous devez avoir confiance avant d'atteindre l'espace.

@ridiculousfish Concernant fbade198b942a666d3fc1110804a7da2c47918f1, les abréviations sont suffisamment nouvelles (et non documentées jusqu'à un master récent) pour que nous devions simplement supprimer le support = .

Je pense au cas avant le retour, pas au cas avant l'espace

Cela me semble bien. Je suppose qu'il _est_ possible d'aller trop loin avec la mise en évidence, ce qui entraîne une lenteur et une surcharge d'informations désorientantes, mais je ne pense pas que ce soit le cas ici. De plus, je suppose qu'il utiliserait une variable $fish_color_abbr-or-whatever afin qu'il puisse facilement être désactivé par ceux qui le souhaitent, pour une raison quelconque.

Au début, j'allais faire remarquer que je trouvais peu intuitif que le comportement de surbrillance soit différent pour les abréviations par rapport aux commandes normales, jusqu'à ce que je réalise que j'étais incorrect et qu'il est cohérent.

Ma confusion venait du fait que je mélangeais le surlignage et la fonction de complétion suggérée.

Par exemple, lorsque je tape "echo", la surbrillance est rouge jusqu'à ce que je tape la commande complète, ce qui est normal. Cependant, l'achèvement suggéré anticipe avec succès ce que j'étais sur le point de taper et me donne l'assurance que je me dirige dans la direction prévue.

Je ne reçois pas de tels retours pour les abréviations, ce qui est regrettable car je ne peux pas souvent proposer de raccourcis mémorables de commandes, en particulier ceux qui s'étendent à des commandes complexes.

En fait, l'objectif pour moi est de regrouper un large éventail de commandes dans un petit espace de noms (je tire pour environ 5 abréviations de caractères et j'en ai des centaines). Pour cette raison, je m'appuie encore plus sur les conseils du shell que je me dirige vers la saisie d'une commande valide. Quelque chose qui remplit le rôle occupé par la complétion suggérée, mais pour les abréviations au lieu des commandes régulières, serait vraiment utile, plus que pour les commandes standard, même pour moi.

Je peux voir la difficulté pour les complétions suggérées posées par les abréviations. Il ne serait pas intuitif que l'abréviation se développe dans les commandes réelles car elle ne serait plus contiguë à ce que vous tapez. Pourtant, j'ai l'impression que ça pourrait être mieux qu'aujourd'hui.

Au moins pour moi, inclure l'abréviation elle-même (pas l'extension) dans les achèvements suggérés me gratterait la démangeaison. Je veux juste voir que je tape correctement un préfixe d'une abréviation définie. Cela suffit pour me dire que je ne tape pas en vain parce que je me suis mal souvenu ou que j'ai mal tapé mon abréviation.

J'ai essayé d'étendre abbr.fish pour gérer à la fois les espaces et les séparateurs = , mais je n'ai pas eu beaucoup de succès à proposer une solution robuste sans recourir à des outils externes.

Je pensais que le plan était de supprimer le support = ? Je pensais juste le faire, puis poster un message sur la liste de diffusion de fish avec un script qui mung $fish_user_abbreviations que les gens pourraient exécuter pour passer aux espaces.

Salut les gars,

Je voulais faire une note après avoir utilisé des abréviations depuis un certain temps maintenant.

Je suis un grand fan, et ils me facilitent la vie. J'aime particulièrement le fait que d'autres personnes puissent voir les commandes que je lance, sous une forme familière.

Mon seul aversion est qu'il n'y a pas d'historique pour les abréviations. Depuis que j'utilise des abréviations pour presque toutes les commandes, cela m'a fait perdre la plupart des fonctionnalités d'historique. Bien que vous puissiez penser que les abréviations devraient être suffisamment courtes pour ne pas avoir besoin de fonctionnalité d'historique, cela me manque un peu. J'ai défini plus de 200 abréviations, et certaines d'entre elles ne diffèrent que légèrement. Que l'histoire me montre celle que j'ai publiée hier, par exemple, serait extrêmement utile pour les abréviations les plus complexes et les moins fréquemment utilisées. Comme je vis pratiquement avec des abréviations, j'ai dû recourir à des fonctions à la place où j'ai besoin d'un support d'historique car je n'ai vraiment pas d'historique autrement.

Merci encore pour la fonctionnalité.

@binaryphile Très intéressant. Il semble que vous ayez une idée en tête de ce à quoi cela devrait ressembler (c'est-à-dire l'interface utilisateur). Souhaitez-vous le décrire plus en détail?

Bonne question. Je suppose que j'aimerais juste que si une extension était déclenchée, l'abréviation devrait entrer dans la liste de l'historique. Donc, si mon abréviation était "gclon" pour "git clone", alors lorsque j'appuierais sur l'espace (ou le point-virgule), "gclon" serait ajouté à mon historique. Je ne modifierais pas le comportement normal de stockage de la commande étendue dans l'historique, donc les deux seraient disponibles.

Après cela, lorsque j'ai commencé à taper un préfixe de l'abréviation (comme "gcl"), je m'attendrais à ce que "gclon" soit la première option pour l'auto-complétion à apparaître.

Idéalement, à ce stade, je serais en mesure d'appuyer sur alt-f et de le terminer automatiquement vers la version étendue, ainsi que d'offrir une nouvelle autocomplétion de cette commande étendue à partir de l'historique. Je le voudrais parce que j'ai peut-être entré d'autres arguments après l'expansion, et je voudrais les avoir disponibles en aussi peu de frappes que possible via le même itinéraire que je l'ai entré en premier lieu (abréviation puis arguments). Étant donné que l'abréviation dans l'historique n'aurait pas les arguments, alt-f serait la méthode la plus naturelle pour moi d'aller plus loin dans la complétion argument par argument.

Je pense que ctrl-f ne changerait pas et avancerait simplement jusqu'à la fin de l'abréviation, pas la version étendue, car il n'y aurait aucun repère visuel quant à ce que vous développeriez.

Je viens de recevoir une compilation nocturne pour enfin tester cela ! J'aime vraiment cette fonctionnalité et j'adore le fait qu'elle a la commande abbr qui l'accompagne.

Mes commentaires sont que nous avons besoin d'un bon moyen d'exporter pour la sauvegarde dotfile. Je pense que ceux-ci devraient tous aller dans un seul fichier au format abbr --show sorties. abbr --show est assez bon pour moi pour l'instant, je vais juste les diriger dans un fichier dot pour l'instant. Mais je veux un moyen facile de les importer à nouveau le moment venu. Donc, si Fish pouvait importer ce format maintenant, ce serait une bonne prochaine étape.

Suivre la commande dans l'aide pour ajouter une nouvelle abréviation échoue avec cette erreur.

Actuellement, vous devez entrer abbr -a "gco git checkout" mais je pense qu'il serait plus logique de prendre en charge le cas décrit dans le manuel.

Ahhh, merci !

48d3536 effectue ce changement.

Je pense que nous devrions soit laisser le support du séparateur '=' dans la prochaine version mineure et le désactiver après cela, soit (silencieusement?) mettre à niveau le fish_user_abbreviations .

Je vais fermer ceci comme corrigé ; J'ai déposé #2051 pour suivre la migration. Un grand merci à @dag pour le concept et à tous ceux qui l'ont testé - hâte de le voir sortir bientôt !

W00t, merci à tous, j'adore vraiment cette fonctionnalité !!

J'adore les abréviations, c'est une expérience beaucoup plus conviviale que les pseudonymes. Merci beaucoup!

Je suis tombé sur ce fil en cherchant comment stocker les abréviations dans les fichiers dotfiles ^{1 , 2} .
Si quelqu'un trébuche ici pour la même raison, vous pouvez utiliser abbr -s/--show . Par exemple

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

@dideler J'utilise quelque chose de similaire à celui pour la sauvegarde automatisée, je recommande également de diriger vers sort .

abbr --show | sort > fish_abbreviation_backup;

J'ai tout mis dans un fichier fish_abbreviation_backup, puis l'ai ajouté à Homeshick pour la sauvegarde. Tout est automatisé et fonctionne sur cron. Après avoir sauvegardé, je source fish_abbreviation_backup pour que le poisson affiche l'ordre alphabétique lors d'un abbr --show .

Ce serait bien si fish conservait les abréviations dans un fichier, de la même manière qu'il fait les choses avec les fonctions.

mise à jour : problème pour trier les abréviations lors de leur stockage -> https://github.com/fish-shell/fish-shell/issues/2156

Ce serait bien si les poissons conservaient les abréviations dans un fichier...

À partir de la page de manuel : "Les abréviations sont stockées à l'aide de variables universelles." Ce qui signifie que vous les trouverez dans le fichier _~/.config/fish/fishd.macaddr_ sous le nom de var fish_user_abbreviations . La commande abbr manipule simplement cette variable universelle.

Merci, serait-il bon d'envisager l'idée de les conserver dans ~/.config/fish/abbreviations.fish afin que nous puissions les ajouter facilement à nos fichiers dotfiles ?

@ElijahLynn : Ce que je fais, c'est que j'ai un fichier appelé "abbrs.fish" dans ~/.config/fish/conf.d/, avec le contenu suivant :

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

Je l'ai dans mes dotfiles , et je peux simplement le déposer sur n'importe quelle machine sur laquelle je ne l'ai pas encore utilisé, et si je veux réinitialiser les abbrs, je peux tous les effacer (je fais set -e fish_user_abbreviations; set -e fish_initialized ) et redémarrer le poisson.

Merci, cela me manque peut-être, mais il semble que vous ayez besoin de le maintenir manuellement et que vous ne puissiez pas les ajouter facilement avec la commande abbr .

Vous y ajoutez la commande abbr. Cela peut même être la sortie d'un appel abbr --show .

Seulement en position de commandement est probablement un bon début. Ensuite, nous pouvons peut-être expérimenter les cas d'utilisation de position d'argument que j'ai suggérés auparavant.

Je pense que non seulement une position au départ serait utile, par exemple : s pour sudo et n pour nano qui peut s'étendre à partir de s n à sudo nano , mais pas dans l'implémentation actuelle.