Yoran 28 novembre, 2011 - 00:46 EDI PHP Éditeur de Texte
SublimeText2 comme environnement de développement PHP

SublimeText fait parti de mes trois éditeurs éligibles au remplacement d'Eclipse pour mes développements quotidiens. Je reviendrais sûrement sur les raisons qui me font abandonner cet EDI mais en substance il était devenu plus un boulet à trainer qu'un accélérateur d'efficacité. Une lourdeur qui était justifiée par sa valeur ajoutée lorsque je travaillais sous Java/J2EE, mais qui devenait de plus en plus difficile à accepter lorsque je suis passé au développement WEB où finalement j'utilisais Eclipse plus comme un éditeur évolué me prenant 1GO de RAM... J'ai donc cherché à remédier à cette situation en évaluant mes besoins, et en cherchant quels "super" éditeurs de texte pouvaient y répondre. Je suis arrivé à gEdit, SublimeText2 et gvim. Ce petit Tutoriel est donc le fruit de mes essais sur SublimeText2.

Pourquoi (pas) SublimeText2 ?

SublimeText2, malgré son nom totalement idiot, était prometteur par son objectif même : un éditeur multi-plateforme cherchant à "mimer" l'excellent TextMate pour MacOS. Et de manière général il y arrive plutôt bien, surtout considérant qu'il s'agit d'une version encore très fraiche et pleine de bugs. Comme TextMate, cet éditeur est doté d'une communauté relativement active produisant de nombreux plugins auxquels viennent s'ajouter certains éléments compatibles avec Textmate (snippets, colorisations, etc.). L'outil est en outre très fortement paramétrable et le cas échéant, l'API python permet d'en étendre les fonctionnalités.

