Fix: Replace em-dashes with ASCII hyphens

Author: djwisdom

docs/developer.md

@@ -400,4 +400,4 @@ Types: `feat`, `fix`, `docs`, `refactor`, `test`
 
 ## License
 
-BSD 2-Clause License — see LICENSE file.
+BSD 2-Clause License - see LICENSE file.

docs/faq.md

@@ -411,4 +411,4 @@ int auto_save_interval = 30;  // Increase to disable
 
 ## License
 
-BSD 2-Clause License — see LICENSE file.
+BSD 2-Clause License - see LICENSE file.

docs/userguide.md

@@ -270,9 +270,9 @@ Settings are stored in `pcode-settings.json` in the editor's directory.
 ### Change History
 
 Changes are tracked in the gutter:
-- **Pink** — Modified line
-- **Green** — Added line
-- **Yellow** — Deleted portion
+- **Pink** - Modified line
+- **Green** - Added line
+- **Yellow** - Deleted portion
 
 ---
 
@@ -331,4 +331,4 @@ Execute commands in the integrated terminal:
 
 ## License
 
-BSD 2-Clause License — see LICENSE file.
+BSD 2-Clause License - see LICENSE file.

docs/versioning.md

@@ -27,131 +27,10 @@ vMAJOR.MINOR.PATCH
 
 ### Purpose
 
-1. **Mark releases** — Clearly identify release commits
-2. **Historical reference** — Easy rollback and comparison
-3. **CI/CD integration** — Build pipelines can trigger on tags
-4. **User reference** — Users can checkout specific versions
-
-### Tag Format
-
-| Type | Format | Example |
-|------|-------|---------|
-| Release | `v*.*.*` | `v0.2.28` |
-| Beta | `v*.*.*-beta*` | `v0.3.0-beta1` |
-| Release Candidate | `v*.*.*-rc*` | `v0.3.0-rc1` |
-
-### Creating Tags
-
-```bash
-# Annotated tag (recommended for releases)
-git tag -a v0.2.28 -m "Release v0.2.28 - Description"
-
-# Lightweight tag
-git tag v0.2.28
-```
-
-### Managing Tags
-
-```bash
-# List all tags
-git tag -l
-
-# List tags with messages
-git tag -l -n
-
-# Push tag to remote
-git push origin v0.2.28
-
-# Push all tags
-git push --tags
-
-# Delete local tag
-git tag -d v0.2.28
-
-# Delete remote tag
-git push origin :refs/tags/v0.2.28
-```
-
----
-
-## Release Process
-
-### Before Releasing
-
-1. **Update VERSION file** with new version number
-2. **Update README.md** with new version in header
-3. **Update documentation** if needed
-4. **Run tests** and verify build
-
-### Creating a Release
-
-```bash
-# 1. Ensure on main branch and up to date
-git checkout main
-git pull
-
-# 2. Create the release tag
-git tag -a v0.2.28 -m "Release v0.2.28 - Description of changes"
-
-# 3. Push tag to remote
-git push origin v0.2.28
-```
-
-### After Release
-
-1. Update VERSION to next development version (e.g., v0.2.29-dev)
-2. Push the version change
-
----
-
-## Version File
-
-The `VERSION` file contains only the version string:
-
-```
-0.2.28
-```
-
-This file is used by:
-- Build scripts to embed version in executable
-- Documentation for version reference
-- CI/CD for release detection
-
-### Sync Version Script
-
-Use the provided scripts to sync version:
-
-```bash
-# PowerShell (Windows)
-.\scripts\sync-version.ps1 0.2.29
-
-# Bash (Linux/macOS/BSD)
-./scripts/sync-version.sh 0.2.29
-```
-
----
-
-## Release Checklist
-
-- [ ] All tests pass
-- [ ] Build succeeds on all platforms
-- [ ] VERSION file updated
-- [ ] README.md header updated
-- [ ] Changelog entry added (if applicable)
-- [ ] Documentation updated
-- [ ] Git tag created with version
-- [ ] Tag pushed to remote
-
----
-
-## Rationale
-
-### Why Use Tags?
-
-1. **Clarity** — Tags make it obvious which commit is a release
-2. **Navigation** — Easy to find any release version
-3. **CI/CD** — Can trigger builds/deployments on tags
-4. **Collaboration** — Team members can reference exact versions
+1. **Mark releases** - Clearly identify release commits
+2. **Historical reference** - Easy rollback and comparison
+3. **CI/CD integration** - Build pipelines can trigger on tags
+4. **User reference** - Users can checkout specific versions
 
 ### Why Annotated Tags?