console.lua: allow persisting the command history

[guidocella]

Disabled by default.

[kasper93]

Why not just append and avoid all the read logic?

[guidocella]

We don't know whether history commands are new or were read from the history file on startup. Even if we kept track of it that would break history deduplication.

[kasper93]

Why history deduplication is needed?

[guidocella]

To avoid duplicate lines? We even have an option for it.

[kasper93]

Well, bit too bloated for my taste, but whatever.

[github-actions]

Download the artifacts for this pull request:

Windows

• mpv-i686-w64-mingw32
• mpv-x86_64-w64-mingw32
• mpv-x86_64-windows-msvc

macOS

• mpv-macos-13-intel
• mpv-macos-14-arm
• mpv-macos-15-arm

[po5]

An issue with doing a full file write instead of appending is that it will end up overwriting history with a zero-byte file if we're out of disk space. Many existing history scripts suffer from this same issue and shrug it off when they lose your history. Don't want this behavior in a builtin script.
Your approach also does weird reordering of the lines, there's no reason new history from the current instance should be wedged in-between different lines that were already written to the history file.
The way you read history is very naive, you can keep the file open and/or resume reading from the last cursor position, saving you a whole new file read to deduplicate entries. This approach works best with appending to the file, which will fix both the history loss and line reordering.
Would even allow you to cheaply write new entries to the file as they come in while preserving the deduplication step, instead of waiting for a clean shutdown event that may not happen, if you want that. Note you may want to dictate buffering yourself with file:setvbuf("full") and file:flush().

I personally think deduplication on write is overkill, but don't skip over the huge block of text since some stuff still applies.

[guidocella]

An issue with doing a full file write instead of appending is that it will end up overwriting history with a zero-byte file if we're out of disk space. Many existing history scripts suffer from this same issue and shrug it off when they lose your history. Don't want this behavior in a builtin script.

That's better than duplicating history lines.

Your approach also does weird reordering of the lines, there's no reason new history from the current instance should be wedged in-between different lines that were already written to the history file.

What? New lines from the current instance are appended to the end.

The way you read history is very naive, you can keep the file open and/or resume reading from the last cursor position, saving you a whole new file read to deduplicate entries. This approach works best with appending to the file, which will fix both the history loss and line reordering.
Would even allow you to cheaply write new entries to the file as they come in while preserving the deduplication step, instead of waiting for a clean shutdown event that may not happen, if you want that. Note you may want to dictate buffering yourself with file:setvbuf("full") and file:flush().

The file is reread to save lines from other mpv instances as written in the comment. Rereading it is not necessary to deduplicate entries or reordering. Saving the last cursor position would break if the beginning of the history file has been modified by other mpv instances.

I personally think deduplication on write is overkill

Deduplication is performed every time a line is added to the history. On write it only deduplicates lines written by other mpv instasnces.