A plain, session-less mode for using Fresh as EDITOR and for git

[zipproth]

I don't use Fresh as an IDE (I use another editor for that), but as a replacement for micro or helix: I set it in EDITOR and VISUAL, use it to edit my git commit messages, and open files from my terminal file manager. I also ship it as the default terminal editor in my personal Linux distribution, so any configuration I apply here carries over to other users’ systems.

I sense this isn't the primary use case for Fresh, as it seems to be used mainly as an IDE, though I may be mistaken. Yet, this usage pattern demands fewer capabilities, and precisely that “fewer” is what I seek: open the file it is given, let me edit and save it, then exit. No daemon, no workspace, no dock, no history. Ideally, this would work seamlessly from the start: set fresh as EDITOR, use it with git, and be done.

In version 0.5.3, this doesn't quite work yet. The welcome screen and the homepage suggest using git config --global core.editor "fresh --wait", which results in the error unexpected argument '--wait'. Instead, fresh --help advises configuring git config core.editor 'fresh --cmd daemon open-file . --wait', which brings the session machinery along: the daemon restores and saves the repository's workspace, and neither the --no-restore flag nor the restore_previous_session setting affects this behaviour, causing git commit to reopen files from the prior session as tabs next to COMMIT_EDITMSG.

Pressing Ctrl+Q during a daemon session offers the Detach option as the default. Once detached, the daemon continues operating until one full hour passes without any active client connection. If a git commit is issued in the same repository within that hour, the file is handed over to the daemon: git then hangs, awaiting an editor that nobody can see.

Invoking fresh --no-restore FILE directly comes much closer: it operates within the calling process and blocks until you exit, eliminating the need for git to use --wait entirely. However, it continues to load every workspace file at launch (approximately 900 in my case), opens the dock by default, writes chrome.json upon termination, and, when hot_exit is enabled, restores the unsaved state left by a prior session in the same directory. Thus, my current approach involves a wrapper that executes exec fresh --no-restore "$@", along with these keys in the user config,

{
  "orchestrator_mode": false,
  "editor": { "hot_exit": false },
  "plugins": {
    "orchestrator": { "enabled": false },
    "live_sessions": { "enabled": false }
  }
}

and a one-time rm ~/.local/share/fresh/workspaces/*.json command. This approach functions correctly, and Fresh starts fast again, yet requires understanding of internal mechanics, a custom wrapper script, and a manual cleanup – the opposite of "it just works".

What I would prefer is a first-class plain mode, ideally activated via a single switch in the global config, such as "session_mode": "none" (the name serves merely as a placeholder). With it set:

• neither a workspace nor prompt history is read or written;
• there is no hot-exit stash or restoration mechanism: exiting with unsaved modifications presents the options Save, Discard, or Cancel, yet crash recovery remains functional;
• the dock is inactive and background probing (for git, gh, or external session sources) is disabled;
• a bare fresh command does not attach to a shared daemon.

Per-file cursor memory can stay; it costs little and provides practical value. Part of this functionality already exists through distinct settings, as demonstrated by the configuration shown above. What is missing is a configuration-level equivalent of --no-restore that additionally bypasses the workspace scan, along with a single toggle that consolidates all these behaviours.

With such a switch, setting EDITOR=fresh and git config core.editor fresh would function directly, eliminating the need for a wrapper, and the welcome screen, the homepage, and the --help output could all recommend the identical option. For people who use Fresh both ways, a flag would cover it per invocation, such as EDITOR="fresh --plain". While git and numerous other tools permit arguments in that context, a configuration option also serves those that expect a bare program name.

Some challenges encountered along the way might warrant individual issues, and I'm happy to file any of them separately. Upon upgrading to 0.4.6, a migration turned each of my 875 old scratch-<pid> session files into a standalone workspace. The dock displays every workspace and probes each one using git status, along with git diff and gh pr view within Git repositories; the loop caps concurrent Git probes, but does not restrict gh invocations. This resulted in roughly 90 processes per second for me while the dock remained active, and one daemon's log expanded to approximately 5 GB in under a day, with debug-level logging enabled by default. Finally, saving settings via a temporary file followed by a rename replaces a symlinked config.json with a regular file.

[sinelaw]

Great feedback, there's obvious tension between the two use cases simple editor vs ide and I'm trying to make them both natural. I think a few small tweaks should make it better

[sinelaw]

@zipproth - Here's what I'm planning to do.

What will change

• fresh FILE will open only that file. It won't restore your last workspace and won't save one when you quit. I'm considering making it also not load any other unsaved files, or making that configurable.
• fresh (no arguments), fresh DIR and fresh -a will keep working as today: your workspace, the dock, hot exit for everything.
• fresh --wait FILE will behave the same as fresh FILE. Fresh already waits until you quit.
• Opening the dock or the workspace list will load your saved workspaces then, not at startup.

Your examples, after this change

• git config --global core.editor fresh, then git commit: you'll see only the commit message. No dock, no tabs from your last session, no Welcome tab. Save, quit, and the commit goes through.
• EDITOR=fresh from your file manager: same - because it will actually run fresh some_file.txt, so will load in the simple mode.
• You left notes.txt unsaved in your last session, then run git commit: notes.txt won't appear, and quitting won't ask about it. It will still be waiting the next time you run fresh in that project.
• If you have many saved workspaces: fresh FILE won't read any of them, so startup stays fast.
• A detached daemon is still running and you use fresh --cmd daemon open-file . --wait as git's editor: instead of git hanging on an editor you can't see, your terminal will attach to the daemon.

Makes sense?

[zipproth]

@sinelaw Thanks for the prompt response and for looking at each case. Yes, that makes a lot of sense.

Choosing based on what appears on the command line is superior to the config switch I originally considered: a file means "edit this file", the absence of arguments or a directory means "open my project", and no one needs to change a Fresh setting to use it as EDITOR or within git. Your examples align precisely with what I encountered, and choosing attaching over hanging resolves the daemon scenario effectively.

I would cast my vote in favour of fresh FILE refraining from loading other unsaved files by default, just as illustrated in your notes.txt example: an editor launched by git for a commit message ought not to inquire about anything else when I quit. A configuration option for those who desire such behaviour is perfectly acceptable, of course.

Three details that could be worth examining:

• The output of fresh --help presently suggests using git config core.editor 'fresh --cmd daemon open-file . --wait'. After this change, it might suggest the same configuration shown on the welcome screen and homepage, so all three agree.
• chrome.json is shared by all launches, and currently each exit records whether the dock was open. If fresh FILE continues to modify it, every subsequent git commit would result in the dock being closed the next time Fresh is launched in IDE mode.
• --no-restore currently omits the search, replace, and go-to-line histories. For me, fresh FILE could similarly omit these, though that is a minor point.

I'm happy to test it as soon as it becomes available.

[sinelaw]

Just merged this into master branch: #3556
If you feel like building from source you can try that

[sinelaw]

Improved in 0.5.4, thanks for bringing this up