IT-edit, un éditeur de texte avec terminaux intégrés

Posté par (page perso) . Édité par ZeroHeure, palm123, Nÿco, Benoît Sibaud et tuiu pol. Modéré par ZeroHeure. Licence CC by-sa
30
17
avr.
2015
Bureautique

Je viens vous présenter ma dernière création, IT-Edit un éditeur de texte avec de multiples fonctionnalités. Créé avec GTK+3, gtksourceview3.0 et libvte.
IT-Edit (Integrated Terminal Editor) est un éditeur de texte avec terminaux intégrés et bien d'autres fonctionnalités pratiques.

IT Edit

Motivation pour l'écriture de IT-Edit

On peut diviser les programmeurs selon leur façon de travailler en deux catégories :

  1. ceux qui utilisent un IDE : un environnement de développement complet.
  2. ceux qui travaillent avec des outils séparés : un éditeur de texte, usage du terminal et autres outils.

Comme je suis un programmeur de la deuxième catégorie et comme j'ai remarqué que j’utilisais souvent un client Internet pour la doc HTML offline, j'ai décidé d'écrire mon propre éditeur de texte qui me donne un accès direct à tous les outils dont j'ai besoin.

Fonctionnalités

Classiques

IT-Edit implémente un éditeur de texte avec coloration syntaxique, affichage des numéros de lignes et complétion automatique avec les fonctionnalités de base d'un éditeur de texte (couper / copier / coller ; dupliquer la sélection ou la ligne du curseur ; annuler / refaire ("undo / redo") ; aller à une ligne donnée ; recherche et remplacement) et de gestion de fichiers (sauvegarder tous les fichiers ouverts).

Terminaux

IT-Edit implémente deux terminaux dans la fenêtre principale qui sont aisément déployables, repliables et peuvent être redimensionnés. Vous pouvez y lancer une commande quelconque exécutée dans une fenêtre du plus haut niveau qui est facilement maximisable, minimisable et redimensionnable.

Note : cette fonctionnalité d'abord prévue pour la visualisation de pages de man a été étendue a toutes sortes de commandes, sans restriction.

Types de fichiers

IT-Edit implémente un mécanisme d'enregistrement de fichiers quelconques (doc HTML, PDF, PS ou musique, vidéo…) qui après enregistrement seront lançables par le programme associé au type de fichier.

Note : cette fonctionnalité était prévue pour la visualisation de documentation offline HTML qui a été étendue.

IDE

Avec ses terminaux intégrés IT-Edit vous fournit un environnement de développement, répondant à tous vos besoins.

Essayez

Prenez la peine d'essayer IT-Edit, vous allez sûrement l'adopter…

Paquetages

Le programme est distribué sous forme de paquetage *.deb, si cela ne vous convient pas, il existe une archive tarball (*.tgz) compatible Linux et BSD (non-testé). Pour installer IT-Edit tapez :

$ ./configure
$ make
$ sudo make install

Appel à contrib

Je suis ouvert à toutes formes de critiques, si vous avez des commentaires à faire sur le code, les fonctionnalités auquelles je n'ai pas pensé, etc.

Scratch your own itch

