12
votes

Bon moyen de sauvegarder des données lors de la rédaction d'un éditeur de texte

Je prévois de faire un éditeur de texte en c. Alors je voulais juste savoir quelle structure de données est bon pour enregistrer le texte. J'ai lu en utilisant la liste liée était une façon de le faire, mais pas efficace. S'il vous plaît, signalez-moi quelques références où je peux avoir une bonne idée de ce qui doit être utilisé. Je prévois d'utiliser la bibliothèque NCurses pour obtenir la saisie de l'utilisateur et de capturer les clés et l'interface utilisateur.

L'utilisation du code source des éditeurs existants est en quelque sorte trop complexe, tous les éditeurs de texte sont énormes, même les éditeurs de la console. Tout code source de la console simple pour référence?


3 commentaires

Vous semblez désirer un bon moyen de Store Data, comme l'économie de l'enregistrement de l'écrire à un fichier (qui ne doit pas nécessairement impliquer des structures de données dans votre programme). (Bonne question cependant.)


Wow ... Je pensais juste à cette question littéralement hier. +1 pour lire mon esprit.


Vous pouvez consulter ed (l'éditeur de texte standard). ed est orienté ligne et ses internes devraient être assez simples. Et pour ceux qui ont un sens de l'humour: gnu.org/fun/jokes/ed .msg.html


5 Réponses :


8
votes

Vous bénéficierez de Lecture sur les tampons EMACS . Voir également Ce blog , surtout le dernier commentaire, cité ici Pour une référence facile:

De nombreuses versions de EMACS, y compris GNU, utilisent une matrice de caractères unique contiguës virtuellement divisée en deux sections séparées par un intervalle. Pour insérer, l'écart est d'abord déplacé au point d'insertion. Les caractères insérés se remplissent dans l'espace, réduisant ainsi sa taille. S'il y a un espace insuffisant pour maintenir les caractères, tout le tampon est réaffecté à une nouvelle taille plus grande et que les lacunes sont fusionnées au point d'insertion précédent.

Le regard naïf à cela et dire que la performance doit être médiocre à cause de tout la copie impliquée. Tort. L'opération de copie est incroyablement rapide et peut être optimisée de différentes manières. Les tampons d'écart profitent également des modèles d'utilisation. Vous pouvez sauter sur toute la fenêtre avant de vous concentrer et d'insérer du texte. L'écart ne se déplace pas pour l'affichage - uniquement pour insertion (ou supprime).

D'autre part, l'insertion d'un bloc de caractères à la tête d'un fichier de 500 Mo puis de l'insérer une autre à la fin est le pire des cas pour l'approche d'écart, en particulier si la taille de l'écart est dépassée. À quelle fréquence cela se passe-t-il?

Les blocs de mémoire contiguë sont prisés dans des environnements de mémoire virtuelle car moins de pagination sont impliqués. De plus, les lectures et les écrit sont simplifiés car le fichier ne doit pas nécessairement être analysé et divisé en une autre structure de données. Au contraire, la représentation interne du fichier dans le tampon GAP est identique au disque et peut être lu et écrite de manière optimale. Les écritures peuvent être faites avec un seul appel système (sur * Nix).

Le tampon GAP est le meilleur algorithme de modification du texte de manière générale. Il utilise la moindre mémoire et présente la performance globale la plus élevée sur une variété de cas d'utilisation. Traduire le tampon Gap en une fenêtre visuelle est un peu plus difficile car le contexte de la ligne doit être constamment maintenu.


7 commentaires

L'affirmation selon laquelle l'algorithme de l'écart est la meilleure des ordures prises, perpétuées par les fans d'Emacs depuis des décennies. Je suis un fan d'emacs, mais la réclamation est toujours des ordures. L'approche "Cordes", avec soldes Les arbres binaires contenant des tableaux de caractères au lieu de caractères uniques dans les feuilles, sont évidemment optimaux d'un point de vue théorique, et si vous augmentez suffisamment la taille de la feuille, tout facteur constant désagréable peut être fait arbitrairement petit.


@R .. Je n'en doute pas, mais c'est une structure assez simple qui répondra à la plupart des besoins des peuples. Je recommanderais que quelqu'un de nouveau dans le texte d'édition envisager de mettre en œuvre quelque chose de simple et simple, puis de mesurer les performances pour voir si un délai de développement et de test supplémentaires étaient nécessaires. "Optimisation prématurée ..." et tout ça.


Moi aussi je ne suis pas si gros fan de cette approche. Il semble un peu trop complexe et n'est pas très efficace dans certains cas.


Merci pour le lien Vijay Mathew. Je vais l'utiliser comme une référence.


@Adam Davis merci pour la modification. En fait, vous avez montré comment faire des liens externes plus utiles pour les lecteurs.


Pour un projet d'apprentissage comme celui-ci, Gap est la voie à suivre. Il transforme votre opération de sauvegarde en 2 iOS.


Je vois l'écart comme un gaspillage de complexité pour presque pas de gain. Au lieu d'effectuer un Memmove extrêmement coûteux sur chaque insertion, vous ne l'exécutez que tous les N insertions. Toutefois, la convivialité est perçue en termes de consistance et de pires retards. Si le fichier est si mauvais que Memmove est perceptible, vous avez vraiment besoin d'un meilleur algorithme. Si ce n'est pas le cas, le seul avantage de l'écart consiste à économiser sur Total le temps de processeur dépensé (peut-être pour des économies d'énergie / batterie ou pour les processus d'arrière-plan pour finir plus rapidement).



3
votes

Si vous voulez que ce soit à l'échelle, vous devez utiliser une forme d'arbre binaire équilibré. Il est possible de le faire si fondamentalement tous les opérations insertion, Supprimer, chercher à caractère, chercher à la ligne, etc. - sont O (journal n) . Si vous ne vous souciez que des tailles de fichiers «Sane» pour le texte (quelques Megs maximum), cela ne comporte pas vraiment des structures que vous utilisez.


1 commentaires

Merci r .. je veux d'abord commencer petit ... Faites-le travailler en utilisant la meilleure façon possible du cas au cas où j'ai envie de le mettre à l'aise plus tard ....



0
votes

Ce lien offre une bonne information - une étude de cas dans la conception d'un "What-You-You-See-is-What-You-obtenez" (ou "WYSIWYG") Editeur de document


1 commentaires

Malheureusement, le lien est mort



1
votes

Vous devez "enregistrer" les données comme texte brut. Si vous voulez dire comment stocker les données en mémoire, je recommande une simple liste liée.

Si c'est juste un éditeur de texte (pas un traitement de texte), l'approche que j'ai prise était de stocker chaque ligne de son propre nœud de liaison.

C'est une bonne approche simple qui facilite l'insertion et la suppression de lignes. Et l'insertion ou la suppression de texte est efficace car seules les données dans le nœud actuel doivent être déplacées lors de l'insertion ou de la suppression de texte.

Vous avez dit que vous ne voulez pas regarder le code source mais, néanmoins, vous pouvez télécharger la version que j'ai écrite de nombreuses années, il y a de nombreuses années à http://www.softcirits.com/sw_dos.aspx en téléchargeant pictor.zip pour voir un éditeur de texte simple.


1 commentaires

Merci pour la source Jonathan. Je ne voulais pas regarder le code source car la plupart des éditeurs sont trop complexes (au moins pour moi) pour comprendre ce qui se passe. Mais de beaux exemples simples sont toujours des épargnants de vie. Je vais regarder dans le code que vous avez fourni, semble petit et gentil :)