Yzis sort sa deuxième version

Posté par  (site web personnel) . Modéré par rootix.
Étiquettes :
0
10
août
2004
Technologie
Quatre mois après sa première version, le projet Yzis produit sa deuxième version (milestone M2) d'un éditeur compatible vi.

Yzis fournit un moteur vi générique et réutilisable, un front-end KDE et ncurses ainsi que l'intégration directe dans d'autres programmes KDE (Quanta, KDevelop)

Démarré par les auteurs de kvim, Yzis se distingue de vim, le principal éditeur compatible vi, par la réutilisation de technologies existantes et stables, comme le langage de script lua, ou le moteur de coloration syntaxique de kate. L'équipe d'Yzis a accueilli trois nouveaux développeurs, qui ont aidé à faire de cette nouvelle version un grand pas vers un éditeur de code moderne et robuste.

La liste des changements comprend :
- réduction du temps de démarrage et de la consommation mémoire (merci à valgrind et kachegrind)
- support du undo/redo
- scriptabilité en lua
- ajout d'un système de configuration
- réécriture du système de gestion des commandes pour plus de simplicité et d'extensibilité
- réécriture du système de rendu graphique
- gestion des modes visuels
- nouveaux mouvements
- support des registres
- plus de commandes compatibles vim
- fichier swap pour récupérer des données pendant un crash
- traductions
- impressions via Qt ou pslib
- macros
- polices à largeur fixe et variable


L'équipe a déjà commencé le travail sur la version suivante, qui sortira à la fin de l'année 2004.

