LiquidPrompt version 1.3

Posté par (page perso) . Édité par Lucas Bonnet. Modéré par Christophe Guilloux. Licence CC by-sa
36
12
mar.
2013
Ligne de commande

LiquidPrompt est un prompt clefs-en-main pour bash ou zsh, dont l'idée générale est d'afficher élégamment des informations utiles uniquement quand le contexte le demande.

Le rythme des linuxfrisations s'est fait moins frénétique (il va falloir songer à aller glaner des utilisateurs ailleurs…) mais cette version apporte néanmoins son lot de bonnes idées, jugez plutôt :

  • ma préférée : lorsque vous êtes dans un multiplexeur de terminal (screen ou tmux), les crochets se colorent en bleu…
  • … et le prompt peut être utilisé comme titre de fenêtre de screen ;
  • support de Bazaar ;
  • une option pour désactiver les VCS sur certains répertoires (par exemple si vous avez des dépôts SVN montés via le réseau, vous avez envie de les désactiver, si si) ;
  • sous git, un + jaune apparait si vous avez au moins un stash ;
  • ajoute une fonction prompt_tag pour ajouter facilement un mot clef (ou ce que vous voulez) en tête de prompt ;
  • des bugfix de portabilité et des améliorations de rapidité.

Pour les amateurs, la branche develop dispose d'une option (en beta) permettant d'utiliser une couleur différente pour des hôtes différents, lors de connexion SSH (telnet restant en rouge gras).

  • # Mieux !

    Posté par (page perso) . Évalué à 2.

    C'est bien mieux et plus rapide que la dernière fois que j'avais testé.
    Par contre moi j'aime bien avoir un prompt sur deux lignes…comme ça je peux avoir le chemin en entier sur la première ligne. Est-ce possible comme évolution/option ?
    En tout cas je suis assez satisfait du résultat, c'est assez réactif cette fois (testé sous Bash).
    Bravo.

    • [^] # Re: Mieux !

      Posté par . Évalué à 2.

      Je viens d'essayer (pour la première fois, donc je ne peux pas comparer) sur un Raspberry Pi, avec la config par défaut et c'est un poil lourdeau. Je dois bien mettre une demi-seconde à récupérer le curseur lorsque j'envoie une commande vide (juste "entrée") dans un dépôt git. C'est moins lent lorsque je suis hors du dépôt git, mais pas instantané.

      C'est sympa d'avoir certaines infos (branche) mais en effet ça fait une ligne super longue. Trop, je trouve.

      J'ai conscience que ceci est juste un retour sur la config par défaut. Je n'ai pas essayé de la modifier.

      • [^] # Re: Mieux !

        Posté par . Évalué à 2.

        Essaye de désactiver tous les gestionnaires de version, ils font explorer l'arborescence à chaque commande.

        • [^] # Re: Mieux !

          Posté par . Évalué à 1.

          A vue de nez, en désactivant la prise en charge des gestionnaires de version, ça fait comme quand je suis dans un répertoire non versionné, à savoir que c'est plus rapide, mais quand même pas instantané comme quand je n'utilise pas liquidprompt.

          Le RPi c'est pas une foudre de guerre, il faut bien le reconnaître.

      • [^] # Re: Mieux !

        Posté par (page perso) . Évalué à 2.

        Ça n'est clairement pas fait pour un RPi… ceci étant dit, un prompt de base n'est pas non plus fait pour une bête de course :-)

        Tu peux réduire de beaucoup le temps d'exécution en jouant avec les variables LP_ENABLE_* ou en virant des fonctionnalités dans ton propre LP_PS1 (cf. la doc).

        • [^] # Re: Mieux !

          Posté par . Évalué à 1.

          Ça n'est clairement pas fait pour un RPi…

          D'accord. C'était un peu l'objet de mon commentaire.

          Tu peux réduire de beaucoup le temps d'exécution en jouant avec les variables LP_ENABLE_* ou en virant des fonctionnalités dans ton propre LP_PS1 (cf. la doc).

          OK, merci. Si j'ai le temps et si j'en ressens le besoin, j'y regarderai.

    • [^] # Re: Mieux !

      Posté par (page perso) . Évalué à 1.

      un prompt sur deux lignes…
      comme ça je peux avoir le chemin en entier sur la première ligne.
      Est-ce possible comme évolution/option ?

      Pas pour le thème par défaut.

      Mais tu peux tout à fait configurer le liquid prompt différemment, sans toucher au code.
      Le plus simple est sans doute d'utiliser "]\n" pour LP_MARK_BRACKET_CLOSE, mais tu peux régler le prompt encore plus finement en utilisant ton propre LP_PS1. La doc explique tout ça avec des exemples, voir aussi les fichiers liquid.ps1 et liquid.theme.

  • # Shell graphique

    Posté par . Évalué à 3.

    J'avais vu une fois un projet d'extension graphique de shell, qui affichait des icônes, des liens… Je n'arrive plus à retrouver. Quelqu'un se souvient ?

  • # Support Git

    Posté par . Évalué à 2.

    Est-ce que quelqu'un sait s'il est possible d'avoir les informations de décalage par rapport à l'upstream ?
    Dans git-completion.bash (qui fait bash et zsh), j'ai cette information via GIT_PS1_SHOWUPSTREAM (verbose).
    Merci.

    # If you would like to see the difference between HEAD and its
    #       upstream, set GIT_PS1_SHOWUPSTREAM="auto".  A "<" indicates
    #       you are behind, ">" indicates you are ahead, and "<>"
    #       indicates you have diverged.  You can further control
    #       behaviour by setting GIT_PS1_SHOWUPSTREAM to a space-separated
    #       list of values:
    #           verbose       show number of commits ahead/behind (+/-) upstream
    #           legacy        don't use the '--count' option available in recent
    #                         versions of git-rev-list
    #           git           always compare HEAD to @{upstream}
    #           svn           always compare HEAD to your SVN upstream
    #       By default, __git_ps1 will compare HEAD to your SVN upstream
    #       if it can find one, or @{upstream} otherwise.  Once you have
    #       set GIT_PS1_SHOWUPSTREAM, you can override it on a
    #       per-repository basis by setting the bash.showUpstream config
    #       variable.
    
    
    • [^] # Re: Support Git

      Posté par (page perso) . Évalué à 1.

      J'aime bien l'idée, même si ça doit ramer à mort… tu nous fais une demande de fonctionnalité ?
      https://github.com/nojhan/liquidprompt/issues/new :-)

    • [^] # Re: Support Git

      Posté par . Évalué à 5.

      Avec ce genre de fonctionalité tu vas vite arriver aux limites du design actuel à cause du coup des opérations à refaire et non facilement mutualisables. Les VCS donnant déjà chaud à la machine (très assez visible dans les environements avec peu de cache disque).

      Je pense que c'est envisageable mais qu'il faut d'une part viser à mutualiser les opérations entre les différents shells et d'autre part viser l'eventual consistency. Nojhan si le nombre de fonctionalités explose t'as déjà pensé à sortir les traitements dans un daemon qui pourrait à la fois mutualiser les calculs, avoir l'opportunité de faire les choses un peu plus intelligement que brute forcer et assurer une bonne interactivité  ?

      • [^] # Re: Support Git

        Posté par . Évalué à 2.

        En tout honnêteté sur mon laptop (un t410), j'ai pas noté de ralentissement à l'usage de cette fonctionnalité.
        Après mes dépôts Git sont petits (c'est en général des petits projets personnels) , il faudrait sans doute demander à quelqu'un qui a un usage plus poussé de Git pour voir.
        Après, quand j'ai regardé un peu pour bash_completion, j'ai pas vue de gens qui se plaignait …

        • [^] # Re: Support Git

          Posté par . Évalué à 5. Dernière modification le 12/03/13 à 20:25.

          Git est extrêmment rapide et tu n'auras pas de problème à partir du moment où ton cache disque est suffisant (l'OS n'as pas à accéder au disque au cours de l'exécution de ca).

          Tu peux avoir des problèmes pour deux raisons:

          • Un VCS plus lent. Bzr est un bon exemple, il a un temps de démarrage significatif et inévitable qui se ressent très vite. Une commande passe, deux tu sens déjà une perte de réactivité
          • Une station limite en RAM qui empêche le système de cacher les pages. Là tu peux prendre des blocages de quelques secondes. Plus t'es IO sont mauvais (VM) plus c'est sensible. J'ai pas mal ce cas au taff où je me balade dans beaucoup beaucoup de repo utilisant 4 VCS différents. Là tout les VCS sont impactés.

          Après dès que tu fais une opération remote tu rentres dans un autre mode côté latence et robustesse. C'était le sens de ma remarque.

  • # Cache

    Posté par (page perso) . Évalué à 2.

    Vu les commentaires précédents, il semble que LiquidPrompt recalcule à chaque fois tout ce qu'il affiche, notamment les informations de gestion de version. Ces informations ne changeant que si on sort du répertoire — et pas si on s'enfonce plus loin — ne serait-il pas possible de les cacher, pour ne recalculer tout ça que lorsque c'est nécessaire, donc lorsqu'on remonte dans les répertoires au-delà du répertoire où le système de gestion de version a été découvert ?

    • [^] # Re: Cache

      Posté par . Évalué à 8.

      Ce que tu dis est faux. Tu es obligé de rafraichir tes informations à chaque fois car tu as de la concurrence, le monde bouge autours de toi et le seul moyen de t'en rendre compte est de demander. Un fichier peut avoir été édité, un commit à pu être fait dans un autre shell etc. Chaque shell doit donc rafraichir sa vue en permanence pour fournir des informations à jour…

      Il me semble qu'il y a eu un joli refactoring sur les VCS qui a pas mal améilloré les perfs (au départ on invoquait deux fois chaque VCS). Mais optimiser ce fonctionnement n'est pas trivial et peut vite devenir très complexe à gérer, surtout dans le contexte de processus indépendants.

      • [^] # Re: Cache

        Posté par . Évalué à 1.

        Y aurait-il moyen d'observer les modifications de certains fichiers clés du VCS et de ne recalculer les informations qu'au cas où un de ces fichiers a été modifié ? Pour certains VCS (Bzr ?) on pourrait éliminer une bonne partie des commandes.

        • [^] # Re: Cache

          Posté par . Évalué à 3. Dernière modification le 12/03/13 à 23:58.

          Dans ce sens tu vas vite te retrouver à recoder le VCS simple… Simplement par ce que le VCS lui même ne découvre qu'on est dirty qu'au moment ou on le lance. La seule optim facile est l'inverse. Si absolument rien n'a changé dans l'arbo alors l'état ne peut pas avoir changé et ca ne sert à rien de mettre à jour l'état. Mais pour savoir si c'est un cas fréquent il n'y a qu'une facon de le savoir: faire des mesures.

          Mais il faut garder à l'esprit qu'actuellement tout repose PROMPT_COMMAND qui pointe sur un script shell… D'où ma question de savoir si ce design est adapté si l'outil est destiner à gagner en fonctionalités.

      • [^] # Re: Cache

        Posté par . Évalué à 3.

        Ce que tu dis est faux. Tu es obligé de rafraichir tes informations à chaque fois car tu as de la concurrence, le monde bouge autours de toi et le seul moyen de t'en rendre compte est de demander. Un fichier peut avoir été édité, un commit à pu être fait dans un autre shell etc. Chaque shell doit donc rafraichir sa vue en permanence pour fournir des informations à jour…

        Je n'utilise pas liquidprompt parce que je n'ai pas besoin d'avoir autant d'informations dans mon prompt* (et que mon miens actuel me convient), mais il doit être possible de s'appuyer sur inotify. Cerise sur le gâteau zsh possède une fonctionnalité pour mettre à jour le prompt à chaud (en le ré-affichant), ça permettrait dans un shell sans aucune commande d'être notifié des évolutions (changement de branche locale, etc) sans interventions de l'utilisateur.

        * : et aussi parce que j'utilise zsh et que ça me semble contre productif d'afficher des infos de vcs autrement que par vcs_info (exemples).

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # et comment tu fais après pour construire des bâtiments ?

    Posté par . Évalué à 3.

    une option pour désactiver les VCS

    le jour de la sortie de HotS c'est juste de la provocation. :-)

  • # Powerline

    Posté par (page perso) . Évalué à 5.

    Dans le même genre, il y a Powerline.

    Il est né pour améliorer la status bar de vim, et propose maintenant une status bar pour bash/zsh, tmux, …

    Il nécessite des polices "patchées", par contre.

  • # Pour les Archers...

    Posté par . Évalué à 4.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.