Editeur avec marquage syntaxique

Ce que j'ai prévu actuellement, c'est une reconnaissance du bloc à plier, basée purement sur des éléments sans rapport avec le langage de Panoramic proprement-dit, étant donné que Synedit-Editor se veut un éditeur multi-langages. Donc, le bloc à plier sera identifié de deux manières:

- soit, on a surligné un certain nombre de lignes. Dans ce cas, ce seront ces lignes qui seront pliées, et ces lignes en totalité, même si la première et/ou la dernière ne sont sélectionnées que partiellement

- soit on replie à partir de la ligne dans laquelle se trouve le curseur, jusqu'à la première ligne blanche ou jusqu'à la fin du fichier, si aucun texte n'est surligné.

Je pense que c'est une convention logique et claire, mais je suis ouvert à la discussion.

EDIT

D'ailleurs, un bloc plié peut lui-même contenir des marqueurs de blocs déjà pliés, sans perte d'information ou de cohérence !

Les recherches de chaînes de caractères par ctrl/F ou F3 n'agissent pas sur les parties pliées !

Je partais sur l' exemple de NotePad++ 
qui propose des pliages sur des balises paramétrables.
En fait, on défini des blocks par des balises et un petit + vient se placer devant les balises de début :

ex déplié:

+ Sub Masub()
|
|
|
|
|
 End_Sub

plié :

+Sub Masub()
End_sub

On pourrait ainsi définir des blocks tels que
Sub...   ...End_sub
For...    ...Next
If...   ...End_if
etc...

plus compliqué pour "label :...    ...return"
les deux points ayant plusieurs utilisations et le nom de label étant variable.
Quoi que, mais ce ne serait plus portable avec d' anciens programmes
mais Jack pourrait créer l' obligation du terme label devant un label...je plaisante...

A partir de là, c' est l' utilisateur qui créée ses propres block pour son langage.
L' éditeur n' a plus qu' à vérifier les balises dans une liste.
Mais là, peut être que je complique le schmilblick...

