J'ai essayé ddd, insight, nemiver, kdevelop, eclipse et cgdb.
Et au final je préfère gdb tout seul. Il faut passer par la case apprentissage, mais on est gagnant au final (comme souvent avec les outils en ligne de commande).
J'étais utilisateur de cgdb moi aussi. Mais il ne propose que la coloration syntaxique de la fenêtre de code (permanente), pas la coloration des sorties des commandes (le hack présenté faisant les deux).
Par contre, cgdb ne semble pas gérer les couleurs dans son interface curses, j'ai essayé un prompt coloré et les caractères d'échappement ne sont pas interprétés.
Du coup, j'ai abandonné cgdb au profit d'un gdb standard où j'ai ajouté la commande list à chaque arrêt (ce qui est du coup très similaire à la fenêtre de code permanente).
J'ai vu fonctionner kakoune, un éditeur de texte très inspiré de vim, et c'est vraiment pas mal.
Les killers features que j'aime bien sont la grammaire dans le bon ordre (« sélection, puis action », alors que vim fait « action, puis sélection ») et le remplacement d'un langage de script par un petit système d'exposition des variables (ce qui fait que vous pouvez utiliser le langage que vous voulez, par exemple bash).
Il y a notamment pas mal de trucs que neovim veux implémenter, mais qui, là, sont déjà faites. Et c'est en… C++11.
En trois mots :
- en WYSIWY G, on voit exactement ce qui apparaîtra dans le navigateur, on ne voit pas le code.
- dans un éditeur de texte, on voit le code uniquement et pas le rendu.
- avec WYSIWY M, on ne voit pas le code, ni le rendu final, mais une mise en forme qui porte le sens. Typiquement, on ne verra pas les balises, H1 sera en gros et gras, mais pas dans les couleurs du CSS du site final.
De ce que j'ai compris en regardant Bracket, c'est un éditeur de texte avec une mise à jour du rendu en temps réel, mais ce qu'on voit, c'est le code source, directement.
Bracket n'est donc pas WYSIWYM.
On pourra comparer avec WYMeditor, qui me parait être un éditeur HTML plus dans l'esprit WYSIWYM.
Ces deux projets ne font pas vraiment la même chose. Oh-my-zsh vise plus large, il cherche à configurer l'intégralité du shell.
On pourrait tout à fait faire un module Oh-my-zsh avec liquidprompt.
En l'état il n'y a pas d'équivalent aussi intégré et dynamique dans Oh-my-zsh, qui propose surtout (enfin, la dernière fois que j'ai regardé, voilà un an ou deux) des prompts peu contextualisés et très mis en forme.
L'exemple le plus frappant est la lecture d'une sortie très verbeuse, comme par exemple la sortie de gcc.
Tu ne veux pas filtrer avec grep parce que tu peux avoir besoin de tout lire. Par contre il est pratique de pouvoir repérer très rapidement les passages qui t'intéressent (les erreurs, par exemple). Les couleurs sont un moyen très efficace de faire ça.
C'est pour ça que j'ai commencé à faire colout, mais je me suis assez vite rendu compte que le problème se posait aussi pour plein d'autres choses (diff, logs) et même dans des cas où j'utilisais grep habituellement (grep de code source, par exemple).
On peut se dépatouiller avec grep ou d'autres commandes dédiées (git coloré, colordiff, ccze, etc.) dans la plupart de ces cas mais je me suis vite rendu compte qu'il était très pratique d'avoir une seule commande bien pensée pour remplacer plein de façon disparates de faire moins bien.
Je ne suis pas sûr d'avoir bien compris à quoi ça servait, même si ça à l'air cool…
Est-ce que ça pourrait m'aider à faire une translitération "inverse" : d'une représentation multi-caractères latins vers de l'unicode ? (notamment vers du cunéiforme ?)
Ç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).
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.
Il faut passer par le réseau pour voir l'écart avec un dépôt distant… je ne suis pas sûr que ça soit très rapide… et se reposer sur un fetch de l'utilisateur n'est pas très ergonomique. Le module git_ps1 est rapide, parce qu'il n'est pas en bash, je suppose ? Peut-être qu'on pourrait parser sa sortie au lieu de passer par des appels systèmes ?
Le prompt affiche le nombres de lignes en plus/moins des modifications non commitées en rouge, le nombre de commits non pushés en jaune.
Récupérer à chaque affichage le retard sur pull serait bien trop lent pour le prompt. Mais on peut peut-être envisager un job en arrière plan et un cache…
[^] # Re: bonne idée
Posté par nojhan (site web personnel, Mastodon) . En réponse à la dépêche Utiliser colout pour colorier tout ce qu'affiche GDB. Évalué à 3.
J'ai essayé ddd, insight, nemiver, kdevelop, eclipse et cgdb.
Et au final je préfère gdb tout seul. Il faut passer par la case apprentissage, mais on est gagnant au final (comme souvent avec les outils en ligne de commande).
[^] # Re: cgdb
Posté par nojhan (site web personnel, Mastodon) . En réponse à la dépêche Utiliser colout pour colorier tout ce qu'affiche GDB. Évalué à 3.
J'étais utilisateur de cgdb moi aussi. Mais il ne propose que la coloration syntaxique de la fenêtre de code (permanente), pas la coloration des sorties des commandes (le hack présenté faisant les deux).
Par contre, cgdb ne semble pas gérer les couleurs dans son interface curses, j'ai essayé un prompt coloré et les caractères d'échappement ne sont pas interprétés.
Du coup, j'ai abandonné cgdb au profit d'un gdb standard où j'ai ajouté la commande
list
à chaque arrêt (ce qui est du coup très similaire à la fenêtre de code permanente).[^] # Re: GDB
Posté par nojhan (site web personnel, Mastodon) . En réponse à la dépêche Utiliser colout pour colorier tout ce qu'affiche GDB. Évalué à 1.
Tant qu'on y est : les tags sont en vrac et il faut corriger « apès » par « après ».
[^] # Re: Une erreur belle comme un arc-en ciel avec des poneys
Posté par nojhan (site web personnel, Mastodon) . En réponse à la dépêche Sortie de la version 4.9 du compilateur GCC. Évalué à 1.
Il faut arrêter avec colorgcc, qui a un rendu immonde !
colout
fait beaucoup mieux, avec notamment la coloration syntaxique du code : http://nojhan.github.io/colout/ (cf. le thèmeg++
)# kakoune, un genre de neovim, mais en mieux ?
Posté par nojhan (site web personnel, Mastodon) . En réponse à la dépêche Neovim : une refonte de vim pour le 21è siècle. Évalué à 2.
J'ai vu fonctionner kakoune, un éditeur de texte très inspiré de vim, et c'est vraiment pas mal.
Les killers features que j'aime bien sont la grammaire dans le bon ordre (« sélection, puis action », alors que vim fait « action, puis sélection ») et le remplacement d'un langage de script par un petit système d'exposition des variables (ce qui fait que vous pouvez utiliser le langage que vous voulez, par exemple bash).
Il y a notamment pas mal de trucs que neovim veux implémenter, mais qui, là, sont déjà faites. Et c'est en… C++11.
https://github.com/mawww/kakoune
# WYSIWYM
Posté par nojhan (site web personnel, Mastodon) . En réponse à la dépêche Brackets : l'éditeur du web, par le web, pour le web. Évalué à 3.
Il y a un petit contresens sur le terme WYSIWYM.
En trois mots :
- en WYSIWY G, on voit exactement ce qui apparaîtra dans le navigateur, on ne voit pas le code.
- dans un éditeur de texte, on voit le code uniquement et pas le rendu.
- avec WYSIWY M, on ne voit pas le code, ni le rendu final, mais une mise en forme qui porte le sens. Typiquement, on ne verra pas les balises, H1 sera en gros et gras, mais pas dans les couleurs du CSS du site final.
De ce que j'ai compris en regardant Bracket, c'est un éditeur de texte avec une mise à jour du rendu en temps réel, mais ce qu'on voit, c'est le code source, directement.
Bracket n'est donc pas WYSIWYM.
On pourra comparer avec WYMeditor, qui me parait être un éditeur HTML plus dans l'esprit WYSIWYM.
[^] # Re: Perf
Posté par nojhan (site web personnel, Mastodon) . En réponse à la dépêche Liquidprompt version 1.7. Évalué à 2.
J'ai hâte de voir la démonstration de cette assertion qui ne porte pas en elle les preuves de sa véracité :-)
[^] # Re: Oh my zsh
Posté par nojhan (site web personnel, Mastodon) . En réponse à la dépêche Liquidprompt version 1.7. Évalué à 1.
Ces deux projets ne font pas vraiment la même chose. Oh-my-zsh vise plus large, il cherche à configurer l'intégralité du shell.
On pourrait tout à fait faire un module Oh-my-zsh avec liquidprompt.
En l'état il n'y a pas d'équivalent aussi intégré et dynamique dans Oh-my-zsh, qui propose surtout (enfin, la dernière fois que j'ai regardé, voilà un an ou deux) des prompts peu contextualisés et très mis en forme.
[^] # Re: graphisme
Posté par nojhan (site web personnel, Mastodon) . En réponse à la dépêche Rejoignez LinuxFr.org ! LinuxFr.org c'est vous !. Évalué à 2.
Ça devait être aux alentours de 2005, sur une ML quelconque, je ne retrouve même plus l'image dans mes sauvegardes :-(
J'ai plus qu'à m'y remettre :-)
[^] # Re: graphisme
Posté par nojhan (site web personnel, Mastodon) . En réponse à la dépêche Rejoignez LinuxFr.org ! LinuxFr.org c'est vous !. Évalué à 2.
Moi aussi, même si je suis techniquement déjà utilisé. Ceci étant dit, j'ai déjà proposé un logo, mais je n'ai eu aucun retour…
Et d'ailleurs, il n'y pas de mailing-list graphisme d'indiquée dans la dépêche ? :-)
[^] # Re: integration
Posté par nojhan (site web personnel, Mastodon) . En réponse à la dépêche Coloriser des flux de texte avec colout. Évalué à 1.
Une fonction ou un alias, par exemple j'utilise ça pour colorer une sortie de build cmake/g++ :
Ça s'utilise simplement :
[^] # Re: Colorer du texte sur la sortie standard en python
Posté par nojhan (site web personnel, Mastodon) . En réponse à la dépêche Coloriser des flux de texte avec colout. Évalué à 1.
Il y a peut-être moyen de refactoriser un peu colout pour qu'il puisse servir de module pour faire ce genre de truc aussi…
[^] # Re: grep
Posté par nojhan (site web personnel, Mastodon) . En réponse à la dépêche Coloriser des flux de texte avec colout. Évalué à 7.
L'exemple le plus frappant est la lecture d'une sortie très verbeuse, comme par exemple la sortie de gcc.
Tu ne veux pas filtrer avec grep parce que tu peux avoir besoin de tout lire. Par contre il est pratique de pouvoir repérer très rapidement les passages qui t'intéressent (les erreurs, par exemple). Les couleurs sont un moyen très efficace de faire ça.
C'est pour ça que j'ai commencé à faire colout, mais je me suis assez vite rendu compte que le problème se posait aussi pour plein d'autres choses (diff, logs) et même dans des cas où j'utilisais grep habituellement (grep de code source, par exemple).
On peut se dépatouiller avec grep ou d'autres commandes dédiées (git coloré, colordiff, ccze, etc.) dans la plupart de ces cas mais je me suis vite rendu compte qu'il était très pratique d'avoir une seule commande bien pensée pour remplacer plein de façon disparates de faire moins bien.
[^] # Re: Option
Posté par nojhan (site web personnel, Mastodon) . En réponse à la dépêche Coloriser des flux de texte avec colout. Évalué à 2.
C'est ce que fait l'option
-t
avec les fichiers de thème.Un thème est une fonction qui renvoie une liste de la forme :
Voir les fichiers
colout_*.py
pour des exemples.# Inverse
Posté par nojhan (site web personnel, Mastodon) . En réponse à la dépêche DChars, pour lire/écrire et modifier des caractères unicodes complexes. Évalué à 10.
Je ne suis pas sûr d'avoir bien compris à quoi ça servait, même si ça à l'air cool…
Est-ce que ça pourrait m'aider à faire une translitération "inverse" : d'une représentation multi-caractères latins vers de l'unicode ? (notamment vers du cunéiforme ?)
[^] # Re: Shell graphique
Posté par nojhan (site web personnel, Mastodon) . En réponse à la dépêche LiquidPrompt version 1.3. Évalué à 2.
Dernier commit voilà 4 mois… pour moi ça n'est pas assez long pour déclarer une mort clinique…
[^] # Re: Support Git
Posté par nojhan (site web personnel, Mastodon) . En réponse à la dépêche LiquidPrompt version 1.3. É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: Shell graphique
Posté par nojhan (site web personnel, Mastodon) . En réponse à la dépêche LiquidPrompt version 1.3. Évalué à 3.
TermKit : http://acko.net/blog/on-termkit/
[^] # Re: Mieux !
Posté par nojhan (site web personnel, Mastodon) . En réponse à la dépêche LiquidPrompt version 1.3. É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 propreLP_PS1
(cf. la doc).[^] # Re: Mieux !
Posté par nojhan (site web personnel, Mastodon) . En réponse à la dépêche LiquidPrompt version 1.3. Évalué à 1.
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 propreLP_PS1
. La doc explique tout ça avec des exemples, voir aussi les fichiersliquid.ps1
etliquid.theme
.[^] # Re: PROMPT_COMMAND
Posté par nojhan (site web personnel, Mastodon) . En réponse à la dépêche LiquidPrompt version 1.2. Évalué à 2.
Corrigé, merci.
[^] # Re: Question bête ...
Posté par nojhan (site web personnel, Mastodon) . En réponse à la dépêche LiquidPrompt version 1.2. Évalué à 1.
Il faut passer par le réseau pour voir l'écart avec un dépôt distant… je ne suis pas sûr que ça soit très rapide… et se reposer sur un fetch de l'utilisateur n'est pas très ergonomique. Le module git_ps1 est rapide, parce qu'il n'est pas en bash, je suppose ? Peut-être qu'on pourrait parser sa sortie au lieu de passer par des appels systèmes ?
[^] # Re: Lazy ?
Posté par nojhan (site web personnel, Mastodon) . En réponse à la dépêche pyxshell : piper des flux de texte en pur Python. Évalué à 2.
WTFOO : What The Fuck Object Oriented. C'est une vanne sur la lourdeur syntaxique du C++.
Pour des exemples d'opérateur
$
, voir le langage fonctionnel Haskell.Je me garderais bien de donner un avis tranché sur l'élégance, quant à moi :-)
[^] # Re: Licence
Posté par nojhan (site web personnel, Mastodon) . En réponse à la dépêche LiquidPrompt version 1.2. Évalué à 4.
On peut utiliser un prompt en se connectant sur un serveur, sans avoir à le télécharger. D’où l'AGPL.
[^] # Re: Question bête ...
Posté par nojhan (site web personnel, Mastodon) . En réponse à la dépêche LiquidPrompt version 1.2. Évalué à 1.
Le prompt affiche le nombres de lignes en plus/moins des modifications non commitées en rouge, le nombre de commits non pushés en jaune.
Récupérer à chaque affichage le retard sur pull serait bien trop lent pour le prompt. Mais on peut peut-être envisager un job en arrière plan et un cache…