• [^] # Re: On peut faire pareil avec un traitement de texte

    Posté par . En réponse à la dépêche Il n'y a pas que le traitement de texte pour manipuler du texte !. Évalué à 6.

    Sans vouloir rentrer dans un troll (velu, forcément), je note plusieurs erreurs dans l'article qui, malgré certaines qualités didactiques, le désserve :
    - parti pris pour vi* et [x]emacs par rapport à d'autres editeurs proprio ou libre existant (jext, ultraedit, etc.). De fait l'accumulation de références spécifiques aux Unices ou non|peu intuitifs (emacs) déconcèrnent l'utilisateur Windows de base (framasoft est pro-LL, mais clairement orienté windows.)
    - oubli primordial : .RTF == Rich Text File, format d'echange standard des documents formatés. Effectivement, ce n'est pas forcément adapté à tous types de documents (rapports, document hierachisés), mais malheureusement il est souvent ignoré. un jour, envoyant un CV au format rtf, on m'a répondu en demandant un format standard (.doc). argh.
    - traitement de texte :
    * moins puissant : A remplacer par "moins spécialisé"
    * plus sujet à plantage : forcément plus de code, donc plus de bug. Cela dit, les bugs visibles sont probablement sur les parties les plus "tricky" du documents, pas sur les fonctions basiques "editeur de texte".
    * taille des fichiers : la comparaison (*44, *144) est trompeuse car l'ordre donné est basé uniquement sur un texte de quelques charactères, ce qui n'est pas réaliste. Sur un rapport ou une note de service le ratio est entre 3 et 20. Et ne pas oublier les fonctionnalités tres utiles tel que le versioning qui rajoutent un poid au fichier, mais qui sont non égalées aujourd'hui (ok, crms et wiki...).
    - avantage edieur de texte/légèreté :
    * point soulevé précédement : 50Mo pour un traitement de texte, faut vraiment etre un util de MS-W pour le croire. Et 8Mo pour ecrire "hello world" je suis sur qu'il y a plus légé (et convivial) qu'Emacs, malgré toutes ses qualités.
    * 50 * 10 < 500. La tendance actuelle des logiciels est au multi-thread, CAD qu'une seule instance de l'application est chargée, donc que l'occupation mémoire est bien moindre.
    - "cat p1 p2 [..] p5 > final.txt". Je suis désolé que l'auteur de l'article ne maîtrise pas Word ou OOo, mais il est tout a fait possible d'avoir un document (appelons le final.doc) regroupant plusieurs parties (p1.doc [..] p5.doc) avec un méchanisme d'include.
    - mise en forme : il met en exergue 3 parties distinctes (saisie, mise en forme, publication). Helas, la saisie et la mise en forme sont forcément imbriqué puisqu'on doit hierachiser l'info (meme dans un doc HTML) -> title, hint, mainpart, keyword, subpart ...). Pour un doc xHTML, la mise en forme correspond a la conception du CSS. En travaillant proprement avec OOo ou Word, on est tout a fait capable d'entrer dans ce procéssus, a ce détail pres qu'il est préférable de faire la mise en forme avant de taper son texte (préparer ses styles).
    -Portabilité-Interopérabilité : format txt portable ??? du fait de certains jeux de charactere, ok si on se réfère uniquement à l'ASCII.


    NB : je suis d'accord sur le fond de l'article, pas sur la forme trop partisanne qu'il adopte. Cette derniere le discalifie d'emblé aux yeux d'un public "basique". Et nous, nous sommes déjà convaincu donc a quoi bon.

    --
    désolé pour les fautes, mais apres 4g je maîtrise plus trop ...