Le caractère de retour chariot est-il considéré comme obsolète

J'ai écrit une bibliothèque open source qui analyse les données structurées mais a intentionnellement omis la détection de retour chariot car je ne vois pas le point. Il ajoute une complexité et des frais supplémentaires pour peu ou pas d'avantages.

À ma grande surprise, un utilisateur a soumis un bogue où l'analyseur ne fonctionnait pas et j'ai découvert que la cause du problème était que les données utilisaient les fins de ligne CR par opposition à LF ou CRLF.

OSX n'utilise-t-il pas les fins de ligne de style LF depuis le passage à une plate-forme basée sur Unix?

Je sais qu'il existe des applications comme Notepad ++ où les fins de ligne peuvent être modifiées pour utiliser CR explicitement, mais je ne vois pas pourquoi quelqu'un voudrait le faire.

Est-il sûr d'exclure la prise en charge du pourcentage statistiquement insignifiant d'utilisateurs qui décident (pour une raison quelconque) des anciennes terminaisons de style Mac OS?

Mise à jour:

Pour clarifier, la prise en charge des fins de ligne Windows (c'est-à-dire CRLF) ne nécessite pas de reconnaissance de jeton CR. Pour des raisons d'efficacité, le lexer correspond sur une base par caractère. En ignorant silencieusement les caractères CR, le jeton CRLF se simplifie en LF. En tant que tel, le jeton CRLF lui-même pourrait être considéré comme un anachronisme qui lui est propre, mais ce n'est pas de cela qu'il s'agit.

Le dernier système d'exploitation qui fournissait une prise en charge à l'échelle du système pour les fins de ligne de style CR était Mac OS 9 . Ironiquement, la seule application qui l'utilise encore par défaut dans OSX est Microsoft Excel.

Selon une bonne pratique, vous êtes "libéral dans ce que vous acceptez et conservateur dans ce que vous envoyez" .

En d'autres termes, s'il y a une chance (aussi petite soit-elle) que quelqu'un vous donne une fin de ligne cr (et s'attend à ce qu'elle fonctionne correctement), vous devrez la supporter.

TBH, je ne vois pas comment l'ajout du support CR prendrait si longtemps.

Lorsque vous voyez un crdans le lexer jeter un coup d'œil au caractère suivant et s'il s'agit d'un nl, avalez la nouvelle ligne et émettez un jeton de nouvelle ligne, si le caractère suivant n'est pas nljuste émettez un jeton de nouvelle ligne et continuez.

Non. CR n'est pas obsolète (défini comme "n'est plus produit ou utilisé"). Vous-même en avez fourni la preuve. C'est peut-être rare , mais pas obsolète .

Quant à "est-il sûr d'exclure le support" pour CR? Comme vous le dites, il ne s'agit pas de perdre des ventes, et vous ne pouvez pas prendre en charge toutes les combinaisons de caractères et formats de fichiers étranges dans le monde, et vous seul connaissez votre logiciel et votre base d'utilisateurs. Je dirais donc qu'il serait prudent de l'exclure si vous êtes convaincu que la charge de support de ne pas l'ajouter (comme l'explique mouviciel) ne l'emporte pas sur la charge de temps de l'ajouter. Mais sans en savoir beaucoup plus sur le produit et la base d'utilisateurs, je ne sais pas comment être plus précis.

A propos de la paresse: il faut équilibrer:

• effort pour changer le code afin que CR soit manipulé en toute sécurité (et puis oubliez-le).

• effort pour expliquer aux utilisateurs pourquoi les fichiers dont ils étaient satisfaits pendant des décennies plantent soudainement votre application, pour trouver des solutions de contournement qu'ils peuvent utiliser sans compromettre vos ventes et pour demander des arguments et répondre aux commentaires ici.

C'est à vous de décider quel chemin est le plus paresseux.

Est-il sûr d'exclure la prise en charge du pourcentage statistiquement insignifiant d'utilisateurs qui décident (pour une raison quelconque) des anciennes terminaisons de style Mac OS?

Peut - être pas trop d'utilisateurs détecteront, mais il y a un éléphant dans la pièce: les fins de ligne (Windows CRLF). Si vous les supportez (je le fais généralement, même si je n'utilise que Windows pour les jeux), il devrait être trivial de prendre en charge la troisième partie de ce triangle historique des Bermudes.

Si vous ne supportez pas quelque chose comme ça, vous devriez au moins le mentionner dans la documentation (style "Ce n'est pas un bug") et comment changer les fichiers pour travailler avec votre outil de la manière la plus simple possible ( dos2unixpar exemple).

Il existe de nombreux périphériques série qui comptent sur la CRfin du flux de données avant leur ETXenvoi. C'est une convention qui ne disparaîtra jamais.

Je traiterais la demande comme n'importe quelle demande de fonctionnalité où vous devez peser les coûts par rapport aux avantages.

Si exactement une personne a demandé une assistance CR, ce n'est peut-être pas nécessaire. Voir le chapitre du livre ci-dessous de 37 signaux où ils disent que vous ne devriez vous soucier que des demandes de fonctionnalités très populaires.

http://gettingreal.37signals.com/ch05_Forget_Feature_Requests.php

Les systèmes d'exploitation MS à partir de MSDOS utilisent la combinaison CR + LF comme séparateur de ligne (je pense principalement à cause des imprimantes matricielles qui en ont besoin).

Alors oui, c'est une déception, mais vous avez toujours besoin de soutien pour ce fichu truc.