En revanche, gros inconvénient à mes yeux, l'outil n'est absolument pas libre. N'étant pas intégriste de nature, j'aurais pu faire avec (j'ai même acheté une licence), mais comme beaucoup de logiciels fermés, cet aspect implique une vitesse d'évolution très faible qui elle, au bout de deux semaines de remonté d'anomalies, commence déjà à me courir. Surtout lorsque j'aurais pu corriger 90% des problèmes rencontrés si j'avais accès aux sources.

Donc au final, je doute fortement que ST2 devienne à terme mon environnement standard. Mais malgré cela il s'agit d'un très bon outil que d'autre pourront trouver parfaitement à leur goût. Voilà pourquoi je prend la peine d'écrire ces quelques lignes sur ce que j'ai déjà pu trouver pour en faire un environnement de développement PHP viable. Ce document est tout sauf exhaustif dans la mesure où j'ai arrêté mes investigation en cours de route.

Pour ce qui est des deux autres éligibles, je pense, après avoir passé gedit au crible de mes besoins, qu'il ne sera pas, lui non plus retenu. C'est un excellent petit éditeur mais il lui manque des fonctions fondamentales pour en faire un environnement de développement viable comme, au hasard, une gestion de projets. Reste donc VIM que j'avais ajouté à ma liste sans grande conviction et qui m'a finalement assez bluffé jusqu'à maintenant. Mais ça, c'est une autre histoire...

Installation de l'auto-complètement et de la recherche de définitions

S'il est deux fonctionnalités devenues vitales pour un développeurs, ce sont bien l'auto-complètement permettant d'écrire rapidement des appels à des fonctions, mots clefs, classes, variables en en tapant juste les premières lettres. Et la recherche de définition consistant à pointer une fonction pour se téléporter sur l'endroit où elle est définie, ailleurs, dans un autre fichier.

ST2 en standard propose un auto-complètement très efficace mais non lié au code source du projet en cours. Il permet de récupérer les mots clefs du langages, les variables ou fonctions du fichier en cours, mais aucunement celles des autres fichiers. De même il n'est pas possible de retrouver rapidement la définition d'une fonction.

Pour combler cette lacune il existe fort heureusement un paquet, SublimeCodeIntel qui exploite Code Intelligence Plugin du projet Komodo Editor. Il apporte ainsi la prise en charge de nombreux langages dont PHP, Javascript, HTML5, etc.

Pour installer le paquet, il faut juste clone le projet dans le dossier des paquets de ST2 :

gastoncd ~/.config/sublime-text-2/Packages
gastongit clone https://github.com/Kronuz/SublimeCodeIntel.git
Installation du thème

Ensuite, il faut s'assurer que le paquet (GNU/Linux cette fois) libpcre++-dev> est bien installé sur votre distribution (apt-get install libpcre++-dev sous Debian).

Il ne reste maintenant plus qu'à aller dans le dossier src de SublimeCodeIntel et de lancer la commande ./build.sh. Cela va recompiler le moteur d'indexation pour votre machine. Lorsque ce travail est effectué, vous n'avez plus qu'à redémarrer ST2.

Ensuite, si vous avez un projet ouvert avec ST2 comportant un ensemble de fichier sources (ex. PHP), vous pouvez tester l'auto-complètement via Ctrl-Espace. Le système va un peu mouliner pour indexer puis vous proposer une liste de possibilités.

Pour la fonctionnalité de recherche d'une définition de fonction, il faut officiellement faire un ALT+Click sur la fonction. Mais 1/ chez moi, impossible de faire fonctionner cela 2/ en tant qu'utilisateur eclipse, j'ai le réflexe de la touche F3.

Fort heureusement ST2 permet de modifier absolument tous les raccourcis claviers. Pour cela allez dans Preferences ⇢ Key Bindings (User) pour ouvrir le fichier de configuration des raccourcis (qui doit être vide logiquement) et placez-y le contenu suivant :

[
{ "keys": ["f3"], "command": "goto_python_definition" }
]

Ne vous laissez pas impressionner par le goto_python_definition, cela fonctionnera aussi bien avec du PHP. Pour s'en convaincre, il suffit de sauvegarder la configuration, d'aller sur un appel de fonction du projet et de presser F3 pour être téléporté directement sur sa définition. La distance avec Eclipse se réduit fortement...

Réglages de la police et des tabulations

Si la police utilisé ne vous convient pas, il est très simple d'en change en modifiant le fichier Preferences ⇢ File Settings (User) :

{
"font_face": "Mono",
"font_size": 9,
}

De même vous pouvez modifier le mode de gestion des tabulations dans le même fichier :

{
"detect_indentation": false,
"tab_size": 2,
"translate_tabs_to_spaces": true,
"trim_automatic_white_space": true,
"word_wrap": false
}

ST2 nous pose un problème en PHP car le double-click sur un identifiant n'inclue pas tous les caractères de cet identifiant. C'est une chose facile à modifier grâce à la propriété word_separators :

"word_separators": "./\\()\"'-:,.;<>~!@#%^&*|+=[]{}`~?",

Installation d'un dictionnaire en français

ST2 utilise le correcteur orthographique Hunspell mais ne comporte en standard que les dictionnaires anglais. Vous pouvez facilement y remédier en allant sur le site dicollecte pour télécharger une archive française.

Ceci fait, décompressez les fichiers .dic et .aff dans le dossier ~/.config/sublime-text-2/Packages/Language - English et redémarrez ST2. Vous devriez voir apparaître la nouvelle langue dans View ⇢ Dictionnary.

Changement du thème global

Il est possible de changer totalement l'apparence de ST2. Il existe pour cela des paquets sur GitHub comme par exemple le très sympa thème "Soda". Pour l'installer, procédure habituelle, clone du projet dans le dossier des paquets :

gastoncd ~/.config/sublime-text-2/Packages
gastongit clone https://github.com/buymeasoda/soda-theme/ "Theme - Soda"
Installation du thème

Ensuite il nous faut modifier la configuration globale pour pointer sur le nouveau thème.

{
"theme": "Soda Light.sublime-theme",
}

Dés la sauvegarde, le thème est pris en compte.

Changement du thème de la coloration syntaxique

Il s'agit là des couleurs utilisées au sein de l'éditeur pour mettre en brillance les mots clefs, variables, etc. ST2 est fourni en standard avec un beau paquet de schémas que vous pouvez déjà explorer en allant dans Preferences ⇢ Color Scheme. Mais si rien ne vous convient, en cherchant un peu sur le net vous en trouverez facilement un autre plus à votre goût.

N'étant personnellement pas un grand fanatique des looks "darks", j'ai opté pour celui préconisé par le thème Soda que vous pouvez télécharger ici.

Une fois l'archive téléchargée, décompressez là dans un dossier Color Scheme - User dans votre dossier de paquets. Vous devez avoir deux fichiers .tmTheme. Redémarrez ST2 et à votre retour vous devriez voir Preferences ⇢ Color Scheme ⇢ Color Scheme - User deux nouveaux thèmes que vous pouvez utilisez directement.

Quelques liens utiles

Vos remarques et commentaires...

saorel, le 28 novembre, 2011 - 08:49

Un article très sympatique (comme toujours), un logiciel que je comptais présnter dans un futur billet. Pour moi il s'agit de l'editeur graphique de texte (de code) le plus performant que j'ai utilisé.

Belle journée

P.S: Je profite de ce commentaire pour signaler que les liens utiles sont mort sur mon firefox.

Yoran, le 28 novembre, 2011 - 10:04

Oui clairement l'éditeur est sympa, ça c'est indéniable. Ce qui l'est pour moi moins c'est son aspect "source fermé". Et encore ce ne serait pas un si gros problème si cela ne s'accompagnait pas de l'absence d'un gestionnaire d'anomalie qui permette au moins d'avoir une vision sur l'avancement des corrections ou bêtement leur intégration dans de futures versions. Personnellement c'est ce manque de visibilité qui me bloque pour un usage intensif de cet outil.

L'autre aspect qui m'a posé un problème difficile à contourner c'est l'outil SublimeCodeIntel qui va régulièrement planter l'éditeur. Régulièrement (très très régulièrement) je me suis retrouvé avec l'éditeur bloqué et obligation de tuer la tache. Alors évidement il s'agit d'un plugin qui n'est pas de la responsabilité de l'éditeur lui-même. Mais ce plugin est tellement vital que cela ne change pas grand chose au final.

PS: les liens sont revenus :)

