LiquidPrompt version 1.3

Posté par nojhan (site web personnel, Mastodon) le 12 mars 2013 à 13:51. Édité par Lucas Bonnet. Modéré par rootix. Licence CC By‑SA.

Étiquettes :

mar.

2013

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).

Aller plus loin

Code sur github (421 clics)
Capture d'écran (1785 clics)
Documentation (334 clics)

# Mieux !

Posté par Cyrille Pontvieux (site web personnel, Mastodon) le 12 mars 2013 à 15:56. É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 jihele le 12 mars 2013 à 16:12. É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 oao le 12 mars 2013 à 17:42. Évalué à 2.
    
    Essaye de désactiver tous les gestionnaires de version, ils font explorer l'arborescence à chaque commande.
    - [^] # Re: Mieux !
      
      Posté par jihele le 12 mars 2013 à 17:49. É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 nojhan (site web personnel, Mastodon) le 12 mars 2013 à 17:49. É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 jihele le 12 mars 2013 à 18:10. É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 nojhan (site web personnel, Mastodon) le 12 mars 2013 à 17:47. É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 JGO le 12 mars 2013 à 16:29. É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 ?
- [^] # Re: Shell graphique
  
  Posté par nojhan (site web personnel, Mastodon) le 12 mars 2013 à 17:51. Évalué à 3.
  
  TermKit : http://acko.net/blog/on-termkit/
  - [^] # Re: Shell graphique
    
    Posté par gautami le 12 mars 2013 à 19:28. Évalué à 1.
    
    Projet splendide mais apparemment mort :-(
    - [^] # Re: Shell graphique
      
      Posté par nojhan (site web personnel, Mastodon) le 12 mars 2013 à 19:33. Évalué à 2.
      
      Dernier commit voilà 4 mois… pour moi ça n'est pas assez long pour déclarer une mort clinique…
      - [^] # Re: Shell graphique
        
        Posté par gautami le 12 mars 2013 à 20:07. Évalué à 1.
        
        J'ai aussi regardé sur le blog s'il y avait de nouveaux billets, fait un pull request et un rapport de bug. J'espère donc aussi qu'une réanimation reste possible :)
    - [^] # Re: Shell graphique
      
      Posté par Quentin Pradet le 15 mars 2013 à 09:28. Évalué à 2.
      
      L'auteur a exposé la situation sur reddit, et il a en gros perdu foi en un développement ouvert.
# Support Git

Posté par sifu le 12 mars 2013 à 17:32. É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 nojhan (site web personnel, Mastodon) le 12 mars 2013 à 17:52. É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 sifu le 12 mars 2013 à 20:17. Évalué à 1.
    
    C'est fait ;)
- [^] # Re: Support Git
  
  Posté par ckyl le 12 mars 2013 à 19:16. É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 sifu le 12 mars 2013 à 20:10. É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 ckyl le 12 mars 2013 à 20:23. Évalué à 5. Dernière modification le 12 mars 2013 à 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 🚲 Tanguy Ortolo (site web personnel) le 12 mars 2013 à 19:51. É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 ckyl le 12 mars 2013 à 20:02. É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 ziliss le 12 mars 2013 à 23:02. É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 ckyl le 12 mars 2013 à 23:57. Évalué à 3. Dernière modification le 12 mars 2013 à 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 barmic le 15 mars 2013 à 10:50. É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 DerekSagan le 12 mars 2013 à 19:57. É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 Tof le 12 mars 2013 à 22:31. É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 JPEC le 14 mars 2013 à 21:15. Évalué à 4.

J'ai fait un package AUR :
https://aur.archlinux.org/packages/liquidprompt-git/

Suivre le flux des commentaires

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