Avant d'utiliser Epydoc, j'ai voulu faire un petit test. Et je suis vite
tombé sur un problème d'organisation.
J'ai choisi un script, et j'y ai intégré mes commentaires (actuellement
externes), avec une mise en forme compréhensible par Epydoc. Le problème est
que le script modifié est 6 fois plus gros, avec 5 fois plus de lignes. Du
coup, la lisibilité en prend un coup. Il faut faire chauffer le curseur,
pour retrouver le code de chaque fonction, relativement à sa déclaration, ou
simplement pour naviguer dans le code-source.
Et encore, je n'ai pas mis en place les doctests...
En réfléchissant, je me suis dit qu'il faudrait, soit un éditeur qui
"replie" les docstrings, soit les enregistrer à part, et les retrouver à la
volée. Une macro de l'éditeur pourrait peut-être faire ça...
Finalement, je viens d'abord, dans ce newsgroup, à la pêche aux
suggestions...
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
jean-michel
"Do Re Mi chel La Si Do" a écrit dans le message de news:41ff4679$0$6597$
Finalement, je viens d'abord, dans ce newsgroup, à la pêche aux suggestions...
Bonsoir !
Si j'ai bien compris, tu parles des docs incluses dans des délimiteurs """ C'est peut-être un peu bourrin, mais tu pourrais transformer par exemple """ ligne 1 ligne 2 ... """ en """ n ligne 1n ligne 2n...n""" et inversement. D'ailleurs, c'est sûrement ce que tu entends par "replier" ? Ce devrait être facile à faire en python ! Reste à l'interfacer avec l'éditeur. Il me semble que scite permet ce genre de chose (Il y a des exemples fournis avec scite qui sont en python).
A+ jean-michel
"Do Re Mi chel La Si Do" <enleverlesO.OmcO@OmclaveauO.com> a écrit dans le
message de news:41ff4679$0$6597$8fcfb975@news.wanadoo.fr...
Finalement, je viens d'abord, dans ce newsgroup, à la pêche aux
suggestions...
Bonsoir !
Si j'ai bien compris, tu parles des docs incluses dans des délimiteurs """
C'est peut-être un peu bourrin, mais tu pourrais transformer par exemple
"""
ligne 1
ligne 2
...
"""
en
""" n ligne 1n ligne 2n...n"""
et inversement.
D'ailleurs, c'est sûrement ce que tu entends par "replier" ?
Ce devrait être facile à faire en python ! Reste à l'interfacer avec
l'éditeur. Il me semble que scite permet ce genre de chose (Il y a des
exemples fournis avec scite qui sont en python).
"Do Re Mi chel La Si Do" a écrit dans le message de news:41ff4679$0$6597$
Finalement, je viens d'abord, dans ce newsgroup, à la pêche aux suggestions...
Bonsoir !
Si j'ai bien compris, tu parles des docs incluses dans des délimiteurs """ C'est peut-être un peu bourrin, mais tu pourrais transformer par exemple """ ligne 1 ligne 2 ... """ en """ n ligne 1n ligne 2n...n""" et inversement. D'ailleurs, c'est sûrement ce que tu entends par "replier" ? Ce devrait être facile à faire en python ! Reste à l'interfacer avec l'éditeur. Il me semble que scite permet ce genre de chose (Il y a des exemples fournis avec scite qui sont en python).
A+ jean-michel
sL
Do Re Mi chel La Si Do wrote:
Bonjour !
Avant d'utiliser Epydoc, j'ai voulu faire un petit test. Et je suis vite tombé sur un problème d'organisation.
J'ai choisi un script, et j'y ai intégré mes commentaires (actuellement externes), avec une mise en forme compréhensible par Epydoc. Le problème est que le script modifié est 6 fois plus gros, avec 5 fois plus de lignes. Du coup, la lisibilité en prend un coup. Il faut faire chauffer le curseur, pour retrouver le code de chaque fonction, relativement à sa déclaration, ou simplement pour naviguer dans le code-source.
Et encore, je n'ai pas mis en place les doctests...
En réfléchissant, je me suis dit qu'il faudrait, soit un éditeur qui "replie" les docstrings, soit les enregistrer à part, et les retrouver à la volée. Une macro de l'éditeur pourrait peut-être faire ça...
Finalement, je viens d'abord, dans ce newsgroup, à la pêche aux suggestions...
à vous lire,
Bonjour,
Le "code folding" de Vim fonctionne de manière satisfaisante pour moi (mode indentation). Je commente de la façon suivante:
def toto(...): """toto fait ceci et cela. Ici, c'est la description longue de la fonction. @param bidule .... """ return 42
sL
Do Re Mi chel La Si Do wrote:
Bonjour !
Avant d'utiliser Epydoc, j'ai voulu faire un petit test. Et je suis vite
tombé sur un problème d'organisation.
J'ai choisi un script, et j'y ai intégré mes commentaires (actuellement
externes), avec une mise en forme compréhensible par Epydoc. Le problème est
que le script modifié est 6 fois plus gros, avec 5 fois plus de lignes. Du
coup, la lisibilité en prend un coup. Il faut faire chauffer le curseur,
pour retrouver le code de chaque fonction, relativement à sa déclaration, ou
simplement pour naviguer dans le code-source.
Et encore, je n'ai pas mis en place les doctests...
En réfléchissant, je me suis dit qu'il faudrait, soit un éditeur qui
"replie" les docstrings, soit les enregistrer à part, et les retrouver à la
volée. Une macro de l'éditeur pourrait peut-être faire ça...
Finalement, je viens d'abord, dans ce newsgroup, à la pêche aux
suggestions...
à vous lire,
Bonjour,
Le "code folding" de Vim fonctionne de manière satisfaisante pour moi
(mode indentation). Je commente de la façon suivante:
def toto(...):
"""toto fait ceci et cela.
Ici, c'est la description longue de la fonction.
@param bidule ....
"""
return 42
Avant d'utiliser Epydoc, j'ai voulu faire un petit test. Et je suis vite tombé sur un problème d'organisation.
J'ai choisi un script, et j'y ai intégré mes commentaires (actuellement externes), avec une mise en forme compréhensible par Epydoc. Le problème est que le script modifié est 6 fois plus gros, avec 5 fois plus de lignes. Du coup, la lisibilité en prend un coup. Il faut faire chauffer le curseur, pour retrouver le code de chaque fonction, relativement à sa déclaration, ou simplement pour naviguer dans le code-source.
Et encore, je n'ai pas mis en place les doctests...
En réfléchissant, je me suis dit qu'il faudrait, soit un éditeur qui "replie" les docstrings, soit les enregistrer à part, et les retrouver à la volée. Une macro de l'éditeur pourrait peut-être faire ça...
Finalement, je viens d'abord, dans ce newsgroup, à la pêche aux suggestions...
à vous lire,
Bonjour,
Le "code folding" de Vim fonctionne de manière satisfaisante pour moi (mode indentation). Je commente de la façon suivante:
def toto(...): """toto fait ceci et cela. Ici, c'est la description longue de la fonction. @param bidule .... """ return 42
sL
Do Re Mi chel La Si Do
Bonsoir !
Je m'excuse de ne pas avoir répondu avant, mais j'ai tenté une expédition dans des contrées sauvages, pleines de brouillard, d'embouteillages, de tromés, et de pollution : Paris.
Bref, l'idée d'une "mono-multi" ligne(s) pourrait être intéressante, mais il m'arrive couramment d'avoir des docstrings unitaires (pour une fonction) de 1000 caractères, cela ferait de très longues lignes. Et certains éditeurs afficheraient quand même cette ligne sur plusieurs lignes.
Pour Scite, il faudrait que je me penche sur la façon de le scripter. Mais le temps manque. Si tu avais un lien tout prêt (ou une mini-doc)...
Bonne soirée. -- Michel Claveau
Bonsoir !
Je m'excuse de ne pas avoir répondu avant, mais j'ai tenté une expédition
dans des contrées sauvages, pleines de brouillard, d'embouteillages, de
tromés, et de pollution : Paris.
Bref, l'idée d'une "mono-multi" ligne(s) pourrait être intéressante, mais il
m'arrive couramment d'avoir des docstrings unitaires (pour une fonction) de
1000 caractères, cela ferait de très longues lignes. Et certains éditeurs
afficheraient quand même cette ligne sur plusieurs lignes.
Pour Scite, il faudrait que je me penche sur la façon de le scripter. Mais
le temps manque. Si tu avais un lien tout prêt (ou une mini-doc)...
Je m'excuse de ne pas avoir répondu avant, mais j'ai tenté une expédition dans des contrées sauvages, pleines de brouillard, d'embouteillages, de tromés, et de pollution : Paris.
Bref, l'idée d'une "mono-multi" ligne(s) pourrait être intéressante, mais il m'arrive couramment d'avoir des docstrings unitaires (pour une fonction) de 1000 caractères, cela ferait de très longues lignes. Et certains éditeurs afficheraient quand même cette ligne sur plusieurs lignes.
Pour Scite, il faudrait que je me penche sur la façon de le scripter. Mais le temps manque. Si tu avais un lien tout prêt (ou une mini-doc)...
Bonne soirée. -- Michel Claveau
Do Re Mi chel La Si Do
Bonsoir !
Si VIM est capable de "replier" séparément les docstrings (doc/code folding), je suis TRES intéressé. (Quand je dis séparément, cela veut dire pouvoir replier, soit le code, soit le docstring, soit les deux.)
@-salutations -- Michel Claveau
Bonsoir !
Si VIM est capable de "replier" séparément les docstrings (doc/code
folding), je suis TRES intéressé.
(Quand je dis séparément, cela veut dire pouvoir replier, soit le code, soit
le docstring, soit les deux.)
Si VIM est capable de "replier" séparément les docstrings (doc/code folding), je suis TRES intéressé. (Quand je dis séparément, cela veut dire pouvoir replier, soit le code, soit le docstring, soit les deux.)
@-salutations -- Michel Claveau
jean-michel
"Do Re Mi chel La Si Do" a écrit dans le message de news:4203ddcc$0$6585$
Pour Scite, il faudrait que je me penche sur la façon de le scripter. Mais
le temps manque. Si tu avais un lien tout prêt (ou une mini-doc)...
J'ai regardé un peu, mais je n'ai rien trouvé d'évident. D'après ce que j'ai compris, scintilla *prévoit* des évènements qui rendent possible l'utilisation de macros, mais c'est à l'outil qui utilise le contrôle de les gérer. On trouve par exemple filerx qui se veut un gestionnaire de projets basé sur scite et scintilla, et qui donne quelques exemples (alléchants) de macros, mais je n'ai pas réussi à bien les faire fonctionner. Il faudrait se plonger dans le source pour comprendre. Quant à l'interface avec python, je n'ai trouvé nulle part plus de détails. Bref, rien de facile à ce sujet là. Le + simple serait peut-être d'écrire un script externe à l'éditeur qui stocke tes docs ailleurs (au hasard un .pydoc) en laissant juste un identificateur dans ton source. Je parie que tu y as pensé tout seul !
Désolé pour la fausse piste ! ++jm
"Do Re Mi chel La Si Do" <enleverlesO.OmcO@OmclaveauO.com> a écrit dans le
message de news:4203ddcc$0$6585$8fcfb975@news.wanadoo.fr...
Pour Scite, il faudrait que je me penche sur la façon de le scripter.
Mais
le temps manque. Si tu avais un lien tout prêt (ou une mini-doc)...
J'ai regardé un peu, mais je n'ai rien trouvé d'évident.
D'après ce que j'ai compris, scintilla *prévoit* des évènements qui rendent
possible l'utilisation de macros, mais c'est à l'outil qui utilise le
contrôle de les gérer. On trouve par exemple filerx qui se veut un
gestionnaire de projets basé sur scite et scintilla, et qui donne quelques
exemples (alléchants) de macros, mais je n'ai pas réussi à bien les faire
fonctionner. Il faudrait se plonger dans le source pour comprendre.
Quant à l'interface avec python, je n'ai trouvé nulle part plus de détails.
Bref, rien de facile à ce sujet là.
Le + simple serait peut-être d'écrire un script externe à l'éditeur qui
stocke tes docs ailleurs (au hasard un .pydoc) en laissant juste un
identificateur dans ton source. Je parie que tu y as pensé tout seul !
"Do Re Mi chel La Si Do" a écrit dans le message de news:4203ddcc$0$6585$
Pour Scite, il faudrait que je me penche sur la façon de le scripter. Mais
le temps manque. Si tu avais un lien tout prêt (ou une mini-doc)...
J'ai regardé un peu, mais je n'ai rien trouvé d'évident. D'après ce que j'ai compris, scintilla *prévoit* des évènements qui rendent possible l'utilisation de macros, mais c'est à l'outil qui utilise le contrôle de les gérer. On trouve par exemple filerx qui se veut un gestionnaire de projets basé sur scite et scintilla, et qui donne quelques exemples (alléchants) de macros, mais je n'ai pas réussi à bien les faire fonctionner. Il faudrait se plonger dans le source pour comprendre. Quant à l'interface avec python, je n'ai trouvé nulle part plus de détails. Bref, rien de facile à ce sujet là. Le + simple serait peut-être d'écrire un script externe à l'éditeur qui stocke tes docs ailleurs (au hasard un .pydoc) en laissant juste un identificateur dans ton source. Je parie que tu y as pensé tout seul !
Désolé pour la fausse piste ! ++jm
Do Re Mi chel La Si Do
Bonsoir !
Suite au message de sL, j'ai vu que Cite permet aussi de "plier/déplier" les fonctions et classes. C'est très pratique, et peut-être suffisant. Et ça rejoint ta suggestion, car Cite est basé sur Scintilla.
Par contre, j'ai beaucoup de choses à trouver, avec Cite (comment le scripter ; comment faire des macros ; comment ajouter des éléments de menu ; etc.) Mais cela se fera, avec le temps, et un peu de recherche sur Internet (grâce à toi, je sais qu'il faut chercher "filerx").
Quand au script externe, oui, j'y ai pensé. J'ai même fait un essai. Et c'est très facile à faire. Le problème étant l'intégration avec l'éditeur (un autre, c'est le risque d'effacement accidentel de l'identificateur).
@-salutations -- Michel Claveau
Bonsoir !
Suite au message de sL, j'ai vu que Cite permet aussi de "plier/déplier" les
fonctions et classes. C'est très pratique, et peut-être suffisant. Et ça
rejoint ta suggestion, car Cite est basé sur Scintilla.
Par contre, j'ai beaucoup de choses à trouver, avec Cite (comment le
scripter ; comment faire des macros ; comment ajouter des éléments de menu ;
etc.) Mais cela se fera, avec le temps, et un peu de recherche sur
Internet (grâce à toi, je sais qu'il faut chercher "filerx").
Quand au script externe, oui, j'y ai pensé. J'ai même fait un essai. Et
c'est très facile à faire. Le problème étant l'intégration avec l'éditeur
(un autre, c'est le risque d'effacement accidentel de l'identificateur).
Suite au message de sL, j'ai vu que Cite permet aussi de "plier/déplier" les fonctions et classes. C'est très pratique, et peut-être suffisant. Et ça rejoint ta suggestion, car Cite est basé sur Scintilla.
Par contre, j'ai beaucoup de choses à trouver, avec Cite (comment le scripter ; comment faire des macros ; comment ajouter des éléments de menu ; etc.) Mais cela se fera, avec le temps, et un peu de recherche sur Internet (grâce à toi, je sais qu'il faut chercher "filerx").
Quand au script externe, oui, j'y ai pensé. J'ai même fait un essai. Et c'est très facile à faire. Le problème étant l'intégration avec l'éditeur (un autre, c'est le risque d'effacement accidentel de l'identificateur).