Merci Klaus, ça pour la lisibilité des gros programmes, ce sera vraiment pratique (on pourra sauvegarder l'état du source avec les replis par défaut ? Si ce n'est pas automatique par bloc, ça veut dire qu'il y aura un fichier en plus du fichier .bas ?)

Je fais le repli dans de petits fichiers *.pli, et dans le source à l'écran, on trouve des lignes #INCLUDE avec ces fichiers.

Pour le moment, j'ai imaginé le dépliage automatique lors de l'enregistrement. Mais je pourrais également préserver le pliage et sauvegarder les segments avec le source principal. Pour le moment, ils sont dans un dossier temporaire. On pourrait ajouter une option générale de type case à cocher pour activer/désactiver cette possibilité.

Très bonne idée Klaus !

J'attends cette option avec impatiente... Elle nous manque depuis si longtemps !

Quand je vous disais que nous n'aurions pas le temps de tester les nouvelles versions, que Klaus aura déjà implanter de nouvelles fonctions.

Bravo Klaus, bonne continuation...

Plier jusqu'à la prochaine ligne blanche marche.
Déplier marche.
Je travaille sur la reconnaissance du surlignage.
Ensuite, ce sera la sauvegarde des fichiers.

Et l'idée d'un fichier prj (ou ppf pour Panoramic Project File ?) pour projet qui serait un zip avec le(s) source(s) le ou les fichiers pli, les fichiers externes, qu'est ce que tu en penses en format d'entrée sortie ? Les chemins pourraient être recréés en relatif par rapport au fichier source (pour les images, les fichiers wav, les dll, utilisée dans le programme ... avec comme seule contrainte d'être une sous arborescence du répertoire courant où est enregistré le fichier source ?)

@Klaus : As tu aussi prévu l'indentation automatique ?

Eh bien, ça fuse, les idées !

Pour le fichier "projet" avec un enregistrement regroupé de tous les modules, je verrai ça plus tard. C'est effectivement intéressant, mais certainement pas sous forme de ZIP. Il faudrait une librairie freeeware gérant les ZIP, à partir de Delphi. Ca existe, mais ce n'est pas si simple, et cela représente en général on OCX (contrôle AvtiveX) à installer et activer chez l'utilisateur, ce que je veux éviter. C'est toujours délicat. Mais pourquoi pas un format propriétaire - je vais y réfléchir.

Quant à l'indentation automatique, c'est clairement non. Et pour plusieurs raisons. La première étant la nature multi-langage de Synedit_Editor. Je rappelle que ce programme gère actuellement la coloration syntaxique de 44 langages (Panoramic compris), et à l'évidence, je ne me vois pas faire de l'indentation automatique pour tous ces langages dont pour la plupart je n'y connais rien. Et d'autre part, l'indentation pour Panoramic est surtout une affaire de goût personnel. Pour ma part, j'applique une certaine méthode, mais je vois bien que d'autres font tout à fait différemment. Et je ne souhaite pas intervenir dans ces affaires_là de façon aussi directive. Et enfin, cela supposerait d'analyser en permanence la structure logique d'un code source, dans sa globalité. Ceci, même si c'est faisable, est un effort énorme et n'est plus du tout compatible avec une réactivité du programme tel que je l'attends d'un éditeur de source. Par contre, il y a d'excellents logiciels de mise en forme de sources, même pour Panoramic (dont certains ont déjà été publié sur ce forum), et il est parfaitement possible de les utiliser, voir même de les attacher à Synedit_Editor sour forme d'outils...

Mais ce débat est instructif et constructif, et je considérai chaque suggestion attentivement. Et si elle entre dans la vision que j'ai du produit final (et si elle est dans mes compétences techniques), je la réaliserai.

Rapport d'avancement sur le "pliage" du code:

Ce qui est fait:
1. le pliage du code à partir de la ligne dans laquelle se trouve le curseur, jusqu'à la première ligne blanche ou la fin du fichier ==> OK
2. le pliage du code de toutes les lignes complètes comprenant la sélection de texte active ==> OK
3. si une sélection de texte est active, fonction (2) est exécutée, sinon, c'est la fonction (1)
4. dépliage ==> OK
5. pliage d'un segment contenant un ou plusieurs segments pliés ==> OK
6. dépliage d'un segment contenant un ou plusieurs segments pliés ==> OK

Ce qui reste à faire:
1. enregistrement d'un code contenant des segments pliés, éventuellement à plusieurs niveaux
2. création d'une version totalement dépliée pour soumission aux outils externes
3. chargement d'un code contenant des segments pliés, éventuellement à plusieurs niveaux

Est-ce qu'une version "démo" (sans enregistrement, bien sûr) du pliage vous intéresse ?

Même si je suis d' un naturel curieux et impatient 
je préfère te laisser finir la partie pliage/dépliage avant de tester.
Cela pourrait se finir en une volée de posts  pour des bugs
qui ne serait dus que du fait qu' ils sont en cours de codage. 

Maintenant, si tu décides d' en mettre une en ligne...
...je ferai comme les copains, je me jetterai dessus comme un mort de faim.

Je ne teste pas, mais je donne mon avis quand même. Vu la vitesse à laquelle tu travaille Klaus, tant que ce n'est pas fini, continues de bosser sur cette fonctionnalité. Publier une version de démo avec les échanges sur le forum et tout, ça te prend du temps (à peine moins que de travailler dessus et de le finir (en règle générale sauf manque d'idées ou problème(s) technique(s) ou personnel(s), ce qui n'arrive quasiment pas).
Selon moi, tu peux continuer de mettre au point cette fonctionnalité avant de publier une démo.

D'accord. Je continue...

Bonjour a tous !

@Klaus : Comme le disent si bien ygeronimi et Jicehel, continu 'tranquillement' le travail que tu as commencé !

Nous avons largement de quoi tester même si je suis impatient de voir le résultat...

Concernant l'indentation automatique, je comprends ta position, malgré tout c'est une option que je trouve utile.
Mais il est vrai que nous avons déjà des outils proposés sur le forum allant dans ce sens.

Bon courage à tous...

A voir, mais je pense que l'indentation automatique pourrait se faire à la demande (pas de manière automatique lors de la frappe) via un outil. Il faut juste que l'outil puisse sélectionner le texte en cours, le copier pour le traiter, faire une sauvegarde du source non mis en forme quelquepart (fichier tmp par exemple) , faire l'indentation (comme l'ont fait des programmes publiés sur le forum), puis remplacer le texte du fichier source par le texte mise en forme. La sauvegarde permettrait de pouvoir faire un undo en cas de problème lors de la mise en forme auto (on n'est jamais trop prudent).

Pour l'indentation, j'avais bien pensé à un outil extérieur. Il peut être appelé par Synedit_Editor, comme n'importe quel outil. Il faudrait que cet utilitaire affiche le résultat d'une manière ou d'une autre, pour validation dans l'outil. Et il faudrait que Synedit_Editor puisse déterminer, d'une manière ou d'une autre, que l'outil a validé son travail et qu'il faut recharger la page à partir du résultat modifié, ou que l'outil a abandonné sa modif.

Je vais peut-être dire une grosse co****** car je n' ai pas fait l' essai avec Synedit
mais il serait bien que la touche "Tab" réagisse comme dans un éditeur de texte en créant un retrait
plus important ( "   ") que la touche "Space" (" "). Cela faciliterai l' indentation ce qui n' est pas le cas dans
Panoramic_Editor.

C'est clair que ce serait une solution encore plus propre et ce mécanisme pourrait servir à d'autre type d'outils additionels optionnels.

Nouvelle version Alpha 0.19 du 05/09/2014 de Synedit_Editor, utilisant la nouvelle version V3.38 du 05/09/2014 de KGF.dll.

Nouveauté:
Cette version sait faire le pliage/dépliage de texte dans une page d'édition !

Le pliage se fait, soit par le menu Edition/Plier, soit par la touche control/P. Il y a deux façons de déterminer les limites du segment à plier:
1. à partir du début de la ligne dans laquelle est le curseur, quelque soit sa position, jusqu'à la prochaine ligne blanche ou jusqu'à la fin du fichier
2. tout le texte sélectionné par surlignage, et ce depuis le début de la ligne contenant le début du texte sélectionné, jusqu'à la fin de la ligne contenant la fin du texte sélectionné.

On plie toujours des lignes entières, quelque soit le moyen de sélection des limites.

A la place du texte replié, on trouvera une ligne du type:

Code:

#INCLUDE "$SE_x_y.pli"  ; ' z...z

avec x étant le numéro de la page d'édition, y étant le numéro du segment plié, et z...z le texte de la première ligne du segment plié.

Pour déplier un segment, il suffit de placer le curseur dans cette ligne spéciale et de taper control/P. Cette ligne disparaît alors et est remplacée par le segment.

Lors de la mémorisation du fichier ("sauver" ou "sauver dans"), le fichier est mémorisé tel quel. Les segments pliés restent pliés, et au chargement par "Ouvrir", on retrouve l'état des segments pliés comme à l'enregistrement.

Les segments pliés sont tous mémorisés dans un fichier du même nom que le fichier source de base, mais avec l'extension *.pli. En absence de ce fichier, il sera impossible, à l'ouverture par "Ouvrir", de récupérer les segments pliés.

Lorsqu'on soumet un code à un outil externe (Notepad+, Panoramic.exe, ...) tous les segments sont automatiquement dépliés pour la soumission, dans un fichier temporaire, sans affecter l'état de pliage dans la page présente à l'écran.

Dernière remarque: on peut replier un segment contenant lui-même un ou plusieurs segments pliés, contenant à leur tour... etc. Pas de limite de profondeur.

Petite remarque: est-ce que techniquement, le numéro de ligne si on l'affiche pourrait tenir compte du nombre de lignes du fichier inclus (ou replié) ?   (Pour avoir le bon numéro de ligne lors du débogage ?)

$SE_x_y.pli n'est pas assez parlant selon moi, x variant selon les jours où on édite le fichier source, par exemple (je dis bien, si j'ai bien compris).L’intérêt de replier est de savoir ce qui est replié, ce qui apparaît au niveau du commentaire z.
Je comprend bien l'intérêt du y mais tu vas avoir un problème avec le x si on commence un autre source avec une seule fenêtre ouverte. Je pense qu'il faudrait le remplacer par un code mais j'avoue que ce n'est pas simple de réfléchir à un système qui écrase un autre fichier pli si besoin mais qui ne l'écrase pas s'il s'agit d'un autre.

Bonjour a tous !

Oui Klaus, tout a fait d'accord avec Jicehel concernant les numéro de lignes et les intitulés.
Il est dommage que  les numéros de lignes changent lors du pliage. Il faudrait pouvoir replier et garder la numérotation. En plus l'avantage, on sais combien de lignes sont pliés.

Concernant le #INCLUDE... , c'est vrai que se n'est pas 'très parlant', en même temps on a le commentaire ensuite.
D'ailleurs chez moi ce commentaire s'affiche en jaune donc pratiquement illisible.

Pourquoi ne pas juste indiquer la partie plier par un "#" ou autre chose et le commentaire représentant la première ligne :

Citation :

# SUB Minibug()

Je n'ai aucune influence sur la gestion des numéros de ligne. C'est codé en "dur" dans l'objet Synedit. On peut juste les afficher ou pas.

Mais je vais ajouter une option permettant de voir dans Synedit_Editor, le texte totalement déplié ce qui donne les vrais numéros de ligne.

Ceci dir, tu peux déjà faire ça en introduisant Notepad+ dansles outils. Si tu soumets un code à cet outil, il est automatiquement totalement déplié, et tu vois les vrais numéros de ligne...

Je vais simplifier le marquage de la section pliée. Je vais le transformer en

Code:

#$SE_x_y.pli  =  z...z

Du coup, le problème du jaune sera résolu aussi. Mais j'ai besoin des informations x et y, car sinon, je n'ai aucun moyen de retrouver les parties manquantes. Car ce n'est pas un vrai plier/déplier fait par l'objet Synedit, qui ne dispose pas du tout ce cette fonctionnalité. Tout est réalisé par moi, avec mémorisation dans de petits fichiers temporaires séparés au moment de l'édition, qui sont regroupés en un seul fichier *.pli lors de l'enregistrement.

Mais je reconnais que la visualisation dépliée native ainsi que l'enregistrement déplié natif manquent, et ce sera ajouté.

@Klaus : Je me doute bien qu'il y a des impératifs techniques !

Concernant les numéros de lignes, c'est vrai que ça risque d'être perturbant en cas de recherche d'une erreur mais rien n'empêche dans ce cas particulier de déplier tout le code !

Déjà ce que tu as réalisé est au delà de nos espérances. Tu as repoussé les limites de notre bon vieil éditeur Panoramic.
Mais j'imagine que tu as d'autres idées dont tu vas nous faire profiter...

Alors bon courage Klaus, et encore merci pour cette application qui va devenir incontournable pour tous les Panoramiciens !

Absolument. Si tu intègre une facilité de visualisation du code déplié aisée (ce sera encore mieux que de passer par notepad+) mais en cas de débuggage, c'est vrai que l'on a vite l'info et ce sera bcp plus fiable et rapide que de retrouver le numéro de ligne actuellement quand il y a plusieurs includes.

@Minibug: Je pense que c'est le but: "cette application qui va devenir incontournable pour tous les Panoramiciens !". Je pense même que Jack béni le projet car cela lui simplifiera la vie aussi à terme de ne plus avoir autant de manips à faire pour maintenir l'éditeur. Qui sait, il l'intégrera peut être directement dans le pack d'installation de Panoramic à terme ? On verra bien