PS : J'ai vraiment écrit ce pseudo IDE pour mes propres besoins, mais je tiens à vous en faire profiter, quand même, afin qu'il évolue selon les fondements du logiciel libre.

  • # Je rigole ;-)

    Posté par . Évalué à 6.

    On peut diviser les programmeurs selon leur façon de travailler en deux catégories :
    - ceux qui utilisent un IDE : un environnement de développement complet.
    - ceux qui travaillent avec des outils séparés : un éditeur de texte, usage du terminal et autres outils.
    Comme je suis un programmeur de la deuxième catégorie

    La phrase aurait pu se terminer en :
    "j'ai créer un outil pour ressembler à ceux de la première catégorie" :-D

    Sinon ton logiciel à l'air sympa sans être overkill.

    Juste une petite question, quand tu dis : "complétion automatique" c'est valable pour tous les langages ? et si oui selon quels critères, cela fait il de l'autocomplétion de méthodes ou d'attributs d'objets définis dans d'autre fichiers du même répertoire ou ouvert dans la même session ?

    kentoc'h mervel eget bezan saotred

    • [^] # Re: Je rigole ;-)

      Posté par (page perso) . Évalué à 2.

      Merci pour vos nombreux commentaires, je vais répondre a chacun qui a poser une question brièvement.

      En faite la complétion automatique est prise en charge pour n'importe quel type de fichier.

      Car l'auto-complétion est régulièrement mise a jours avec le contenus du fichier courant.
      Le contenus du GtkTextBuffer est analyser et les possibilités d'auto-complétion mise a jours.

      En faite il y a un "objet" d'auto-complétion pour chaque fichier ouvert.
      Dommage car si l'on bosse sur un projet et que le mot est contenus dans un autre fichier il n'apparaît pas dans la liste d'auto-complétion.

      L'auto-complétion apparaît après que l'on ai taper 3 lettres.
      Pour qu'un mot soit pris en compte, ben il faut que ça soit un mot dans le terme informatique (séparateurs comme '_' ou '->' compris.

      Pour en savoir plus voir ici.

      Merci pour vos commentaires.

  • # icônes KDE ?

    Posté par . Évalué à 10.

    Salut, beau travail.

    Je trouve très rigolo d'utiliser des icônes KDE sur un logiciel en GTK. Les gnomistes vont être content ! Pourquoi ce choix ?

    Ton logiciel peut-il se comparer à Kate, l'éditeur de texte de KDE rempli de fonctionnalités ?

    Titre de l'image

  • # Un dépôt ?

    Posté par (page perso) . Évalué à 3.

    Oh que c'est intéressant. Sur ma Debian 8 64 bits, j'ai un segfault, du coup je ne peux pas trop en dire plus si ce n'est que l'idée me plait beaucoup, je suis du même genre que toi :)
    As-tu prévu de le déployer sur GitHub ou un équivalent afin que nous puissions aisément avoir accès au code et proposer des patchs ?

    • [^] # Re: Un dépôt ?

      Posté par (page perso) . Évalué à 1.

      Merci pour vos nombreux commentaires, je vais répondre a chacun qui a poser une question brièvement.

      Oui il y a un dépôt sur github.

      PS: il y a quelqu'un qui est en train de relire mon code en ce moment et quelque imperfections vont être corriger.
      Et donc il y aura un peu d'amélioration.

      Il m'est arriver aussi une fois d'avoir une erreur de segmentation mais je pense que c'est dû au type de fichier:
      un fichier Makefile.am.

      Sinon tu pourrait ouvrir un terminal et lancer le programme en ligne de commande:

      $ IT-Edit mon_fic.txt

      Normalement le programme devrai afficher sa configuration sur stdout.

      Peut-être que ca fonctionne comme ça.

      Merci pour vos commentaires.

      • [^] # Re: Un dépôt ?

        Posté par (page perso) . Évalué à 1.

        J'ai corrigé l'erreur, je ferai un PR une fois que le code aura été revu ;)

        • [^] # Re: Un dépôt ?

          Posté par (page perso) . Évalué à 1.

          Bonjours,

          Je suis très intéresser par l'erreur en question du plantage ou plutôt pourquoi le programme provoquait une erreur de segmentation.

          Pourriez vous me dire la partie de code incriminé.

          Et comment vous avez réussis a faire fonctionner le programme: ce que vous avez corriger.

          PS: c'est quoi un PR ?

          Merci de bien vouloir me tenir informer, ce serai vraiment gentil de votre part.

          • [^] # Re: Un dépôt ?

            Posté par (page perso) . Évalué à 3.

            PS: c'est quoi un PR ?

            Pull Request dans la terminologie git.

            « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

  • # coloration syntaxique

    Posté par . Évalué à 3.

    Souvent quand j'édite des fichiers ésotérique, je rêve d'une coloration syntaxique "générique".

    Les commentaires ont seulement quelques variantes, les string une ou 2, les chiffres sont toujours à part, les séparateurs comme {}[] peuvent aussi encore avoir une autre couleur etc…

    "La première sécurité est la liberté"

    • [^] # Re: coloration syntaxique

      Posté par . Évalué à 3.

      C'est à peu près ce que fait vim avec sa syntaxe "conf". Je ne sais pas sur quels critères il l'utilise automatiquement par contre.

  • # Gestionnaire de fenêtre pavant - Tiling window manager

    Posté par (page perso) . Évalué à 10. Dernière modification le 17/04/15 à 17:22.

    Pourquoi ne pas simplement utiliser un gestionnaire de fenêtre pavant qui permet très facilement de réaliser cela et sera probablement beaucoup plus puissant à l'usage puisque non limité dans ce qu'il est possible d'ouvrir dans chaque "partie" ?

    J'utilise à l'heure actuelle https://i3wm.org/ qui me plaît beaucoup, mais il en existe de nombreux autres. Par exemple :

    • [^] # Re: Gestionnaire de fenêtre pavant - Tiling window manager

      Posté par (page perso) . Évalué à 7.

      On peut diviser les programmeurs selon leur façon de travailler en deux trois catégories :

      1. ceux qui utilisent un IDE : un environnement de développement complet.
      2. ceux qui travaillent avec des outils séparés : un éditeur de texte, usage du terminal et autres outils.
      3. ceux qui utilisent un IDE et des terminaux, et un éditeur de texte, et d'autres outils.

      On peut aussi utiliser un multiplexeur de terminal, comme Tmux.

      Personnellement je préfère le gestionnaire pavant, qui est souvent plus pratique à manipuler. Mais la combinaison Tmux + gestionnaire de fenêtres pavant ça « enlarge » ta productivité de façon étonnante.

      Autre avantage du gestionnaire de fenêtres : tu peux facilement scripter le comportement des fenêtres (par exemple garder ton éditeur à gauche, en position fixe, sur 75% de l'écran, et changer dans l'espace restant entre terminal, navigateur et autres outils).

      • [^] # Re: Gestionnaire de fenêtre pavant - Tiling window manager

        Posté par (page perso) . Évalué à 1.

        Salut,
        Juste pour infos les 3 principales fenêtres sont aussi redimensionnables.
        Et si je veut intégrer des fenêtres pavant dont je suis pas sur d'avoir saisie le sens exact, il faudrait que GTK+3 l'implémente.
        Merci pour vos commentaires.

        • [^] # Re: Gestionnaire de fenêtre pavant - Tiling window manager

          Posté par (page perso) . Évalué à 1.

          En réalité, il s'agit de remplacer entiérement la gestionnaire de fenêtre du bureau. Ce n'est pas spécifique à une application.

          L'idée est qu'au lieu d'avoir des fenêtre que l'on peut librement déplacé à l'écran, elles sont placés de manière à recouvrir le maximum possible de surface et suivant des règles que l'on peut définir.

          Pour avoir le même configuration que sur la capture d'écran du journal, je lance donc mon éditeur de texte et 2 émulateurs de terminaux (3 processus distincts donc), et le gestionnaire de fenêtre va se charger de les placer exactement de la même manière. L'avantage est que la même disposition est possible quel que soit les applications.

          On peut trouver des exemples des possibilités ici : https://i3wm.org/screenshots/#

      • [^] # Re: Gestionnaire de fenêtre pavant - Tiling window manager

        Posté par . Évalué à 1.

        Mais la combinaison Tmux + gestionnaire de fenêtres pavant ça « enlarge » ta productivité de façon étonnante.

        Je suis aussi utilisateur d'un gestionnaire de fenêtres pavant (i3wm en l’occurrence) donc pas de question sur ce point. :)

        Par contre pour Tmux, je suis curieux de savoir quelle utilisation tu en as.
        Ce que je vois, c'est qu'il peut servir pour conserver une session distante ouverte (pour s'y —re—connecter en SSH à tout moment) ou comme alternative aux onglets dans le terminal. Tu en fais peut-être autre chose ?

        • [^] # Re: Gestionnaire de fenêtre pavant - Tiling window manager

          Posté par . Évalué à 1.

          Tmux permet aussi la séparation de ton Terminal en grille. Donc si tu utilise Vim par exemple tu peux avoir le même genre de configuration que se soit en locale ou en distant. Tu peux même avec un peu de config passer d'un panneau Vim (split) a un panneau Tmux avec le même commande (Alt+flèches). C'est vraiment super pour améliorer la façon de travailler avec le terminal et avec SSH les possibilités sont énormes.

          Un petit tuto: https://www.ocf.berkeley.edu/~ckuehl/tmux/

          • [^] # Re: Gestionnaire de fenêtre pavant - Tiling window manager

            Posté par . Évalué à 2.

            Ça m'intéresse de voir comment tu fait pour avoir le même raccourcis pour passer d'un panneau Tmux à l'autre ou d'un panneau vim à l'autre. Fut un temps j'avais testé tmux, mais entre i3, tmux et vim, je finissais par me perdre pour passer d'une fenêtre à l'autre. L'idéal pour moi serait de pouvoir le faire de façon modale (touche1 puis hjkl).

            bépo powered

            • [^] # Re: Gestionnaire de fenêtre pavant - Tiling window manager

              Posté par (page perso) . Évalué à 2.

              L'idéal pour moi serait de pouvoir le faire de façon modale (touche1 puis hjkl).

              Haaaa ! Enfin quelqu'un qui partage ma religion :)

              C'est précisément ce que je faisais du temps où j'étais autorisé à travailler sous Linux, avec la lib furious pour Awesome notamment.

              C'est un peu lourd à configurer, j'ai pas eut le temps de bien travailler dessus, mais c'est juste trop bon !

        • [^] # Re: Gestionnaire de fenêtre pavant - Tiling window manager

          Posté par (page perso) . Évalué à 2.

          Par contre pour Tmux, je suis curieux de savoir quelle utilisation tu en as.
          Ce que je vois, c'est qu'il peut servir pour conserver une session distante ouverte (pour s'y —re—connecter en SSH à tout moment) ou comme alternative aux onglets dans le terminal. Tu en fais peut-être autre chose ?

          Je pousse ça plus loin on va dire. L'idée c'est altimux. En fait ça me sert à n'avoir qu'un seul terminal en tout et pour tout. Aprés on a des sessions et des fenêtres (au sens tmux) et des panes (le tiling, que j'utilise très peu). Sauvegarder toutes ces configs, utilisez un outil qui permet de charger tout ça en une commande et vous aurez un environnement très puissant.ça plus tard. En avant gout : un raccourcis de genre Mod T + M, permet de mettre le focus sur le terminal avec Awesome, puis de charger la fenêtre de Mutt (client mail) dans le terminal. Il y a un raccourcis par tâche "utile" dans le terminal. C'est puissant :)

          Je manque de temps, mais je décrirais la puissance de tout ça un peu plus tard.

  • # Un clone de vieux éditeurs ? Pourquoi ?

    Posté par . Évalué à 6.

    Bonjour,

    Marrant de voir ton éditeur, cela ressemble à ce que emacs (voir même vi) font depuis 30 ans.
    Pourquoi as tu décidé de la faire, pour le fun ou pour d'autres raisons ?
    Plus dans une approche clickodrome que raccourcis clavier ?


    Sinon, comme on est vendredi, je résiste pas pour la suite.
    Trouverez vous le nombre de trolls cachés dans la suite de ce post ?

    On peut diviser les programmeurs selon leur façon de travailler en deux trois quatre catégories :
    1. ceux qui utilisent un IDE : un environnement de développement complet.
    1. ceux qui travaillent avec des outils séparés : un éditeur de texte, usage du terminal et autres outils.
    1. ceux qui utilisent un IDE et des terminaux, et un éditeur de texte, et d'autres outils.
    1. ceux qui utilisent Emacs, un vrai éditeur de texte sachant dialoguer avec des outils externes

    Allez, je retourne dans mon emacs ! Ah, ben je l'avais même pas quitté en fait ;-)

    • [^] # Re: Un clone de vieux éditeurs ? Pourquoi ?

      Posté par . Évalué à 1.

      Et dans la première partie de ton post, on peut trouver des trolls aussi ? :)

      • [^] # Re: Un clone de vieux éditeurs ? Pourquoi ?

        Posté par . Évalué à 1.

        Et dans la première partie de ton post, on peut trouver des trolls aussi ? :)

        On peut aussi ;-), mais je suis vraiment intéressé par la réponse de l'auteur sur ses motivations à développer ce type d'éditeur.

        • [^] # Re: Un clone de vieux éditeurs ? Pourquoi ?

          Posté par (page perso) . Évalué à 2.

          Bonjours,

          Et bien cela est expliqué dans la dépêche, il y a une section nommer:

          Motivation pour l'écriture de IT-Edit.

          En faite je me suis construit un environnement de développement répondant entièrement a mes besoins:

          -) Fonctions d'éditeur de texte.
          -) 2 Terminaux intégrés dans l'interface, dépliable et repliable.
          -) La possibilité de lancer une commande, dans un terminal toplevel,
          a la base ca devait être spécifique aux manpages mais j'ai décider de ne pas limité la fonctionnalités a cela,
          (que l'on peut redimensionner, maximiser, minimiser. L'on pourrait donc laisser une manpage ouverte par exemple, en la laissant minimiser).
          -) La possiblité d'enregistrer des fichiers, qui sont ouvert par le programme par défaut du type de fichier.
          C'était a la base pour la doc offline HTML, mais j'ai décider de pas limité la fonctionnalité a ça, du coup on peut enregistrer le fichier qu'on veut comme par exemple de la doc sous forme de *.pdf.
          Etc…

          • [^] # Re: Un clone de vieux éditeurs ? Pourquoi ?

            Posté par . Évalué à 1.

            Merci pour ta réponse. J'avais bien lu ta partie motivation.
            Mon interrogation était que, comme dans les vieux éditeurs (Emacs par exemple), toutes les fonctionnalités que tu as développées (accès à des terminaux, parcours de documents html, pdf et man, parseur générique…) sont déjà dispo, je cherchais à connaître les raisons qui t'ont poussé à redévelopper des choses déjà existantes. Cela pourrait être la non connaissance de ces fonctionnalités dans ces "vieux" éditeurs, le plaisir de développer, le fait que ces vieux éditeurs sont trop basés sur des raccourcis clavier, la complexité de leur paramétrage… ou peut être tout autre chose ?

            • [^] # Re: Un clone de vieux éditeurs ? Pourquoi ?

              Posté par (page perso) . Évalué à 3.

              Pour être plus précis,

              je me répète peut-être mais c'était dans le but d'avoir un éditeur sur mesure et surtout bien sur pour le plaisir de développer.

              Par exemple dans la capture de kate qu'il y a dans les réponses, je pense que le terminal intégrés est mal placer et trop petit.

              Tu te voit faire "ls -1" là dedans a moins de le redimensionner, mais ça empièterait sérieusement sur l'éditeur.

              Dans tout les éditeurs dont je me suis inspiré l'implémentation du terminal ne me plaisait pas.
              Et il y a bien sur d'autres détails.

              Après il est vrai que IT-Edit n'est qu'un autre éditeur qui embarque entre autre un terminal (pardons deux).
              Mais qui connais mieux son éditeur que celui qui l'a développer.

              Mais je l'ai développer exactement pour mes besoins et je me suis vraiment poser la question si j'allais le distribuer ou être l'unique utilisateur.
              Mais si il vous convient et bien tant mieux,
              je sais qu'il n'est pas facile de changer d'éditeur comme ça il faut l'essayer afin de s'adapter et surtout le vouloir un peu.

              Et d'ailleurs je ne savait pas du tout que toutes les fonctionnalités que j'ai développées (accès à des terminaux, parcours de documents html, pdf et man, parseur générique…) sont déjà disponible dans d'autres éditeur.

  • # Neovim

    Posté par (page perso) . Évalué à 6.

    En parlant d'éditeurs avec des terminaux, il est intéressant de noter que Neovim a fait le même choix récemment. Ils ont dégagé l'ancienne émulation des terminaux présente dans Vim pour la remplacer par la libvte. Et pour l'utiliser, ça marche pas mal du tout !

  • # libgedit

    Posté par (page perso) . Évalué à 4. Dernière modification le 19/04/15 à 18:53.

    Cool, un autre éditeur de texte basé sur GtkSourceView.

    Sache qu'il y a le projet libgedit (dont je suis l'initiateur), qui vise à rendre le code de gedit réutilisable pour d'autres éditeurs de texte, en bougeant les fonctionnalités dans GtkSourceView notamment.

    Pcq, tu as sans doute pu le remarquer, écrire un éditeur de texte from scratch avec GtkSourceView demande quand même pas mal de boulot, pour avoir une éditeur de texte convenable. gedit fait 40k lignes de code plus ou moins (sans les plugins), donc il reste encore du refactoring à faire ;-)

    « Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)

  • # Ouais bof

    Posté par . Évalué à 2.

    Personnellement je trouve très pratique de faire "Alt+tab" pour avoir mon terminal. En plus cela me permet de développer en live avec Vim ou en local avec gedit…

    J'avoue qu'il y a un éditeur montant pas mal c'est "Sublime text". Il permet avec un système de plugin d'ajouter beaucoup de choses pilotable en ligne de commande et il a de vrai nouvelles fonctionnalités a la Excel pour du copier-coller incrémentale. Un vrai mixte. Son seul point faible est de na pas être open-source mais il est binairement compatible Linux (sans passer par Wine.)

  • # Merci pour vos réponses et le futur de IT-Edit.

    Posté par (page perso) . Évalué à 1.

    Merci pour vos nombreuses réactions, commentaires, critiques et avis.

    J'espère avoir répondus correctement a tout le monde qui a posé une question et j'ai découvert le concept de gestionnaire de fenêtre pavant de part cette discussion.

    Et si l'on pensait un peu a l'avenir de IT-Edit si cela vous intéresse.

    J'ai penser a étendre IT-Edit grâce a système de plug-in ce qui donnerai un sérieux coup de pouces a la popularité de IT-Edit (d'ailleurs plus de 400 téléchargements du fichier *.deb est largement plus grand que mes attentes).

    Le problème avec un système de plug-in est que je ne voit pas du tout en tant que programmeur (de niveau intermédiaire en C) comment l'implémenter.

    Peut être créer un type de fichier spécifique qui dont le contenus serai exécuter lors du chargement du plug-in ?

    Bref si vous savez comment ont implémente un système de plug-in pour un programme en théorie vous seriez sympa de m'éclairer.

    PS: bientôt sortira une nouvelle version mineur de IT-Edit qui concerne en l'amélioration du code mais ne change rien a l'utilisation du programme.

    Merci pour vos réponses éclairées.

    • [^] # Re: Merci pour vos réponses et le futur de IT-Edit.

      Posté par (page perso) . Évalué à 1.

      Utilise libpeas pour les plugins, c'est ce qui est utilisé dans gedit et d'autres applications de GNOME (libpeas provient du code de gedit à la base).

      Mais, avoir un système de plugin rajoute beaucoup d'emmerdes pour le développement d'une application. Il faut que l'application définisse une API que les plugins pourront utiliser. Et, si possible, cette API ne doit pas être cassée à chaque version… Comme pour le développement d'une librairie, en gros. Avec l'age, n'importe quel code a besoin d'être restructuré un jour ou l'autre, et maintenir la compatibilité des plugins est parfois difficile et demande en tout cas plus de boulot.

      De plus les plugins rajoutent de l'incertitude dans la stabilité de l'application. Toi, étant développeur de l'éditeur de texte, tu veux être certain que l'application soit stable, qu'il n'y ait pas de bugs. Avec des plugins, il peut y avoir plein de bugs imprévus. Les plugins sont généralement moins bien écrit et contiennent plus de bugs que le cœur de l'application (pcq développé par des gens moins expérimenté). Un cassage de l'API ne fait qu’aggraver les choses. Et les bugs ne sont pas forcément isolé à la fonctionnalité qu'un plugin fourni, un plugin peut faire apparaitre des bugs dans d'autres fonctionnalités. Et quand un utilisateur a plein de bugs et qu'il n'en connait pas vraiment la cause, il se dit que l'application est pourrie et va voir ailleurs.

      Donc… je ne recommande pas vraiment les systèmes de plugins. En tout cas certainement pas pour une jeune application dont l'architecture du code doit encore évoluer.

      Ceci dit, pour en revenir à libpeas, ça utilise sous le capot dlopen(), pour charger des shared libraries au runtime. Un plugin est donc une sorte de librairie.

      « Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)

      • [^] # Re: Merci pour vos réponses et le futur de IT-Edit.

        Posté par (page perso) . Évalué à 1.

        Merci pour le conseil,
        et des conséquences de l'implémentation d'un système de plug-ins.

        Tu a sûrement raison surtout que je n'ai pas le niveau pour le faire tout simplement (2 ans et quelques de C).

        Mais j'aimerai quand même que le programme évolue: je pense a des fonctions d'éditions supplémentaires demander ou implémenter par les quelques utilisateur de IT-Edit car soyons honnête IT-Edit est un éditeur de texte lightweight, programmer par un amateur passionner, mais qui a ses atouts malgré tout.

        Soit dit que le code va subir de léger changements dans la version distribuer afin de gommer quelques imperfections.

        D'ailleurs merci a la personne, que je ne citerai pas, qui a entièrement relus mon code et détecter les imperfections.
        En faîtes j'attends sa réponse pour publier une mise a jours.

        Bon comme cette dépêche descend dans les gouffres du site, je propose de clore la discussion.

        Encore grand merci a cet inconnus pour le travail effectuer et adapter IT-Edit a vos besoins soit en configurant les options disponible ou si vous connaissez GTK+3 en implémentant vos propres fonctions.
        Merci de me contacter si vous désirez partager vos améliorations.

        Et merci a tous ceux qui ont participer a la discussion.

Suivre le flux des commentaires

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