Uther (./52) :
Pourtant je pense tout le contraire. Personnellement je préféré utiliser un autre IDE. Pourquoi s'embeter a programmer un IDE alors qu'il y en a de très bien faits. A part l'envoi automatique à Tiemu/VTI, TIGGC-IDE n'a pas grand chose qui le rende si indispensable au développement TI.

As-tu lu vraiment lu le message ./44 auquel tu réponds? Parce que rien que là j'ai déjà cité plusieurs avantages:

confort d'utilisation, compatibilité de projets entre plateformes, adaptation au développement sur calculatrice (options du projet, en particulier les options de TIGCCLIB et de ld-tigcc, coloration syntaxique pour l'assembleur 68k, envoi à la calculatrice ou TiEmu etc.) et ressemblance de l'interface entre plateformes (ce qui permet d'utiliser la même documentation et les mêmes tutoriaux partout)

Je rajouterai aussi:
* l'interface vraiment adaptée aux fonctionnalités vraiment utiles pour la programmation sur TI et non surchargée avec des fonctionnalités qui ne servent à rien pour un programme pour la calculatrice,
* la lecture/écriture de fichiers en le charset de la calculatrice même sur les plateformes utilisant l'UTF-8 (OK, TIGCC IDE utilise le CP 1252 qui n'est qu'une approximation au charset TI, KTIGCC est vraiment capable Unicode et convertit charset TI <-> Unicode en interne) - si tu enregistres tes sources en UTF-8, les caractères spéciaux dans tes chaînes de caractères ne seront pas affichés correctement sur la calculatrice parce qu'elle ne gère pas l'UTF-8,
* la compilation dans un dossier temporaire qui permet de:
- compiler (et exécuter) un projet sans l'enregistrer (même si par défaut, il est enregistré automatiquement, mais ça peut être désactivé dans les préférences), pratique si tu veux juste tester un truc dans l'émulateur sans modifier le projet enregistré,
- avoir des dossiers virtuels qui ne correspondent pas forcément aux dossiers physiques, en particulier ajouter des fichiers au projet peu importe où ils se trouvent sur le disque (même si je déconseille l'utilisation de fichiers en dehors du dossier dans lequel se trouve le .tpr parce que ces chemins seront codés en absolu et donc non transportables sur d'autres machines),
* la complétion des identifiants de TIGCCLIB avec les informations extraites de la documentation de TIGCC
et j'en oublie sûrement. Et le fait que l'intégration avec TiEmu ne se limite pas à l'envoi, il y a aussi le débogage (chargement des informations de débogage et lancement automatique du programme, avec des arguments configurables dans les options du projet).

Un exécutable send2ti en ligne de commande qui permette de faire un truc du genre : send2ti -tiemu file.89z serait pratique pour ceux qui ne souhaitent pas utiliser l'IDE.

Ça existe déjà:
tilp --no-gui --cable=TiEmu --port=2 file.89z
Dans le cas de TiEmu, tu peux aussi utiliser une des interfaces IPC (D-Bus, OLE, DCOP).

Lionel Debroux (./53) :
"Ne pas committer" n'est pas synonyme de "garder mes modifications en local jusqu'à la fin du développement", même en centralisé: ML, forum et tracker peuvent aussi servir à avoir une sauvegarde, et ne sont pas (a priori) plus ou moins fiables qu'un serveur centralisé de SCM ou de fichiers (FTP, HTTP, rsync, unison, etc.).

Tu en as d'autres comme ça? Selon toi, je vais faire un cvs diff, ouvrir un navigateur web, aller sur un tracker, attacher le diff et l'envoyer quand je peux faire un commit tout simplement? C'est vraiment n'importe quoi comme suggestion...

Ta manière de travailler sux parce qu'elle baisse la qualité des commits

C'est le résultat qui compte, si c'est fait en un commit ou en 10 n'a strictement aucune importance. Ce que je délivre, ce sont les releases, pas les commits. Le SCM est l'endroit où je développe, pas un produit du développement. Les commits reflètent le développement tel qu'il a été effectué, ils ne sont pas embellis ou idéalisés, ce n'est pas du tout à ça que sert un SCM. Je ne cache pas mes erreurs. On fait tous des erreurs, ça ne sert à rien de les cacher.