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

Open
  • Is something wrong?
#58 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
csharp, markdown
Domain
data

Research direction

Read the canonical writer and the playground scenario that produces the shown Markdown, then check docs/formats/fieldworks-markdown.md. Compare the proposed edge-space representations against Pandoc trimming and FieldWorks writing-system preservation; the issue calls for an owner decision on whether readability justifies keeping that data. Done means the representation is decided and the writer behavior or format documentation reflects it.

Written by the indexing model from the issue text.

Description

textediting

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

Dominant language
C#
Stars
1
Forks
0
Avg merge
3h 55m
Merged PRs (30d)
36

Getting set up

  • No Dockerfile or Docker Compose file
  • Has a pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from sillsdev/motif

All issues in sillsdev/motif

Similar issues

More C# issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.