Florian, le 28 novembre, 2011 - 11:33

Sinon en éditeur libre écrit en python et imitant TextMate il y a aussi http://scribes.sourceforge.net/

Yoran, le 28 novembre, 2011 - 11:49

ça a l'air sympa sur le "papier", je viens de l'installer et jeter un oeil rapide. L'animation de la barre d'outil m'agace réellement mais j'imagine que cela peut être configuré.

En revanche, même si je suis assez d'accord sur l'inutilité des onglets, qu'en est-il des panneaux latéraux ? Je n'ai rien trouvé qui permette d'en ajouter et j'en ai besoin pour deux aspects "mandatory" de mon cahier des charges : l'exploration du dossier en cours et l'affichage de la structure du fichier en cours. Mais j'ai regardé très vite, j'ai sûrement loupé des choses.

En tout cas merci pour ce pointeur.

Florian, le 28 novembre, 2011 - 12:03

Voila l'info sur le blog du dev principal : http://mystilleef.blogspot.com/2011/07/scribes-side-pane-file-browser.html

Je suis d'accord sur l'animation de la barre d'outils, mais j'ai pas trouvé comment empècher ce comportement..

Je pense que le dév veut pousser les utilisateurs à apprendre les raccourcis..

Jo, le 28 novembre, 2011 - 12:58

Et Geany l'as tu testé ? Une fois tuné j'ai vraiment pas trouvé mieux !

