Ace: Mauvaise position du curseur

Essayez de courir

fm = editor.renderer.$textLayer.$fontMetrics;
"xiXbm".split("").map(fm.$measureCharWidth, fm)

si cela imprime des nombres différents, la police utilisée dans l'éditeur n'est pas à espacement fixe.

Notez également que l'ajout d'une règle consolas !important est une mauvaise idée car elle se brisera sur linux et mac.

J'avais un problème similaire, et cet ajout CSS l'a résolu. Pourrait aider...

.ace_editor, .ace_editor div{
    font-family:monospace
}

(Raison : comme l'a dit @nightwing . Cet ajout de css garantirait que vous utilisez le monospace.)

J'ai des utilisateurs qui voient ce problème sur Windows 10 / Chrome 41.0.2272.76.

@nightwing Quand j'ai exécuté ce morceau de code, c'était la sortie.

Cela ne semble se produire que sous Windows. Auparavant, j'ai trouvé que la position du curseur était _toujours_ incorrecte sur Windows 8+ jusqu'à ce que j'ajuste l'espacement des lettres : https://github.com/ajaxorg/ace-builds/issues/58

Cependant, mes utilisateurs voient toujours cela de temps en temps. Voir les captures d'écran ici :
https://github.com/Crunch/Crunch-2/issues/39

Ace utilise-t-il _all_ les propriétés CSS de la ligne affichée lors de la mesure ? Tels que l'espacement des lettres, l'ombre du texte, le rendu du texte, -webkit-text-size-adjust et -webkit-font-smoothing ? (C'est-à-dire, utilise-t-il le style calculé de la police actuelle, tel qu'il est appliqué à l'éditeur visible ?) Ou seulement certains ?

@matthew-dean, toutes ces propriétés doivent être personnalisées sur l'élément racine de l'éditeur, de sorte que les montants hérités par les lignes d'as sont également hérités par la mesure div.
text- rendu:optimizeLegibility n'est pas pris en charge

@nightwing text-rendering: optimizeLegibility pourrait en effet être le coupable. C'est la seule chose à laquelle je pouvais penser qui compenserait différemment un monospace, ce qui a apparemment été un problème, en particulier dans Chrome, _spécifiquement Chrome pour Windows_ depuis Windows 7. Voir : https://github.com/zurb/foundation/issues/ 1827 (et autres bugs divers déposés).

Je vais essayer de supprimer ce paramètre, au moins pour l'éditeur, pour voir si cela change. @vdzundza Étant donné que c'est intermittent, je serais intéressé de savoir si cela fonctionne pour vous (et si vous aviez appliqué cette prop/valeur).

J'ai changé ce paramètre pour le rendu de texte : geometryPrecision, qui devrait être encore plus précis lors du rendu des caractères de texte. Cependant, sous Windows, il dessine toujours la position du curseur de manière inexacte. Voir plus de captures d'écran @ https://github.com/Crunch/Crunch-2/issues/39

Pourriez-vous me donner une page de démonstration reproduisant ce problème, ou peut-être crunch-2 afin que je puisse le déboguer ?

@nightwing Vous pouvez obtenir une copie de Crunch 2 ici : https://github.com/Crunch/Crunch-2/releases

Alors envoyez-moi un message sur Twitter : https://twitter.com/matthewdeaners. Sur NWJS, vous pouvez accéder aux outils de développement Chrome, mais il y a quelques étapes à suivre pour Crunch.

@nightwing Des idées ? Nous avons toujours des problèmes sur Windows 10.

Je n'ai pas pu reproduire cela sur Windows 10, pouvez-vous m'envoyer une image montrant le problème ?

@nightwing Il y a plusieurs images, certaines animées pour montrer ce qui se passe, dans ce fil : https://github.com/Crunch/Crunch-2/issues/39

@nightwing Je pense maintenant qu'il s'agit de la police Hasklig (https://github.com/i-tu/Hasklig) + Chromium 41 + text-rendering avec soit OptimizeLegibility, soitometricPrecision. Tout paramètre qui active les ligatures finit par être rendu avec des largeurs de caractères incohérentes. Je l'ai testé avec de longues lignes de ligatures et en activant/désactivant le rendu du texte, et les lignes ont changé de longueur. Donc, dans mon cas, ce n'est probablement pas un problème d'Ace, puisque Hasklig ne semble pas techniquement être une police à espacement fixe dans cet environnement. Désolé pour la chasse à l'oie sauvage ; Je ne savais pas que la police rendait non monospace.

Errrr... J'ai peut-être parlé trop tôt. J'ai également des problèmes avec la position du curseur avec Source Code Pro et text-rendering: optimizeLegibility est désactivé. Cependant, le réglage/désactivation du rendu du texte semble « réinitialiser » la mesure du curseur, vous ne pouvez donc parfois pas reproduire après la première fois.

D'accord. Donc, je ne connais pas exactement la cause, mais j'ai un correctif qui fonctionne pour moi. Je règle text-indent: 0.1px puis text-indent: 0.1px après un court délai d'attente. Cela déclenche la mise en page / la peinture / le composite comme indiqué ici : http://csstriggers.com/

@nightwing Une des raisons pour lesquelles vous n'avez pas rencontré cela pourrait être que la définition d'un thème as provoque probablement une mise en page / peinture / composite dans la plupart des cas, si l'un des paramètres de police "inhérents" du navigateur ne correspond pas aux paramètres de police du thème, ce qui semble probable. La première peinture de Chrome d'une ligne de texte peut être inexacte, ce qui signifie que les mesures d'Ace le seraient aussi, mais tant que quelqu'un définit ne serait-ce qu'une propriété CSS qui déclenche une nouvelle mise en page, personne ne le remarquerait jamais.

Donc, si vous voulez reproduire, vous pouvez tester avec certains paramètres de police définis uniquement dans le CSS, et non dans un thème, mais je ne sais pas quelle pourrait être la combinaison magique pour reproduire le bogue. Il est également possible qu'Ace puisse détecter ce bogue en mesurant une ligne de texte particulière avec un CSS particulier et en la comparant à une constante connue (ce que devrait être le résultat), puis si cela ne correspond pas, en déclenchant un repeint dans le même manière. (Mais bien sûr, cela signifierait reproduire le bogue en premier lieu.)

Une autre chose que vous pouvez faire est que Ace définisse toujours une propriété CSS (tardive), indépendamment de ce qui déclencherait toujours la mise en page / la repeinture. (J'ai essayé de comprendre quelque chose qui ne serait pas visiblement visible, mais je ne suis pas sûr de ce que cela pourrait être.) .

J'ai rencontré le problème exact et j'ai réussi à le résoudre (pour mon cas).

J'exécutais une fonction sur la sortie d'Ace pour extraire la matière première de YAML. Cette fonction s'exécute sur l'événement onChange d'Ace. Lorsque ma fonction a généré des erreurs, le curseur a commencé à se désynchroniser. Contrairement à un autre problème similaire dans lequel les curseurs se désynchronisent de manière permanente, celui-ci "récupère", car si je sélectionne tout et supprime tout, et commence à écrire sans que la fonction ne génère d'erreurs, le curseur est correctement positionné.

Je ne sais pas si je suis assez clair, ou si cela aide de quelque manière que ce soit, mais je soupçonne que tout type d'interruption du flux de code entourant Ace fait que la position du curseur n'est pas mise à jour correctement (ergo la position du curseur est mise à jour _after_ certain les choses sont exécutées, et si celles-ci échouent, le positionnement du curseur échoue ?).

@kenlimmj en lançant une erreur des écouteurs d'événement cassera l'éditeur, car les autres écouteurs ne seront pas appelés.
editor.on("input", pourrait être un meilleur événement pour ce que vous faites.

Même problème.

Capture d'écran:

@AviralGarg1993, vous devez utiliser une police à espacement fixe.

@nightwing Cela n'a pas semblé fonctionner.

https://github.com/AviralGarg1993/codeSirens/commit/edf539da1d752e5b7404a4fd7ae129f0f74a1d35

Pour toute autre personne ayant ce problème, ceci pourrait aider:

Si vous avez une taille de police définie dans rem (comme dans Bootstrap 4), votre curseur serait farfelu.
La définition d'une taille de police de 12px a résolu mon problème :

.ace_editor .ace_content {
  font-size: 12px !important;
}

Fondamentalement, Ace ne peut afficher que les polices « monospaces », vous pouvez modifier la police d'une manière ou d'une autre ou vous devez attribuer un nom de police en css.
si vous travaillez dans firefox, il y a une police par défaut qui changera votre police monospace. alors soyez conscient de cela.

Les conseils de @wislem n'ont pas fonctionné pour moi mais m'ont mis sur la bonne voie.

Je pense que l'utiliser dans une feuille de style globale résoudrait tous les problèmes, quel que soit le framework. Le problème de base de l'utilisation de font-size in rem était cependant le même problème de base.

.ace_editor div, .ace_editor span { font-size: 12px !important; }

L'éditeur Ace semble fonctionner uniquement avec la police à espacement fixe. Comme indiqué par @skbly7, la solution peut appliquer font-family:monospace mais l'ajout de !important empêchera le remplacement par d'autres CSS appliqués après les mots sur les éléments.

.ace_editor, .ace_text-input, .ace_editor div{
    font-family : monospace !important;
}

Je construis un nouveau site en utilisant Ace pour Less.js et c'est toujours un problème, avec rien d'autre sur la page, à l'exception de 2 éditeurs. Je vais essayer mon vieux hack text-indent: 0.1px .

Cette fois, ce sont les styles par défaut d'un projet Vue qui en sont la cause :

html {
  word-spacing: 1px;
  -ms-text-size-adjust: 100%;
  -webkit-text-size-adjust: 100%;
  -moz-osx-font-smoothing: grayscale;
  -webkit-font-smoothing: antialiased;
}

Les styles par défaut d'Ace devraient probablement réinitialiser ces paramètres.

Cela semble être un vieux problème avec l'éditeur Ace, particulièrement évident lorsque vous collez du texte en non anglais

Mon hypothèse est qu'un code fou ici en est la cause
https://github.com/ajaxorg/ace/blob/902d1a02864479cfa7c47f46972ff53fb56924fc/lib/ace/virtual_renderer.js#L1221

essayer avec
Встре́ча с медве́дем мо́жет быть о́чень опа́сна. Ру́сские лю́ди лю́бят ходи́ть в лес и собира́ть грибы́ и я́годы. Они́ де́лают э́то с осторо́жностью, так как медве́ди то́же о́чень лю́бят я́годы и мо́гут напа́сть на челове́ка. Медве́дь ест всё: я́годы, ры́бу, мя́со и да́же насеко́мых. Осо́бенно он лю́бит мёд.

au lieu de choisir des polices étranges, ne voulez-vous pas plutôt en corriger la cause ? Ce n'est pas un problème dans l'éditeur de Monaco

Vous n'avez pas encore résolu le problème du curseur. C'est toujours là et je ne pense pas que le problème soit le CSS. C'est la logique du curseur fou

https://github.com/ajaxorg/ace/blob/902d1a02864479cfa7c47f46972ff53fb56924fc/lib/ace/virtual_renderer.js#L1309

et particulièrement
https://github.com/ajaxorg/ace/blob/902d1a02864479cfa7c47f46972ff53fb56924fc/lib/ace/virtual_renderer.js#L1482
https://github.com/ajaxorg/ace/blob/902d1a02864479cfa7c47f46972ff53fb56924fc/lib/ace/virtual_renderer.js#L1509
la coordonnée X est éteinte !
cela affecte aussi les gouttières. la largeur de la police n'est pas du tout prise en compte

ou peut-être
https://github.com/ajaxorg/ace/blob/7285dad33867771a688a96bbf2309f4e995a5b7d/lib/ace/layer/cursor.js#L174

Je suis sur le point de refactoriser mon application pour utiliser monaco à la place, mais je me demande aussi si cela peut être corrigé

même lorsque je règle la police à espacement fixe en russe, le problème est toujours là

Une solution temporaire pour cet enfer de polices à espacement fixe consiste à inclure une police à espacement fixe avec un éditeur ace qui couvre toutes les langues, pas seulement le russe

Je pense qu'il y a un autre problème avec le collage de texte formaté dans l'éditeur ace qui perturbe la position du curseur. Ace ne le désinfecte pas

@blurymind Je pense que le long et le court est l'algorithme d'estimation de la position du curseur est terriblement naïf quant à la façon dont les polices sont rendues dans un moteur de navigateur. Ainsi, plutôt que de mesurer la manière dont les caractères sont réellement dessinés, il semble estimer ce qu'ils "devraient être" en fonction de certains paramètres CSS de base et peut-être de la taille d'un seul caractère, et suppose que les métriques devraient être valables pour le reste du texte ? Je ne sais pas quelles hypothèses sont faites, mais elles semblent être intrinsèquement erronées.

Vous ne pouvez pas vraiment savoir où se trouve la fin d'un bloc de texte rendu sans obtenir ses métriques réelles. Je ne sais pas quel est l'algorithme correct, mais il semble que, parce que c'est si facile à casser, le raisonnement sur la position du curseur et la largeur du texte est fondamentalement défectueux.

Dans mon cas, cela ne s'est produit qu'après avoir tapé "ff" ou "fi"... Pour moi, la désactivation des ligatures a fonctionné.
Alors ajoutez simplement
.ace_editor, .ace_editor div { font-variant-ligatures: none !important; }
au css.

J'espère que ça aide ;)

Salut,
situation étrange ici, mais je peux confirmer que la police n'est pas le seul problème.
Sur mon projet, j'ai un composant utilisant l'éditeur Ace pour entrer JSON. Cela force toujours la police à être "monospace".
Quoi qu'il en soit, cela fonctionne sans problème sur Storybook lorsqu'il est isolé.
Lorsque le composant hérite de CSS (lorsqu'il est utilisé dans l'application, pas dans le livre de contes), j'ai toujours le même problème de dysfonctionnement du curseur.
Il existe de nombreux styles hérités, mais la police est à espacement fixe.

@Copainbig, d' autres règles CSS peuvent également interférer, par exemple la définition de la taille de la police pour tous les éléments div

J'utilise mediawiki + chrome et j'ai rencontré la même erreur.

Problème résolu en utilisant

.ace_editor, .ace_editor * { font-family: "Monaco", "Menlo", "Ubuntu Mono", "Droid Sans Mono", "Consolas", monospace !important; font-size: 12px !important; font-weight: 400 !important; letter-spacing: 0 !important; }

dans Mediawiki:Common.css

@ skbly7 J'étais confronté à ce problème, comme dans la version précédente d'Ace Editor, votre solution a fonctionné mais pour moi, ce n'est pas le cas.

Voici la solution que vous cherchiez,

.ace_editor * {
    font-family: monospace !important;
}

Tout ce que vous devez savoir

Donc, apparemment, vous ne pouvez pas vraiment utiliser une autre police lorsque vous utilisez un éditeur d'as. Cela va gâcher beaucoup d'UX pour votre éditeur de code ou tout ce sur quoi vous pourriez travailler là où vous essayez probablement d'implémenter l'éditeur as. Donc, si vous rencontrez ce problème à l'avenir, vous pouvez utiliser le code indiqué ci-dessus pour vous débarrasser de ce problème de merde, car c'est une saloperie à résoudre. Et non, ce n'était pas une erreur javascript, c'était juste une erreur/un bug CSS à cause duquel cela ne fonctionnait pas comme il était censé le faire.

.ace_editor, .ace_editor * { font-family: "Monaco", "Menlo", "Ubuntu Mono", "Droid Sans Mono", "Consolas", monospace !important; font-size: 12px !important; font-weight: 400 !important; letter-spacing: 0 !important; }

fonctionne très bien pour moi, sur Windows10 en utilisant le package React ace