Writer: spaces at the edge of a span are written as  , which is noisy to read

Offen
  • Stimmt etwas nicht?
#172 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
35/100
Issue-Typ
Feature
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
csharp, markdown
Bereich
documentation, internationalization

Rechercherichtung

Read the canonical writer and the FieldWorks Markdown format documentation at docs/formats/fieldworks-markdown.md, then inspect the Latin-and-Arabic playground scenario. Decide whether preserving the edge space’s writing system is worth the noisy   output; document the decision and update the writer or documentation accordingly.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

The canonical writer writes a space at the start or end of a span's text as  , e.g. the Latin-and-Arabic playground scenario gives

[هذه جملة عربية فيها ]{ws=ar}English words[ و ]{ws=ar}1234[ أرقام.]{ws=ar}

It is lossless (the space's writing system is kept, and Pandoc trims edge spaces in a span otherwise), but it is the noisiest thing a person or an agent sees. Options to weigh: write the edge space outside the span when the neighbouring run's writing system can take it without changing what FieldWorks stores (it can't in general: the space's ws is data); a lighter escape (\ is a non-breaking space in Pandoc, so not that); or accept it and say so in docs/formats/fieldworks-markdown.md. Owner decision needed: is the space's writing system worth keeping in the readable form?

Seen while making the playground's Markdown tab (PR for docs/markdown-forward).

🤖 Generated with Claude Code

Vorherrschende Sprache
C#
Sterne
0
Forks
0
Ø Merge
1 Std. 43 Min.
Gemergte PRs (30 T.)
43

Entwicklungsumgebung

Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus sillsdev/SIL.TextEditing

Alle Issues in sillsdev/SIL.TextEditing

Ähnliche Issues

Weitere Issues zu C#

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.