> L'un est l'autre, s'ils ne sont destinés qu'à des manipulations de
codes sources, ne peuvent me suffire, vu que pour ma part, j'en manipule
plutôt peu, de code source. Toutes les fonctionnalités dont on parle ici
peuvent m'intéresser occasionnellement, mais ce serait d'autant plus le
cas si je pouvais utiliser l'un ou l'autre éditeur de manière unique, y
compris pour ce que j'en fais le plus: lire des fichiers textes, y
compris de plusieurs centaines
de kilo-octets.
Un de mes buts non avoués est de se débarasser définitivement du notepad
de windows. Ce n'est pas encore fait, mais le jour où j'aurai atteint
la stabilité, je le remplace.
> Avec 6Pad, que j'ai un peu mis de côté depuis quelques mois (un an
peut-être), je ne pouvais guère manipuler un fichier par des séries de
déplacements/suppressions de texte sans qu'il finisse par partir en
live, idem au bout de 5 10 minutes.
Je pense m'être pas mal amélioré sur ce point. Mais su rencontres des
écueils de ce type, n'hésite pas à les signaler. C'est comme ça qu'on
progresse.
J'ai déjà essayé d'ouvrir un fichier de 15 Mo, il s'ouvre en un temps
tout à fait respectable et ne me paraît pas spécialement planter à la
lecture.
L'édition d'un énorme fichier de plusieurs Mo peut encore être
problématique par contre. Le trou noir en RAM est la fonction undo ici.
J'envisage de passer à un système d'annulation où la limite ne serait
plus un nombre de niveaux fixe, mais une taille bornée. En clair: un
système qui répondrait à la question combien de mémoire êtes-vous prêt à
utiliser au maximum pour la fonction annuler. Du coup pour un très très
gros fichier, ça se limitera peut-être à deux niveaux, et 20 voire plus
pour un tout petit fichier.
> EdSharp a un gros avantage, pour moi du moins, c'est la conversion
de divers formats de fichiers, allant du .doc au PDF et à l'HTML, sauf
qu'en fait pour tout ça je préfère son prédécesseur, TextPal, pour les
mêmes raisons de lenteur au démarrage. Ben oui, je démarre souvent lol.
De ce côté là, rien n'interdit de coder un script d'import qui fera
appel à un programme externe. Tiens par exemple, le getText.exe inclus
dans EdSharp à l'air particulièrement intéressant...
> Et puis si on se met à comparer divers éditeurs, je vais vous
reparler du mien, NoteTab, en lister les points forts et exiger (entre
grands guillemets
virtuels), qu'elles soient intégrées à 6Pad. Lol.
Mais je t'en prie, fais tes propositions. Tant que ça reste constructif,
il n'y a rien à perdre. ET même si je refuse, il y a des chances pour
qu'un script soit faisable par toi-même ou quelqu'un d'autre.
> Ah, et puis, 6Pad est mégasuperportable. Si on parle du .net
Framework, je n'ai qu'un seul logiciel qui nécessite le .net version
2.0... C'est EdSharp.
SoundForge en nécessite une version différente, inférieure. Je repose ma
question: peut-on envisager de rendre un programme utilisant le .net
portable,
c'est-à-dire, avoir une garantie à 100% qu'il sera utilisable sur un
autre ordi, sans avoir si oui ou non il fera partie des quelques
machines qui n'auraient pas le .net ? C'est ça un programme portable,
sans tricher tout au moins. En tout cas, tant qu'on trouve toujours des
oredis sous XP en circulation.
Mème sur 7, j'ai quelques-unes des fonctionnalités de la version de
mahan qui ne fonctionnent pas parce qu'il me manque des composants .net
(la traduction par exemple), ce n'est pas un problème propre à XP.
Mais ça, c'est l'inconvénient des machines virtuelles: que ça soit java,
.net, python ou autre chose, quand tu distribues un programme compilé
pour une machine virtuelle, il est portable mais uniquement dans les
limites de disponibilité de la dite machine.
Le seul moyen d'être 100% portable sans avoir à se poser la question de
la disponibilité de la VM est alors de l'embarquer.
Évidemment, embarquer java ou .net, c'est juste complètement démesuré,
surtout pour quelque chose à la base aussi simple et indispensable qu'un
éditeur de texte. Pareil si le logiciel est à la destination des newbies
qui n'y connaissent rien à l'informatique et pour qui installer un
framework quel qu'il soit est impensable. Embarquer ruby et python ça
passe déjà mieux, mais quand même, c'est vite assez gros. C'est là que
le génie de lua entre en scène, avec une VM qui fait dans les 250 Ko et
qui s'embarque donc parfaitement sans la moindre douleur. Sauf erreur,
lua est à ce jour le langage VM le plus compact, et luajit
l'implémentation la plus rapide existante dans la catégorie langage à
typage dynamique.
Progliste :
Pour se désinscrire de la liste :
mailto:[email protected]?subject=unsubscribe
Pour voir les archives de la liste :
http://www.mail-archive.com/[email protected]/
Je vous rappelle que les pièces jointe sont activés leur taille est limité à 2 MO
Pour accéder aux fichiers de la liste
http://outils.archive-host.com/partage.php?id=2Qar9Hy6ftzr
Ou en utilisant la nouvelle page de partage :
http://outils-n.archive-host.com/partage-fm0m7b947vglikp9Efpso94gt
Pour y ajouter des fichiers demandez-moi le ou sur la liste ou en privé, je
vous répondrez en privé.
