informatique et high-tech (les meilleures news) %) - Page 526

Zerosquare (./15745) :

melbou (./15743) :
C'est marrant que des programmeurs n'aient pas programmé de truc potable pour... programmer

Ouais enfin pour Eclipse et Netbeans, on parle de programmeurs Java, faut pas confondre

Netbeans n'est pas spécialisé Java contrairement a Eclipse

Ouais bah Eclipse+PDT est un peu mieux que Netbeans pour faire du PHP

C'quoi PDT?

salmoooon (./15734) :
hm quoique, en y repensant, ya le debugger aussi qu'est atrocement lent et buggue...

On m'a toujours dit que c'était le meilleur débuggueur au monde! (ce que j'imagine très bien: windows est tellement buggué qu'il leur faut un débuggueur de compèt! [/troll])

PHP Developer Tools

L'intégration n'est pas 100% parfaite (mais surtout parce qu'il faut passer un peu de temps si on veut vraiment avoir un paramétrage bien comme il faut - typiquement, je n'ai qu'une vérification du code avec les parseur du plug-in, pas à travers le binaire php-cli).

Ah, merci! C'est pour coder Web en Java+PHP si je comprends bien.

PDT c'est que PHP. Après, j'ai aussi ajouté les Web developer tools (js+(x)html+css).

Ah, je pensais que comme c'était sous Eclipse, on parlait Java....

Donc on peut faire du PHP sous autre chose que Bloc-notes (à la ramasse, moi)

GoldenCrystal (./15749) :
Faut pas abuser quand même… emacs doit être la pire abomination jamais pondue au monde dans le domaine des éditeurs de texte moches, non ergonomiques et complexes à utiliser pour pas grand chose.

Et VI alors ?

Zerosquare (./15758) :

GoldenCrystal (./15749) :
Faut pas abuser quand même… emacs doit être la pire abomination jamais pondue au monde dans le domaine des éditeurs de texte moches, non ergonomiques et complexes à utiliser pour pas grand chose.

Et VI alors ?

C'est ultra ergonomique enfin!

:w
ost
:q!

vince (./15748) :
d'un autre coté, VI a été proposé aussi...

D'un autre côté c'était ironique...

je sais, comme le ./15750

./15760> Ne vous mettez pas de tous les côtés comme ça, on verra bientôt plus les bords de la page!!

emacs vs vi> Curieusement les 3-4 trucs qu'on m'a montré avec vi, je les retenus; curieusement avec emacs, pas

emacs
control alt meta mer, control shift insert dtc

vim
:fuck

C'est pas ergonomique mais pour editer en ligne de commande y'a quoi de mieux que vim? (question sans intention trollatoire, si il existe mieux j'aimerais connaitre pour de vrai)

nano/pico marchent bien

oué, au moins ils affichent les commandes ^^

melbou (./15764) :
C'est pas ergonomique mais pour editer en ligne de commande y'a quoi de mieux que vim? (question sans intention trollatoire, si il existe mieux j'aimerais connaitre pour de vrai)

Voilà, nano. Moi c'est emacs et pas vi. emacs-nox, pour configurer en console, est toujours le premier paquet que j'installe quand j'installe une distro.

Mais après chacun son truc, j'ai pourtant essayé de m'en servir quelques mois pour dev, c'set galère. Alors peut-être pour un pro, après de longs mois, ok, je veux bien croire. Mais pas pour un casual codeur.

(pour info, le package standard sur un UNIX c'est vi, voir ed, mais nano est standard sous Gentoo emacs je ne l'ai plus utilisé depuis plus de 6ans et je m'en porte pas plus mal!)

vim/gvim que j'utilise régulierement (en plus d'un vrai IDE) on aussi leur avantages sur nano, ça dépend de ce qu'on fait.

Mmh nano il est pas installé par défaut sur la Suse qu'on utilise. Tant pis.

nano je connais pas, mais gvim sous windows est l'éditeur le plus rapide que je connaisse. Aucun ne le bat, même sur de gros docs.

kate rulez

squalyl (./15770) :
nano je connais pas, mais gvim sous windows est l'éditeur le plus rapide que je connaisse. Aucun ne le bat, même sur de gros docs.

Si, MacVIM sur OS X : meilleure gestion des tab, et les raccourcis clavier standards d'OS X (cmd-S, cmd-C, cmd-V, ...) n'interfèrent pas avec les raccourcis clavier de VIM contrairement aux autres OS.
Par contre, gvim sur Linux est vraiment pourri

kate sur kde 4 kekchoz active par défaut le BOM sur les fichiers UTF-8, et ça, c'est une grosse putain de merde, parce que sur un fichier PHP, ce BOM se retrouve avant le <?PHP initial, et ça se retrouve dans la sortie.
Quand y'a plusieurs fichiers php inclus avec ce problème, déja ça fait une suite de BOMs dans la sortie, pas grave c'est non imprimable, mais quand t'as en plus une page de download, ça corrompt tous les fichiers au download

donc pour moi tant que kate a ce réglage par défaut débile pour les fichiers php, il est disqualifié.

pourtant dans le menu "tools" sur un fichier "untitled" utf8 tout neuf il y à "Add Byte Order Mark"

ça fait un paquet de temps que je m'en sert, j'ai jamais eu de blème.

c'est pas des fichiers utf8 tout neufs

il nous a "niqués" une dizaine de fichiers php existants.

je les ai réparés à l'éditeur hexa, pour être sûr

De toutes façons le BOM pour des fichiers UTF-8, c'est débile... il n'y a qu'en UTF-16 et UTF-32 qu'il a un sens, vu qu'il n'y a pas de notion d'endianess pour les fichiers UTF-8.

c'est clair

lol ? http://www.zdnet.fr/actualites/megaupload-ferme-parce-qu-il-projetait-de-lancer-un-service-concurrent-a-itunes-39767827.htm

bah que se soit avec des fichiers que je crée moi même ou d'autre, jamais eu de soucis

juste une fois, le graphiste à touché qq fichiers avec notepad++ et c'est lui qui à tout niqué, celui ci les à mis en ascii sans rien demander (pourtant niveau transformation d'encodage je le trouvais génial quant je m'en servais)