jayhemnani
say hi →

/oss · 11 merged

eugenioenko/ttt

A text editor that runs in the terminal but works like a desktop one, shipped as one file with no setup.

the project on GitHub (opens in a new tab)

  1. 20 Oct 2026

    Plugins can now use full regular expressions

    What was broken
    Plugins could only search with Lua's small pattern language. It has no choices between words, no counted repeats and no word edges in the middle, so the Vim-style plugin turned such searches down.
    What I changed
    A new module lets plugins use the full regular expression engine, with the same offsets Lua users already know.
    Why it matters
    Plugin authors can write the searches people expect, with no extra permission.

    see the code, #1016 (opens in a new tab)

  2. 19 Oct 2026

    Text piped into the editor now opens in a new tab

    What was broken
    Sending text into the editor from another command, such as showing a diff, did nothing. The text was thrown away and the editor opened empty.
    What I changed
    The editor now reads the piped text and shows it in an untitled tab. The tab starts clean, so closing it asks no questions.
    Why it matters
    People can look at command output in the editor, the way they can in vim.

    see the code, #1008 (opens in a new tab)

  3. 18 Oct 2026

    Replace in Files keeps a file's last line as it was

    What was broken
    Replacing text across files added a newline to the end of any file that had none, so one small edit also changed the file's last line.
    What I changed
    I made it add the final newline only when the file already had one.
    Why it matters
    A replace changes only the words you asked for, and the diff shows only that.

    see the code, #964 (opens in a new tab)

  4. 15 Oct 2026

    Save As asks before replacing a file

    What was broken
    Save As wrote over whatever file was already at the chosen path, with no prompt and no undo.
    What I changed
    Save As now asks before replacing another file, with Cancel as the default.
    Why it matters
    A typo in a file name can no longer wipe out an existing file.

    see the code, #910 (opens in a new tab)

  5. 15 Oct 2026

    New files follow the save settings too

    What was broken
    Files made with New File ignored the final-newline and trim-trailing-spaces settings, and .editorconfig, when saved. Files opened from disk got them on every save.
    What I changed
    Saving a new file now looks up the same settings an opened file uses.
    Why it matters
    Every file is saved the same way, however it was created.

    see the code, #909 (opens in a new tab)

  6. 13 Oct 2026

    Unchanged Windows-style files no longer show as edited

    What was broken
    Files saved with Windows line endings showed every line as changed in the editor's margin, even when nothing was touched. Other files showed a removed line at the end.
    What I changed
    The margin now reads the saved version the same way the editor reads the file.
    Why it matters
    The change markers point only at lines you really changed.

    see the code, #892 (opens in a new tab)

  7. 13 Oct 2026

    Replace in Files no longer loses unsaved or newer work

    What was broken
    Replace in Files wrote to the saved file at positions found during the search. It threw away unsaved edits in an open tab, and garbled text that had changed since the search.
    What I changed
    The editor now refuses files with unsaved edits, checks each match is still where it was, and names any file it skipped.
    Why it matters
    A project-wide replace never destroys work, and the count it reports is the real one.

    see the code, #891 (opens in a new tab)

  8. 13 Oct 2026

    Ignored files stay hidden in folders with accented names

    What was broken
    The editor hides or dims files that git is told to ignore. If the project sat in a folder with an accented or non-English name, it lost track of them, so clutter like build output showed up.
    What I changed
    The editor now asks git in a way that returns names exactly as written, without git's special quoting.
    Why it matters
    Projects behave the same whatever language the folder names are in.

    see the code, #878 (opens in a new tab)

  9. 13 Oct 2026

    Throwing away one file's changes no longer hits another

    What was broken
    In web projects, folders are often named with brackets. Discarding changes to such a file also quietly undid edits in a different file whose name happened to match the pattern, losing work without warning.
    What I changed
    The editor now tells git to treat each file name exactly as written, as it already did elsewhere.
    Why it matters
    Discard and stage touch only the file you picked, so no one loses work they meant to keep.

    see the code, #877 (opens in a new tab)

  10. 12 Oct 2026

    The line's author is right even before you save

    What was broken
    The editor shows who last changed the line you are on. After adding or removing lines without saving, it looked at the wrong line in the saved file and named the wrong person.
    What I changed
    With unsaved changes, the editor now hands its current text to git, which matches each line to its real author.
    Why it matters
    The name you see is the person who actually wrote that line.

    see the code, #815 (opens in a new tab)

  11. 11 Oct 2026

    Copied GitHub links open the right file again

    What was broken
    The editor copies a GitHub link to your current line. With a space or # in the file name, a folder opened through a shortcut, or some remote styles, the link broke, and one kept your password.
    What I changed
    The link is now built from the real file path, with each part of the name safely escaped, and the password and odd parts of the address are dropped.
    Why it matters
    The link you paste for a teammate opens the line you meant, and never leaks your login.

    see the code, #814 (opens in a new tab)

← every project