slt
lorsque j'importe des fichiers *.cpp de la fac a chez moi (utilisation de
visual c++6.0), j'ai le message suivant :
"Lines ending with only a carriage return have been detected. These will be
modified to include a line feed."
Ceci est tres embétant parceque je me retrouve avec un interligne entre
chaque ligne de code lorsque j'ouvre le fichier chez moi.
quelqu'un a-t'il une explication, voire même une solution concernant ce
probleme?
merci
On Wed, 4 Feb 2004 22:49:00 +0100, "Alain Naigeon" wrote:
Il me semble que pour aboutir à l'inconvénient que tu signales, il faut que l'éditeur mette à jour le fichier sous un autre format que l'originel.
Si tu crées un document sous Word, ce dernier enregistre le document dans un format très différent de ce qui est affiché à l'écran (Il n'y a pas de problème de conversion de fichier, puisque le document est créé à partir de rien). Du coup, tu ne peux pas l'ouvrir avec un autre logiciel (un éditeur de texte, grep, etc.) et obtenir quelque chose de ressemblant à ce que tu vois affiché sous Word.
C'est déjà assez pénible avec Word, mais relativement justifié par la richesse du formatage. Mais je n'aimerais vraiment pas que ce genre d'inconvénients arrive avec le code C++.
Absolument, moi non plus je n'aimerais pas ! Mon pinaillage était à la limite du troll, et avait de toute façon un ":-)" implicite.
--
Français *==> "Musique renaissance" <==* English midi - facsimiles - ligatures - mensuration http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/ Alain Naigeon - - Strasbourg, France
"Fabien LE LEZ" <gramster@gramster.com> a écrit dans le message news:
vjk520142r69dm4psrniuqo29ti52chd35@4ax.com...
On Wed, 4 Feb 2004 22:49:00 +0100, "Alain Naigeon" <anaigeon@free.fr>
wrote:
Il me semble que pour aboutir à l'inconvénient que tu signales,
il faut que l'éditeur mette à jour le fichier sous un autre format
que l'originel.
Si tu crées un document sous Word, ce dernier enregistre le document
dans un format très différent de ce qui est affiché à l'écran (Il n'y
a pas de problème de conversion de fichier, puisque le document est
créé à partir de rien). Du coup, tu ne peux pas l'ouvrir avec un autre
logiciel (un éditeur de texte, grep, etc.) et obtenir quelque chose de
ressemblant à ce que tu vois affiché sous Word.
C'est déjà assez pénible avec Word, mais relativement justifié par la
richesse du formatage. Mais je n'aimerais vraiment pas que ce genre
d'inconvénients arrive avec le code C++.
Absolument, moi non plus je n'aimerais pas ! Mon pinaillage était à la
limite du troll, et avait de toute façon un ":-)" implicite.
--
Français *==> "Musique renaissance" <==* English
midi - facsimiles - ligatures - mensuration
http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/
Alain Naigeon - anaigeon@free.fr - Strasbourg, France
On Wed, 4 Feb 2004 22:49:00 +0100, "Alain Naigeon" wrote:
Il me semble que pour aboutir à l'inconvénient que tu signales, il faut que l'éditeur mette à jour le fichier sous un autre format que l'originel.
Si tu crées un document sous Word, ce dernier enregistre le document dans un format très différent de ce qui est affiché à l'écran (Il n'y a pas de problème de conversion de fichier, puisque le document est créé à partir de rien). Du coup, tu ne peux pas l'ouvrir avec un autre logiciel (un éditeur de texte, grep, etc.) et obtenir quelque chose de ressemblant à ce que tu vois affiché sous Word.
C'est déjà assez pénible avec Word, mais relativement justifié par la richesse du formatage. Mais je n'aimerais vraiment pas que ce genre d'inconvénients arrive avec le code C++.
Absolument, moi non plus je n'aimerais pas ! Mon pinaillage était à la limite du troll, et avait de toute façon un ":-)" implicite.
--
Français *==> "Musique renaissance" <==* English midi - facsimiles - ligatures - mensuration http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/ Alain Naigeon - - Strasbourg, France
Samuel Krempp
le Friday 06 February 2004 00:36, écrivit :
C'est déjà assez pénible avec Word, mais relativement justifié par la richesse du formatage. Mais je n'aimerais vraiment pas que ce genre d'inconvénients arrive avec le code C++.
oui mais justement c'est pas vraiment ce dont je parlais. (de toute façon, il n'a jamais été question que l'editeur enregistre le fichier sous une forme autre que fichier texte compilable, la seule liberté envisagée est sur les fins de lignes et espace..)
dans le cas où tu ouvres un fichier existant, modifies 3 lignes, et enregistre, l'éditeur que j'imaginais fonctionnerait ainsi :
1. il affiche l'integralité du fichier selon son canon de formattage, indépendamment de tous les fins de lignes et espace du fichier d'origine. 2. au moment de sauver, soit il sauve tout le fichier avec les espaces et fins de lignes completement modifiés, à l'image de ce qui était affiché, soit il ne fait que récrire les lignes qui ont été modifiées (avec formattage reprenant le contexte -nbres d'espaces de l'indenation courante, etc- tout en mettant en oeuvre le canon). La 2° approche ne me semble pas poser de probleme d'implémentation, et serait alors préferable (minimise l'étendue des diffs)
dans cette optique là, les problèmes que tu évoques ne s'appliquent pas..
je crois que ça serait tout à fait faisable, le probleme étant de choisir à quel moment appliquer le formattage pendant que le codeur tape le code. l'interpretation de la structure n'est possible qu'à certains moment, et peut changer au fur et à mesure, le tout serait donc d'éviter de ballader des bouts de lignes aux 4 coins de l'écran à chaque caractère tapé par le codeur, et à priori en faisant un peu attention ce n'est pas du tout insurmontable.
le probleme de la configuration du "canon" de formattage utilisé pour s'adapter aux goûts de l'utilisateur est par contre pertinant, mais à mon avis pas si compliqué que ça. Est-ce qu'il y a tant de situations différentes à distinguer pour savoir où on veut retourner à la ligne ? si l'editeur permet de customiser des fonctions de décision qui fournissent en parametre tout le contexte intéressant (nbre de caractereres de chacun des tokens considérés, information sur le contexte - déclaration/définition/appel, d'une fonction ou d'une classe, la ligne en cours est une liste de parametres, ou de parametres de templates, de variables membres d'un certain type, etc...)
de toute façon meme avec le mode relativement simple d'indendation d'emacs je n'ai pas osé chercher à le personnaliser, au delà de faire un choix parmi les modes dispo, et de regler la valeur de base des indentations..
je sais pas si ce serait un feature suffisant pour être un argument marketing, mais bon qd il y aura divers compilos tout aussi conformes et à peu pres aussi performant, peut être des gens décideront d'ajouter cette possibilité à leur éditeur pour avoir un petit bonus.. et finalement etre repris par les concurrents.
(avoir un éditeur qui adapte le formattage du code source à la largeur de la fenetre d'édition, je pense personnellement que ce serait un réel bonus)
-- Sam
le Friday 06 February 2004 00:36, gramster@gramster.com écrivit :
C'est déjà assez pénible avec Word, mais relativement justifié par la
richesse du formatage. Mais je n'aimerais vraiment pas que ce genre
d'inconvénients arrive avec le code C++.
oui mais justement c'est pas vraiment ce dont je parlais. (de toute façon,
il n'a jamais été question que l'editeur enregistre le fichier sous une
forme autre que fichier texte compilable, la seule liberté envisagée est
sur les fins de lignes et espace..)
dans le cas où tu ouvres un fichier existant, modifies 3 lignes, et
enregistre, l'éditeur que j'imaginais fonctionnerait ainsi :
1. il affiche l'integralité du fichier selon son canon de formattage,
indépendamment de tous les fins de lignes et espace du fichier d'origine.
2. au moment de sauver, soit il sauve tout le fichier avec les espaces et
fins de lignes completement modifiés, à l'image de ce qui était affiché,
soit il ne fait que récrire les lignes qui ont été modifiées (avec
formattage reprenant le contexte -nbres d'espaces de l'indenation courante,
etc- tout en mettant en oeuvre le canon). La 2° approche ne me semble pas
poser de probleme d'implémentation, et serait alors préferable (minimise
l'étendue des diffs)
dans cette optique là, les problèmes que tu évoques ne s'appliquent pas..
je crois que ça serait tout à fait faisable, le probleme étant de choisir à
quel moment appliquer le formattage pendant que le codeur tape le code.
l'interpretation de la structure n'est possible qu'à certains moment, et
peut changer au fur et à mesure, le tout serait donc d'éviter de ballader
des bouts de lignes aux 4 coins de l'écran à chaque caractère tapé par le
codeur, et à priori en faisant un peu attention ce n'est pas du tout
insurmontable.
le probleme de la configuration du "canon" de formattage utilisé pour
s'adapter aux goûts de l'utilisateur est par contre pertinant, mais à mon
avis pas si compliqué que ça.
Est-ce qu'il y a tant de situations différentes à distinguer pour savoir où
on veut retourner à la ligne ?
si l'editeur permet de customiser des fonctions de décision qui fournissent
en parametre tout le contexte intéressant (nbre de caractereres de chacun
des tokens considérés, information sur le contexte -
déclaration/définition/appel, d'une fonction ou d'une classe, la ligne en
cours est une liste de parametres, ou de parametres de templates, de
variables membres d'un certain type, etc...)
de toute façon meme avec le mode relativement simple d'indendation d'emacs
je n'ai pas osé chercher à le personnaliser, au delà de faire un choix
parmi les modes dispo, et de regler la valeur de base des indentations..
je sais pas si ce serait un feature suffisant pour être un argument
marketing, mais bon qd il y aura divers compilos tout aussi conformes et à
peu pres aussi performant, peut être des gens décideront d'ajouter cette
possibilité à leur éditeur pour avoir un petit bonus.. et finalement etre
repris par les concurrents.
(avoir un éditeur qui adapte le formattage du code source à la largeur de la
fenetre d'édition, je pense personnellement que ce serait un réel bonus)
C'est déjà assez pénible avec Word, mais relativement justifié par la richesse du formatage. Mais je n'aimerais vraiment pas que ce genre d'inconvénients arrive avec le code C++.
oui mais justement c'est pas vraiment ce dont je parlais. (de toute façon, il n'a jamais été question que l'editeur enregistre le fichier sous une forme autre que fichier texte compilable, la seule liberté envisagée est sur les fins de lignes et espace..)
dans le cas où tu ouvres un fichier existant, modifies 3 lignes, et enregistre, l'éditeur que j'imaginais fonctionnerait ainsi :
1. il affiche l'integralité du fichier selon son canon de formattage, indépendamment de tous les fins de lignes et espace du fichier d'origine. 2. au moment de sauver, soit il sauve tout le fichier avec les espaces et fins de lignes completement modifiés, à l'image de ce qui était affiché, soit il ne fait que récrire les lignes qui ont été modifiées (avec formattage reprenant le contexte -nbres d'espaces de l'indenation courante, etc- tout en mettant en oeuvre le canon). La 2° approche ne me semble pas poser de probleme d'implémentation, et serait alors préferable (minimise l'étendue des diffs)
dans cette optique là, les problèmes que tu évoques ne s'appliquent pas..
je crois que ça serait tout à fait faisable, le probleme étant de choisir à quel moment appliquer le formattage pendant que le codeur tape le code. l'interpretation de la structure n'est possible qu'à certains moment, et peut changer au fur et à mesure, le tout serait donc d'éviter de ballader des bouts de lignes aux 4 coins de l'écran à chaque caractère tapé par le codeur, et à priori en faisant un peu attention ce n'est pas du tout insurmontable.
le probleme de la configuration du "canon" de formattage utilisé pour s'adapter aux goûts de l'utilisateur est par contre pertinant, mais à mon avis pas si compliqué que ça. Est-ce qu'il y a tant de situations différentes à distinguer pour savoir où on veut retourner à la ligne ? si l'editeur permet de customiser des fonctions de décision qui fournissent en parametre tout le contexte intéressant (nbre de caractereres de chacun des tokens considérés, information sur le contexte - déclaration/définition/appel, d'une fonction ou d'une classe, la ligne en cours est une liste de parametres, ou de parametres de templates, de variables membres d'un certain type, etc...)
de toute façon meme avec le mode relativement simple d'indendation d'emacs je n'ai pas osé chercher à le personnaliser, au delà de faire un choix parmi les modes dispo, et de regler la valeur de base des indentations..
je sais pas si ce serait un feature suffisant pour être un argument marketing, mais bon qd il y aura divers compilos tout aussi conformes et à peu pres aussi performant, peut être des gens décideront d'ajouter cette possibilité à leur éditeur pour avoir un petit bonus.. et finalement etre repris par les concurrents.
(avoir un éditeur qui adapte le formattage du code source à la largeur de la fenetre d'édition, je pense personnellement que ce serait un réel bonus)
-- Sam
Fabien LE LEZ
On Fri, 6 Feb 2004 01:05:27 +0100, "Alain Naigeon" wrote:
et avait de toute façon un ":-)" implicite
Perso, je préfère le smiley explicite -- cf ma signature ;-)
-- ;-)
On Fri, 6 Feb 2004 01:05:27 +0100, "Alain Naigeon" <anaigeon@free.fr>
wrote:
et avait de toute façon un ":-)" implicite
Perso, je préfère le smiley explicite -- cf ma signature ;-)
On Fri, 6 Feb 2004 01:05:27 +0100, "Alain Naigeon" wrote:
et avait de toute façon un ":-)" implicite
Perso, je préfère le smiley explicite -- cf ma signature ;-)
-- ;-)
Fabien LE LEZ
On Fri, 06 Feb 2004 01:59:42 +0100, Samuel Krempp wrote:
(de toute façon, il n'a jamais été question que l'editeur enregistre le fichier sous une forme autre que fichier texte compilable, la seule liberté envisagée est sur les fins de lignes et espace..)
Imaginons le cas d'un .cpp créé avec cet éditeur. Verrais-tu une utilité à ce que le contenu du fichier (affiché avec cat/type/more/less, par exemple) soit différent ce ce qu'affiche l'éditeur ? [Même si la différence ne concerne que des sauts de ligne]
-- ;-)
On Fri, 06 Feb 2004 01:59:42 +0100, Samuel Krempp
<krempp@crans.truc.en.trop.ens-cachan.fr> wrote:
(de toute façon,
il n'a jamais été question que l'editeur enregistre le fichier sous une
forme autre que fichier texte compilable, la seule liberté envisagée est
sur les fins de lignes et espace..)
Imaginons le cas d'un .cpp créé avec cet éditeur. Verrais-tu une
utilité à ce que le contenu du fichier (affiché avec
cat/type/more/less, par exemple) soit différent ce ce qu'affiche
l'éditeur ? [Même si la différence ne concerne que des sauts de ligne]
On Fri, 06 Feb 2004 01:59:42 +0100, Samuel Krempp wrote:
(de toute façon, il n'a jamais été question que l'editeur enregistre le fichier sous une forme autre que fichier texte compilable, la seule liberté envisagée est sur les fins de lignes et espace..)
Imaginons le cas d'un .cpp créé avec cet éditeur. Verrais-tu une utilité à ce que le contenu du fichier (affiché avec cat/type/more/less, par exemple) soit différent ce ce qu'affiche l'éditeur ? [Même si la différence ne concerne que des sauts de ligne]
-- ;-)
Fabien LE LEZ
On Fri, 06 Feb 2004 01:59:42 +0100, Samuel Krempp wrote:
(avoir un éditeur qui adapte le formattage du code source à la largeur de la fenetre d'édition, je pense personnellement que ce serait un réel bonus)
Un point pour toi sur ce coup-là... Mais si la ligne ne fait que quelques caractères de trop, un changement de taille de police est aussi une solution à envisager.
-- ;-)
On Fri, 06 Feb 2004 01:59:42 +0100, Samuel Krempp
<krempp@crans.truc.en.trop.ens-cachan.fr> wrote:
(avoir un éditeur qui adapte le formattage du code source à la largeur de la
fenetre d'édition, je pense personnellement que ce serait un réel bonus)
Un point pour toi sur ce coup-là... Mais si la ligne ne fait que
quelques caractères de trop, un changement de taille de police est
aussi une solution à envisager.
On Fri, 06 Feb 2004 01:59:42 +0100, Samuel Krempp wrote:
(avoir un éditeur qui adapte le formattage du code source à la largeur de la fenetre d'édition, je pense personnellement que ce serait un réel bonus)
Un point pour toi sur ce coup-là... Mais si la ligne ne fait que quelques caractères de trop, un changement de taille de police est aussi une solution à envisager.
-- ;-)
Samuel Krempp
le Saturday 07 February 2004 07:07, écrivit :
Imaginons le cas d'un .cpp créé avec cet éditeur. Verrais-tu une utilité à ce que le contenu du fichier (affiché avec cat/type/more/less, par exemple) soit différent ce ce qu'affiche l'éditeur ? [Même si la différence ne concerne que des sauts de ligne]
oui, je pense que le fichier.cpp lui meme devrait etre formatté pour du 80 colonnes par défaut. Ce qui impose pas mal de retours à la lignes, surtout quand on utilise des types tres long à taper (par exple des typedefs à l'interieur de classes imbriquées qui prennent des arguments template.. une commande toute simple peut prendre plus de 80 caracteres avec ce genre de types)
par contre si ca tient dans la fenetre de l'editeur, je prefere que cette longue ligne ne soit pas séparée artificiellement en plusieurs..
-- Sam
le Saturday 07 February 2004 07:07, gramster@gramster.com écrivit :
Imaginons le cas d'un .cpp créé avec cet éditeur. Verrais-tu une
utilité à ce que le contenu du fichier (affiché avec
cat/type/more/less, par exemple) soit différent ce ce qu'affiche
l'éditeur ? [Même si la différence ne concerne que des sauts de ligne]
oui, je pense que le fichier.cpp lui meme devrait etre formatté pour du 80
colonnes par défaut. Ce qui impose pas mal de retours à la lignes, surtout
quand on utilise des types tres long à taper (par exple des typedefs à
l'interieur de classes imbriquées qui prennent des arguments template.. une
commande toute simple peut prendre plus de 80 caracteres avec ce genre de
types)
par contre si ca tient dans la fenetre de l'editeur, je prefere que cette
longue ligne ne soit pas séparée artificiellement en plusieurs..
Imaginons le cas d'un .cpp créé avec cet éditeur. Verrais-tu une utilité à ce que le contenu du fichier (affiché avec cat/type/more/less, par exemple) soit différent ce ce qu'affiche l'éditeur ? [Même si la différence ne concerne que des sauts de ligne]
oui, je pense que le fichier.cpp lui meme devrait etre formatté pour du 80 colonnes par défaut. Ce qui impose pas mal de retours à la lignes, surtout quand on utilise des types tres long à taper (par exple des typedefs à l'interieur de classes imbriquées qui prennent des arguments template.. une commande toute simple peut prendre plus de 80 caracteres avec ce genre de types)
par contre si ca tient dans la fenetre de l'editeur, je prefere que cette longue ligne ne soit pas séparée artificiellement en plusieurs..
