Je comprends que le comportement de babel-french concernant `\dots` et `xspace` puisse surprendre, voici quelques précisions : 1. les trois petits points (…) sont un *caractère Unicode* (U+2026), également présent dans le codage LY1 mais absent des codages T1 et TS1 les plus utilisés en français avec pdfLaTeX ; 2. xspace ne dispense de la paire d'accolade après la commande `\dots` *que si celle-ci émule le caractère non disponible*, donc en pdfLaTeX avec \usepackage[T1]{fontenc} ; 3. lorsque le caractère … est disponible dans la fonte de sortie, il me paraît normal de l'utiliser plutôt que de l'émuler. De nos jours les textes sources devraient tous être codés en utf-8 (codage par défaut de (pdf)LaTeX) et imposé pour LuaLaTeX et XeLaTeX. Or on accède facilement au caractère … directement au clavier [par exemple définir une touche "Compose" sur un clavier Linux : `Compose . .` affiche …). Je recommande donc de saisir directement le caractère … plutôt que `\dots` (avec ou sans accolades) dans les sources (La)TeX qu'ils soient compilés avec avec l'un ou l'autre des moteurs pdfTeX, XeTeX ou LuaTeX. Du coup plus besoin de xspace pour \dots. `\dots`. En plus, une touche "Compose" permet de coder directement les Ç É À œ æ « » í ø ß etc. donnant des textes sources bien plus lisibles.

Je comprends que le comportement de babel-french concernant \dots et xspace `\dots` et `xspace` puisse surprendre, voici quelques précisions : 1. les trois petits points (…) sont un *caractère Unicode* (U+2026), également présent dans le codage LY1 mais absent des codages T1 et TS1 les plus utilisés en français avec pdfLaTeX ; 2. xspace ne dispense de la paire d'accolade après la commande `\dots` *que si celle-ci émule le caractère non disponible*, donc en pdfLaTeX avec \usepackage[T1]{fontenc} ; 3. lorsque le caractère … est disponible dans la fonte de sortie, il me paraît normal de l'utiliser plutôt que de l'émuler. De nos jours les textes sources devraient tous être codés en utf-8 (codage par défaut de (pdf)LaTeX) et imposé pour LuaLaTeX et XeLaTeX. Or on accède facilement au caractère … directement au clavier [par exemple définir une touche "Compose" sur un clavier Linux : `Compose . .` affiche …). Je recommande donc de saisir directement le caractère … plutôt que `\dots` (avec ou sans accolades) dans les sources (La)TeX qu'ils soient compilés avec avec l'un ou l'autre des moteurs pdfTeX, XeTeX ou LuaTeX. Du coup plus besoin de xspace pour \dots. En plus, une touche "Compose" permet de coder directement les Ç É À œ æ « » í ø ß etc. donnant des textes sources bien plus lisibles.

Je comprends que le comportement de babel-french concernant \dots et xspace puisse surprendre, voici quelques précisions : 1. les trois petits points (…) sont un *caractère Unicode* (U+2026), également présent dans le codage LY1 mais absent des codages T1 et TS1 les plus utilisés en français avec pdfLaTeX ; 2. xspace ne dispense de la paire d'accolade après la commande `\dots` *que si celle-ci émule le caractère non disponible*, donc en pdfLaTeX avec \usepackage[T1]{fontenc} ; 3. lorsque le caractère … est disponible dans la fonte de sortie, il me paraît normal de l'utiliser plutôt que de l'émuler. De nos jours les textes sources devraient tous être codés en utf-8 (codage par défaut de (pdf)LaTeX) et imposé pour LuaLaTeX et XeLaTeX. Or on accède facilement au caractère … directement au clavier [par exemple définir une touche "Compose" sur un clavier Linux : `Compose . .` affiche …). Je recommande donc de saisir directement le caractère … plutôt que `\dots` (avec ou sans accolades) dans les sources (La)TeX qu'ils soient compilés avec avec l'un ou l'autre des moteurs pdfTeX, XeTeX ou LuaTeX. Du coup plus besoin de xspace pour \dots. En plus, une touche "Compose" permet de coder directement les Ç É À œ æ « » í ø ß etc. donnant des textes sources bien plus lisibles.