Aller plus loin

  • # Hum, hum

    Posté par  . Évalué à 4.

    - fichier swap pour récupérer des données pendant un crash

    Je sais pas pour vous, mais généralement, mes données j'essais de les récupérer après un crash parce ce que _pendant_ le crash, la machine n'est plus trop utilisable ... à moins d'une feature révolutionnaire de la part de Yzis...
    • [^] # Re: Hum, hum

      Posté par  (site web personnel) . Évalué à 3.

      mhmm...

      Sans blague ? si tu as un terminal qui crash ça embarque ton noyeau et tout le toutim et tu peux plus utiliser ta machine ? Tu n'as pas le temps de voir juste une petit application planter parce que ton système s'emballe trop vite ? Ou alors quand tu as une appli qui plante ou une fenêtre qui joue à mister freeze tu te dis que c ta bécane qui déconne et tu appuies tout de suite sur reset ?
      • [^] # Re: Hum, hum

        Posté par  (site web personnel) . Évalué à 0.

        As tu pensé qu'il pouvait tourner uniquement avec un system tellement minimal que à par le kernel vi et emac il n avait pas grand chose ce qui signifit que forcement quand quelque chose plante ben y a pas grand chose a côté qui marche encore!!!!!!

        c'est bon je sort -------------->[]
      • [^] # Re: Hum, hum

        Posté par  (Mastodon) . Évalué à 3.

        je pense qu'il pensait à un crash de toute la machine.

        Personnellement, j'ai jamais vu un vi crasher. Alors s'ils sont pas capable de faire une éditeur compatible vi stable, je ne vois pas l'interêt du projet...
        • [^] # Re: Hum, hum

          Posté par  . Évalué à 3.

          Ben tout comme toi je n'ai jamais vu un vi (que ce soit nvi ou vim) se vautrer lamentablement. De plus après avoir récupérer ysis j'ai fait un test super simple, je lui ai demandé de m'ouvrir un fichier latex (.tex) dont la taille fait 34K, et bien ysis est lent. J'ai le temps (largement même puisque pas loins de la seconde) de voir toutes les lignes de mon terminal commencant par « ~ » puis de voir le contenu de mon fichier. Je n'ai jamais recontrer ce genre de soucis avec vim sauf sur de très très gros fichiers.

          J'ai préféré ne pas tester ysis avec de gros fichiers « apt-get remove --purge » on verra ce que cela donne dans la prochaine version.

          /me ne voit pas non plus l'intérêt de ce projet ...
          • [^] # Re: Hum, hum

            Posté par  (site web personnel) . Évalué à 5.

            Ce n'est que le debut. Vim est un vieil editeur qui a eu le temps de se bonifier au moins sur les aspects robustesse. Yzis y arrivera aussi, je n'ai aucun doute.

            L'interet de yzis, ce n'est pas de l'utiliser exactement comme vim. C'est vraiment les nouvelles possiblites que le projet offre:
            - un backend vi generique re-utilisable dans d'autres projets
            - une integration facile dans des bureaux graphiques
            - un langage de script plus evolue

            En tout cas, on note et on essaiera de faire mieux la prochaine fois.
          • [^] # Re: Hum, hum

            Posté par  . Évalué à 2.

            c'est cause par le syntax highlighting qui calcule toutes les lignes du fichier pendant le chargement.
            je dois pouvoir corriger ca dans la journee, c'est trivial ;)

            Cheers,
            Mik

            PS: pour tester , sudo mv $KDEDIR/share/yzis/syntax $KDEDIR/share/yzis/syntax.old, puis yzis ./configure (1Mo), moins d'une seconde pour le chargement chez moi.
          • [^] # Commentaire supprimé

            Posté par  . Évalué à 3.

            Ce commentaire a été supprimé par l’équipe de modération.

            • [^] # Re: Hum, hum

              Posté par  . Évalué à 1.

              Par ailleurs, l'utilisation du langage LUA pour le scripting est une bonne chose et ceux qui ont une fois dans leur vie tenté de faire des scripts avec le langage de Vim apprécieront grandement :)

              D'un côté, je suis bien d'accord parceque effectivement le langage de script de vim est vraiment pas terrible. D'un autre côté, il y a tellement de bons scripts déjà existants dans ce langage que c'est dommage de ne pas pouvoir les récupérer.

              En fait, LUA est sûrement un bon choix pour le long terme, mais seulement si Yzis attire suffisament d'utilisateurs avancés pour réimplémenter tout ce qui existe dejà de bon pour Vim.
        • [^] # Re: Hum, hum

          Posté par  . Évalué à 2.

          sous QNX vi plante, et quand il plante il emmene le fichier ouvert faire un voyage avec hâdes.

          c'est tjrs un plaisir de travailler avec qnx !
  • # Une question

    Posté par  . Évalué à 2.

    Pour la configuration, c'est les mêmes fichiers que pour vim ?

    J'ai pas trop cherché mais comme j'avais envie de m'y mettre pour voir un peu ce que ça valait...

    Le site ne répond pas chez moi alors pour aller pêcher dse infos, c'est pas évident...
    • [^] # Re: Une question

      Posté par  . Évalué à 4.

      pour l'instant la configuration est differente,
      mais on essaye de garder les memes noms pour les options.

      pour M4 on essayera de faire un systeme de compatibilite avec vim, pour lire et essayer de comprendre les .vimrc etc ...

      Cheers,
      Mik
  • # Y a plus qu'à...

    Posté par  (site web personnel) . Évalué à 6.

    avoir un front end GTK2 pour prouver que cette approche aurait dû être celle adoptée par le projet VIM.

    Je trouve ca dommage que l'auteur de VIM n'ait pas voulu se pencher sur les problèmes monstrueux d'architecture de VIM pour tout ce qui concerne son interfaçage avec le monde extérieur (ie: les toolkits visuels).

    Si Ysis arrive à compléter la boucle en proposant des frontends mieux intégrés que ceux de VIM (Qt, GTK2, Win32 etc...), belle preuve que leur choix avait été le bon.

    Spa tout ca, mais je sens que mon frontend GTK, je vais l'attendre un moment vu que les devs sont principalement des utilisateurs de Qt...
    • [^] # Re: Y a plus qu'à...

      Posté par  . Évalué à 5.

      ca ne devrait pas etre si complique.

      l'interface core<->GUI utilise tres peu Qt, justement pour simplifier l'integration avec d'autres toolkits,
      et en cas de probleme, on est toujours pret a faire les modifs necessaires pour permettre une integration plus facile ...

      il faut juste des volontaires qui connaissent gtk(2)(+) :)

      Mik
    • [^] # Re: Y a plus qu'à...

      Posté par  (Mastodon) . Évalué à 2.

      question bête :

      Quel est l'interêt d'une version de vim avec interface graphique ? Je n'arrive pas à voir ce que ça changerait par rapport à un vi ouvert dans un terminal sur le bureau.
      • [^] # Re: Y a plus qu'à...

        Posté par  . Évalué à 4.

        Réponse bête :

        Ne pas avoir besoin d'ouvrir un terminal sur le bureau .Je sais c'est dur mais il y a des gens qui ne connaissent pas xterm, rxvt, konsole, ... et c'est pas une raison pour les priver de vi.


        Si t'as encore un Win32 qq part essaye gvim pour windows, et tu verras le cote pratique
        • [^] # Re: Y a plus qu'à...

          Posté par  (Mastodon) . Évalué à 2.

          Pas besoin d'ouvrir le terminal, il suffit de créer un raccourci qui lance l'appli dans le term.

          J'ai essayé gvim, sans en voir l'interet non plus à vrai dire.
          • [^] # Re: Y a plus qu'à...

            Posté par  . Évalué à 1.

            ca on est d'accord, l'interet de gvim est nul ;)

            mais c'est justement parce qu'on peut rien en faire que c'est nul.

            alors que kyzis ....
            ben vous verrez bien ;)

            Cheers,
            Mik
      • [^] # Re: Y a plus qu'à...

        Posté par  (site web personnel, Mastodon) . Évalué à 5.

        Communiquer en harmonies avec le bureau ? Gérer correctement le copier-coller depuis les toolkits évolués ?

        Montrer au monde qu'on est pas débile au point de refuser le moindre confort.

        S'intégrer correctement dans des outils différents sous forme de composant.

        Je suis content qu'un proget fusionne enfin les idées de vi et scintilla. En fait, Yzis c'est surtout un Scintilla efficace ;)

        Troll detected --> []
        • [^] # Re: Y a plus qu'à...

          Posté par  (site web personnel) . Évalué à 4.

          - avoir des options visuelles plus avancees : le split vertical de vim est vraiment moche, en version graphique, on utilise un splitter Qt ou Gtk qui est plus propre

          - avoir acces a une palette plus large de couleur : le terminaux sont limites en nombre de couleur

          - avoir des menus et des barres d'outils

          - fournir une integration dans KDevelop et Quanta

          Je suis sur qu'on peut en trouver d'autres.
          • [^] # Re: Y a plus qu'à...

            Posté par  . Évalué à -1.

            - avoir acces a une palette plus large de couleur : le terminaux sont limites en nombre de couleur

            Quel est l'intéret dans un éditeur de texte d'avoir 32.10^6 couleurs ?

            - avoir des menus et des barres d'outils
            pour quoi faire ? Surement pour ne pas a avoir a chercher dans la doc la combinaison qui_va_bien.

            - fournir une integration dans KDevelop et Quanta
            Et si on utilise ni KDevelop et Quanta parce qu'il sont trop lourd ?

            Vi(m) est un éditeur de texte léger en mode console, sont job n'est certainement pas de devoir s'intégrer à 15T de projets différents.

            ps: un terminal, des terminaux ;)
            • [^] # Re: Y a plus qu'à...

              Posté par  . Évalué à 0.

              T'es pas force de l'utiliser.

              L'intégration a kmail, ou autres me parait etre une chose interessante.
            • [^] # Re: Y a plus qu'à...

              Posté par  . Évalué à 4.

              > Et si on utilise ni KDevelop et Quanta parce qu'il sont trop lourd ?

              Et si la sacrosainte légèreté n'était en fait pas une fin en soit ? Si l'important c'était plutôt d'avoir toujours l'outil le plus confortable pour faire ce qu'on a à faire, et que la légèreté n'était qu'un des élément de ce confort, mais pas forcement le plus important ? Et si un IDE bien lourdingue se révélait en fait plus adapté que Vim à certaines tâches ?

              > Vi(m) est un éditeur de texte léger en mode console, sont job n'est
              > certainement pas de devoir s'intégrer à 15T de projets différents.

              Dommage, parcequ'il y a clairement 15T de projets qui peuvent tirer parti d'un bon composant d'édition de texte. Enfin, c'est pas si grave, ce sera pas Vim mais Yzis, et puis voilà...
        • [^] # Re: Y a plus qu'à...

          Posté par  (Mastodon) . Évalué à 2.

          J'ai jamais rencontré ce légendaire pb de copier-coller, peux-tu me donner une procédure reproduisible ? Je fais pleins de copier-coller depuis des terminaux vers d'autres applis et inversement sans avoir de problèmes ? Avec quels toolkits (soit-disant) évolués ça ne fonctionne pas ?
        • [^] # Re: Y a plus qu'à...

          Posté par  . Évalué à -1.

          Communiquer en harmonies avec le bureau ? Gérer correctement le copier-coller depuis les toolkits évolués ?

          Hum, tout le monde n'utilise pas un bureau, le copier-coller .... mouais, bof

          Montrer au monde qu'on est pas débile au point de refuser le moindre confort.
          Tout dépend le sens du mot confort, perso, je trouve mes terminaux bien plus confortable que beaucoup d'interfaces graphique.

          S'intégrer correctement dans des outils différents sous forme de composant.

          Dans quel but ?
      • [^] # Re: Y a plus qu'à...

        Posté par  (site web personnel) . Évalué à 4.

        J'y vois un gros intérêt pour la gestion du rendu.

        En gros j'estime que vim est un bon editeur, mais les modes un peu complexes comme vimdiff pour faire des beaux merges etc etc, c'est limite imbitable. C'est d'ailleurs vraiment le dernier truc que je regrette depuis mon passage à vim depuis emacs (ediff rox).

        Avec un belle intégration des toolkits visuels, je pense que la vue du diff, l'application de chunks etc y gagnerait en visibilité et praticité. Tout comme avoir des vrais sous fenetres avec un ^Wv au lieu d'un canva texte splitté par d'horribles "|"... tout ca c'est typiquement le boulot des widgets, c'est pas le role du canva texte de faire ce rendu, hors dans VIM aujourd'hui, le canva texte melange choux et carrotes (c'est aussi un problème sous emacs mais dans une moindre mesure).
      • [^] # Re: Y a plus qu'à...

        Posté par  . Évalué à 2.

        « Quel est l'interêt d'une version de vim avec interface graphique ? »

        Ça depend de ton utilisation de vim, mais des interêts à utiliser gvim ( ou vim -g ) plutôt que vim, il y en a plein:

        - drag'n drop
        - utiliser le copier/coller de gnome (il y a des applis gnome trés pénible à utiliser avec le copier/coller façon X car ce qui est copié de cette manière reste copié que tant que la fenêtre reste ouverte)
        - eviter de devoir passer en mode commande pour certaines commandes souvent utilisées (undo/redo par example)
        - consommer un peu moins de mémoire ( ça depend du terminal )
              gvim: VSZ=16656
              xterm:7512 + vim: VSZ=13724 = 21236
        - editer des images xpm (si si ;-) )
        - etc...


        gvim /usr/src/linux/Documentation/xterm-linux.xpm
        ( Je trouve ça magnifique! :) )

         
  • # La même chose pour Emacs

    Posté par  . Évalué à 3.

    Quand est-ce qu'on aura emacs intégré dans KDE/Gnome...
    J'en ai marre des IDE qui proposent un énième éditeur...
    Les fans de vim ont de la chance!
    • [^] # Re: La même chose pour Emacs

      Posté par  (site web personnel) . Évalué à 1.

      De la chance oui, mais parfois j'enrage de cette chance. En particulier lorsque je colle un :wq dans un commentaire ou dans OOo en pensant que le monde entier possède un mode commande et un mode édition :)

      hop

      :wq <--- Celui-là c'est fait exprès
      • [^] # Re: La même chose pour Emacs

        Posté par  . Évalué à 1.

        ou quand je perdais tout ce que je venais de taper dans un TEXTAREA avec un IE (c'était avant Mozilla) sous Ouinouin parce que j'avais eu la bonne idée de taper sur ESC...

        Le Ctrl-Z permettait de retrouver ce qui avait été effacé, mais j'ai perdu deux ou trois articles sur mon SPIP comme ça...

        Et je ne parle pas comme Denis des « ZZ » dans Word parce que j'ai dû vouloir quitter et enregistrer...

        Ah, il y a tout de même un avantage à gvim : ça tourne sous Windows.

        CU

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.