Part 3

From plain text to the code editor

Opening a file is not one single task. Sometimes you only need to read it; sometimes you need one sentence changed; sometimes you need a code-aware surface. Choosing the smallest suitable tool keeps work calm.

Read before you edit

echo and its read alias are useful when you only need to inspect text. Opening an editor just to confirm one value adds unnecessary state. Read first; if the file really needs a change, then open the appropriate editor.

This inspect-first rhythm is especially useful on remote hosting, where every unnecessary write is a write you did not have to risk.

install echo edit code stat

echo project/notes/ideas.txt

read project/notes/ideas.txt

`edit` for text, `code` for source

edit is the lightweight choice for ordinary text files. code is the source editor, with language detection and optional syntax-aware interface features. Both can create a new file with -n when that is intentional.

Do not choose code merely because it looks more powerful. A notes file is often better in edit; PHP, JavaScript, CSS or a .lil script benefit from the code-oriented view.

edit project/notes/ideas.txt

edit project/notes/todo.txt -n

code project/index.php -n

code project/index.php -php

Prefer small, verifiable changes

After creating or editing a file, inspect it again. stat confirms the path and metadata; a read command confirms the content. This two-step check catches wrong filenames and wrong directories before they turn into a chain of later mistakes.

The same principle scales to programming: change one coherent thing, verify it, then continue. Terminal work rewards observable steps.

stat project/index.php

echo project/index.php

The active file shortens the next command

The core remembers the last opened file for commands that support the active-file convention. $ means “the active file”, so after opening project/index.php you can use stat $ without retyping the path.

Treat $ as convenience, not magic. If there is any doubt about which file is active, name the path explicitly. Shortcuts are valuable only while they remain obvious.

code project/index.php

stat $

Source editing and structured editing solve different problems

You can open an INI or JSON file in code and edit punctuation directly. Sometimes that is exactly what you need, especially when comments, whitespace or source layout matter.

But when the real task is “change this logical key to this value”, a format-specific command can be much clearer. The next part is about that boundary: editing data by meaning instead of navigating brackets and separators.

code project/config/app.ini -ini

help ini

Keep your editor routine reusable

A small preparation script can install the editors you prefer, create standard files and open the project in a known state. You do not need to automate the creative editing itself; automate the boring setup around it.

That distinction is useful everywhere: scripts should remove repetition, not remove your understanding of what is being changed.

Keep this as a script

Save this as editor-ready.lil. It makes sure the basic reading and editing tools exist, prepares a note and a PHP file, and leaves you with a predictable starting point.

#lil
@install echo edit code stat
cd lil-playground
edit project/notes/todo.txt -n
code project/index.php -n
stat project/index.php