Pascal Chevrel, le 28 novembre, 2011 - 16:01

Tu devrais jeter un œil à Geany, c'est léger, libre, stable, assez configurable et bien plus puissant que Gedit:

http://www.geany.org/

Je fais beaucoup de webdev (php, html, css, js) pour mon boulot et je l'utilise avec plaisir depuis plusieurs années.

Yoran, le 28 novembre, 2011 - 17:46

Ok je note, je vais tester geany, vous êtes déjà deux à me le conseiller :-) Ma dernière évaluation de cet outil date d'au moins 2 ans, j'imagine qu'il a du évoluer depuis.

En tout cas merci du conseil à tout les deux.

Yoran, le 28 novembre, 2011 - 22:50

Bon, ben pour geany, je suis tombé sur un bel os. J'avais réussi à peu prés à tout faire fonctionner (y compris cette maudite coloration syntaxique) mais là je coince sur les tags.

En standard, geany ne gère que les tags fichier par fichier, c'est un peu court sur un gros Projet.

Si l'on utiliser GProject ou GeanyPrj, ça fonctionne, il indexe bien l'ensemble des fichiers mais alors là c'est le moteur de génération de tags qui est clairement trop lent. 35 secondes pour indexer mon projet lorsque ctags fait cela en 6 secondes... Et il fait cela à chaque nouvelle ouverture d'un projet sans que je puisse trouver moyen de mettre cela en cache et effectuer le scan à la demande. D'ailleurs le panneau de config indique bien de ne pas activer les tags pour un projet de plus de 1000 fichiers... mais il est mignon, si c'est pour un projet de 100 fichiers, j'ai pas besoin de tags moi !! :)

Du coup, j'ai voulu faire comme avec VIM et ne générer les tags qu'une fois de temps en temps. J'ai donc essayé de passer par la génération externe (geany -g + outils/ajouter des tags) mais par ce biais, seuls les symboles sont générés, pas les références aux fichiers. Cela donne donc accès à l'auto-complètement (sans les paramètres :/) mais pas à la recherche de déclaration de fonctions.

J'ai même tenté l'obscure format "pipe" en convertissant une entrée ctags. En effet, je me suis rendu compte que ce format (http://www.geany.org/manual/current/#tags) prend en compte le chemin relatif dans le projet. J'ai donc généré un beau fichier parfaitement valide, et bien non, il veut toujours pas aller à la définition...

Enfin, je n'ai pas non plus trouver moyen de remonter dans l'historique d'édition (fichier => Ctrl-T => Nouveau fichier => ?? pour revenir au fichier d'origine).

Il faut dire qu'un projet pour moi (stats donnés par ctags) c'est 1838 fichiers PHP, 337 340 lignes de codes et 41554 tags... Et sur cette taille il faut avouer que geany fonctionne même moins bien qu'Eclipse... Et en tout cas clairement moins bien que ST2/CodeIntel

Et le problème c'est que je ne peux pas fonctionner avec des tags "statiques" (juste l'auto-complètement) car j'ai en permanence besoin de voir comment est codé le framework. Vu le niveau de documentation du projet Drupal et de ses modules contribs, se passer de cela ce n'est juste pas une option...

A suivre donc, mais là c'est un peu mal parti :)

Dab, le 28 novembre, 2011 - 16:41

Et bien sûr ne pas oublier Emacs ... qui fait tout ce que tu désire/imagine et bien plus ...

Yoran, le 28 novembre, 2011 - 17:55

Oh hé, je veux pas risquer la tendinite moi :)))))

Plus sérieusement, si je devais choisir un éditeur console, je serais plus sous VIM dans la mesure où j'ai déjà le background (je l'utilise depuis, hum, je veux pas dire combien de temps ;-). Je ne l'avais jamais poussé en tant qu'EDI auparavant mais hier j'ai testé les plugins sessions/taglist/syntastic/NERDTree et le résultat est assez sympà. J'ai réussi à faire absolument tout ce que j'avais l'habitude de faire avec éclipse et à une vitesse largement supèrieur (genre l'indexation d'un projet drupal en 6 secondes...)

