Part 3 · Advanced features / 3.1

Encodings, line endings, and syntax

Erya was written for CJK documents, so encoding sits near the front: detected on open, shown in the status bar at all times, changed with F7, and — crucially — refused rather than mangled when the target encoding cannot represent your text.

Reading time about 14 min Audience Anyone handling older files Prerequisites 2.1 Version v1.0 ・ 2026-08-26

3.1.1

Encoding detection on open

Erya works it out and then keeps telling you, in the status bar.

Figure 3.1.1　The order: BOM first, then “is the whole file valid UTF-8?”, and only then a statistical guess between Big5, GBK, and Shift_JIS.

Erya knows five encodings: UTF-8, UTF-8 BOM, Big5, GBK, and Shift_JIS.
Opening a file never changes it. The detected encoding is only the default for the next save.
Detection is statistical, so short files can be guessed wrong (a Big5 file with a handful of characters may come out as GBK). If the text looks wrong, press F7 and try the next one (see 3.1.2).
UTF-16 and UTF-32 are outside the supported set. Erya reports “detected unsupported text encoding: UTF-16LE” rather than decoding them into nonsense — and rather than presenting them as an editable byte dump.

3.1.2

`F7` changes the save encoding

One press, one step through a cycle of five.

Figure 3.1.2　The cycle. The second-to-last status cell follows along, and the message row says “Switched to Big5; save to complete the encoding conversion”.

F7 does not change the file straight away

It changes which encoding the next save will use. The conversion happens on Ctrl+S. So after pressing F7: save if you meant it, press again to cycle back if you did not, or simply Ctrl+Z — an encoding switch is an undoable step like any other.

The commonest use is converting an old Big5 document to UTF-8: open it (the status bar says Big5), press F7 until it says UTF-8, then Ctrl+S. Going the other way, for a system that only accepts Big5, is exactly the same procedure.

3.1.3

When the conversion is impossible

Erya skips that encoding rather than replacing your characters with question marks.

Big5 has no 𠮟; Shift_JIS has no heart emoji. Many tools would quietly write ? or □ and let you discover it later. Erya does something else:

It tries the conversion. Success means every character in the document is representable.
If even one is not, that encoding is skipped and the next is tried. This is why a single press of F7 can jump from UTF-8 straight to GBK — Big5 in between could not hold something in your text.
If all five fail, you get “Cannot switch to …: it cannot represent every document character”, and the current encoding is left untouched.

Better not to convert than to damage the content

This is Erya's central rule about encodings. A saved file is either complete or still in its original encoding — never half correct and half question marks. If you cannot work out which character is at fault, save a UTF-8 copy and compare it elsewhere.

3.1.4

`F8` switches LF and CRLF

Like the encoding, it takes effect on the next save.

Shown	What it is	Usual home
LF	Line feed \n	Linux, macOS, most languages and config formats
CRLF	Carriage return + line feed \r\n	Windows text files, exports from older systems

Erya detects which one the file uses and shows it in the last status cell.
F8 toggles: “Switched to CRLF; save to complete the line-ending conversion”.
It is undoable with Ctrl+Z.
A missing trailing newline is preserved too: a file that did not end with one will not gain one.

Git says the entire file changed?

That is usually the line endings. Open the file, look at the last status cell, press F8 to put it back, and save — the diff goes clean again.

3.1.5

How syntax highlighting is chosen

By the full filename first, then the extension; otherwise plain text.

A recognised language appears in the fourth status cell (for example Markdown or TOML). No cell means no highlighting.
The usual languages are covered: Rust, C/C++, Go, Python, Java, JavaScript/TypeScript, shell, SQL, Markdown, and more.
So are structured formats: TOML, YAML, JSON, XML, .ini, .conf.
The grey of a selection sits on top of the colours, so the two never interfere.

Very long lines are handled conservatively

When a single line is longer than 64 KiB, or the cursor jumps across a great many lines at once, Erya switches to a bounded highlighting strategy so that parsing cannot freeze the screen. Some lines may briefly appear uncoloured; the content is untouched. Large-file mode disables highlighting entirely (see 3.2.2).

3.1.6

Linux configuration files too

Many of them have no extension, so Erya matches whole filenames.

Category	Filenames and extensions recognised
General config	.conf, .ini, .editorconfig
systemd units	.service, .socket, .timer, .mount, .target, .network
Environment files	.env, .env.*
Structured formats	TOML, YAML, JSON, XML
Shell startup	.bashrc, .profile, .zshrc, /etc/default/*
System configuration	.gitconfig, sshd_config, ssh_config, sudoers, fstab, hosts, resolv.conf
Services	nginx.conf, Apache configs, crontab, Dockerfile/Containerfile, Makefile

That list is a deliberate requirement rather than an accident: one of Erya's expected uses is SSH into a server and edit a config file.

3.1.7

`Ctrl+T` formats the document

Three formats only: TOML, YAML, JSON.

Message row	Meaning
Document formatted; Ctrl+Z to undo	Done — and it counts as one undo step (see 2.4.2).
Document is already formatted	It was already tidy; nothing changed.
Formatting currently supports TOML, YAML, and JSON documents	This file is none of those. Erya goes by the extension.
Formatting failed; document unchanged: …	A syntax error. The message usually names the line, and the document is left exactly as it was.

Comments in TOML and YAML are preserved

Many formatters throw comments away; Erya does not. That matters most in configuration files, where the comment is often the only record of why a setting is what it is.

Use it as a syntax check

After editing a .yaml, press Ctrl+T. Silence means the syntax is valid; an error tells you exactly where it is not. Considerably faster than finding out at deploy time.

3.1.8

Paragraph reflow and width

Rewrap a paragraph to a given width. No default key.

Action name	Key in Classic	What it does
set_paragraph_width	`Alt+M`	Sets the reflow width, from 20 to 500 columns; the default is 80.
reflow_paragraph	`Alt+Q`	Rewraps the paragraph containing the cursor to that width.

Paragraph boundaries are blank lines: Erya searches up and down for the nearest one.
Reflowing from a blank line gives “The cursor is not inside a paragraph”.
Success reports “Paragraph reflowed to 80 columns”, and counts as one undo step.
A width outside 20–500 gives “Paragraph width must be an integer from 20 to 500”.
The reflow measures in terminal columns, so full-width characters count as two and the right edge really does line up.

Both of these are unbound by default

As with phrases and macros (see 2.4.8). Switch to Erya Classic, or bind them yourself in the keymap editor (see 4.1.4).

Reflow changes the file; line wrap only changes the view

Ctrl+L wrapping affects the screen only and never touches a byte of the file; paragraph reflow inserts real line breaks. Use reflow for plain-text documents you hand over, and wrapping for reading long lines yourself.

3.1.9

Common problems

The six that come up most around encodings and formats.

Symptom	Cause and fix
The whole file is garbled	The detection guessed wrong. Press `F7` until it reads correctly, then save (3.1.2).
`F7` pressed, file unchanged	The conversion happens on save (3.1.2).
`F7` skipped an encoding	It cannot represent something in your text, so it was skipped (3.1.3).
Git shows the whole file as modified	The line endings changed. Put them back with `F8` (3.1.4).
A config file has no highlighting	The filename is not on the list (3.1.6), or the file is in large-file mode (3.2.2).
`Ctrl+T` says unsupported	Only TOML, YAML, and JSON are formatted (3.1.7).