Maintenant dans le cadre d'un dev web, un éditeur graphique reste une option plus intéressante je pense (browser de fichiers, outline de code, sélectionner une couleur via un picker, etc). Je ferais du C je n'hésiterais pas, mais pour du PHP je ne suis tout de même pas 200% convaincu, du moins pour l'instant, je continue à chercher :)

Yoran, le 28 novembre, 2011 - 23:46

Je me demande si je vais pas définitivement finir avec vim moi ;-)

http://static.flogisoft.com/vim/vim_color_picker_0.1.png

Casper, le 29 novembre, 2011 - 00:00

As tu essayé Kate ? il y a plein de module intéressant et le must c'est le split de la fenêtre d’édition !

Yoran, le 29 novembre, 2011 - 00:07

Sans vouloir rabaisser Kate que j'ai utilisé pendant toute ma periode KDE, le split est une fonctionnalité que tu as même sous vi.

Mais oui Kate, comme beaucoup d'appli KDS (KMail ou Kopete par exemple) est très bon. Mais me concernant il a juste un problème : KDE. Je me suis fâché avec ce bureau lors de son passage à la version 4 et depuis ça ne s'est pas arrangé. Plus le temps avance, plus je recherche légèreté et simplicité. Je commence même à faire chauffer la compilation d'XFCE en prévoyance de l'arrivée de Gnome Shell ;-)

Casper, le 29 novembre, 2011 - 00:09

j'utilise kate avec gnome j'ai pas aimé non plus kde

Yoran, le 29 novembre, 2011 - 00:19

C'est vrai que cela fonctionne, mais tu as déjà regardé tout ce qu'une application KDS charge lorsqu'elle est lancée en environnement "alien" ? Perso je suis peut-être (sûrement ;-) un peu psycho-rigide mais ça me pose un problème :) La seule application KDE que je lance par obligation lorsque je ne peux plus faire autrement c'est kcachegrind qui n'a pas (enfin je n'en ai pas trouvé) d'équivalent valable sous gtk.

Casper, le 29 novembre, 2011 - 00:23

oui ça ouvre un tas de "merde" mais je crois que je ne pourrais plus m'en passer. même lorsque je suis obligé d’être sous windows j'utilise kde for windows.
Merci pour kcachegrind j'avais complètement oublié son existence.

KaBooFa, le 29 novembre, 2011 - 13:50

Bonjour,

Perso je ne suis jamais parvenu a faire fonctionner SublimeCodeIntel sur SublimeText2 ni sous Windows ni sous ArchLinux.

Le tout est très lent est la fenêtre de proposition ne s'affiche pas.

KaB

fero14041, le 29 novembre, 2011 - 14:18

Comme éditeurs alternatifs, il y aurait également jEdit: liste des fonctionnalités, liste des plugins. Ecrit en Java, relativement complet, je l'avais testé en cherchant une alternative à Eclipse, et à SciTE.
Bon, depuis, j'ai découvert Vim ;-p

Yoran, le 29 novembre, 2011 - 16:17

Je pense que je ne pourrais jamais être taxé de mauvaise fois concernant Java qui a fait mon expertise pendant un gros paquets d'années, mais dés que l'on touche à la performance, ce n'est pas bon. Et c'est encore plus vrai concernant un éditeur utilisant Java, et encore plus pour un éditeur utilisant sa couche Swing (l'interface graphique pure java) ce qui est la cas de JEdit (mais aussi de phpEdit, Netbeans, etc.). Et là règle d'or est que tout ce java ne perd pas en performance, il le fait payer en consommation mémoire :-)

Java est un excellent langage/plateforme d'un point de vue qualité logiciel, mais tout ce que fera jEdit/phpEdit/NetBeans/Eclipse/Etc, un éditeur natif le fera en prenant moins de CPU et/ou (beaucoup) moins de mémoire. En contrepartie il sera rare qu'une application native offre la même puissance qu'un application java à périmètre fonctionnel égal, j'en suis conscient.

Toujours est il que si je quitte Eclipse, ce n'est pas pour repartir sur du Java :-) Et il semble que plus le temps avance, plus je te rejoigne sur VIM.

PS: quelqu'un sait comment faire passer de l'ANSI dans gVIM lorsque l'on exécute une commande externe (ex. :!git diff %) ?

lex, le 30 novembre, 2011 - 10:54

lu,
Je passe par là un peu par hasard et je me rends compte que je suis pas le seul à toujours revenir à vim, même après une foultitude d’infidélité. Je trouve pas mieux (pourtant j'ai essayé hein !).

Globalement, pour git j'utilise Fugitive (plus d'info).

Si tu es familier de Git, je te recommande pathogen.vim pour la gestion/utilisation des plugins.

Pour l'Ansi je comprends pas trop ton besoin.

Yoran, le 30 novembre, 2011 - 11:16

Oui je pense qu'on est beaucoup à se dire "Pff mais c'est vieux ce truc, forcement le neuf doit être bien mieux... En finalement... non". La parallèle que j'ai trouvé récemment c'est les PC et les tablettes. C'est un peu comme si un développeur se disait "pfff mais c'est vieux le concept de PC, je vais développer directement sur une tablette"... Bon courage :)

Sinon oui pathogen est un must, indéniablement. J'ai surtout de mon côté bien bataillé pour mettre vim réellement au niveau d'éclipse en matière d'auto-complétement, de recherche de définition de fonction, et de marquage en général. Mais là ça commence à fonctionner bien mieux que l'"original", ça fait plaisir.

Pour l'ANSI, l'idée est que j'ai plein de commande (en fait tout mon script de gestion de projet) qui fait une utilisation intensive de la couleur via le protocole ANSI. Idem pour mes commandes GIT que j'ai configuré (git diff, git status, etc.) pour utiliser la colorisation (pratique pour les diffs..).

D'habitude je lançais les commandes via vim en passant par !ma_commande et tout fonctionnait bien, logique, on était en console. Or avec mon retour à VIM je teste gVim qui offre bien des avantages et là ça ne marche plus du tout vu que dans ce logiciel, le retour des exécutable n'est pas interprété en ANSI mais en texte simple. Du coup, gros bazar et la commande ! est donc limite inutilisable pour moi dans gVim.

lex, le 30 novembre, 2011 - 11:36

mmm,

Effectivement, gvim n'aime pas trop l'ANSI. Ce truc correspond peut être à ce que tu cherches.

Mais j'insiste : si tu veux une intégration (avancée) de git (blame, diff, commit etc...), si t'as 5mn jettes un œil sur le site que j'ai passé en info plus haut. Ça change pas mal la vie ^^.

Yoran, le 30 novembre, 2011 - 12:55

Ah c'est très bien ce "truc", je vais regarder cela, merci :))
Edit: et en plus ça marche redoutablement bien !!

Sinon pas la peine d'insister, j'ai déjà installé le plugin :)))) Et effetctivement il semble assez top, merci pour cela !

Publier un nouveau commentaire

Le contenu de ce champ sera maintenu privé et ne sera pas affiché publiquement.
  • To highlight piece of code, just surround them with <code type="language"> Your code &tl;/code>>. Language can be java,c++,bash,etc... Everything Geshi support.
  • Tags HTML autorisés : <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <blockquote> <div> <p> <br>
  • Les lignes et les paragraphes vont à la ligne automatiquement.
  • Les adresses de pages web et de courriels sont transformées en liens automatiquement.

Plus d'informations sur les options de formatage

CAPTCHA
Cette question est là pour déterminer si vous êtes humain ou pas...