Feature Request: Dump/persist editor state to disk (extension?)

[stianhoiland]

One feature of nano I use to massively accelerate my workflows is its filepos_history file. That file simply contains a MRU list of file paths and their last cursor position. nano itself obviously uses this to remember your cursor position in files between nano launches--which is great!--but I also use this list in shell scripts and workflows to great effect and I couldn't live without these. They are nearly mandatory for someone who doesn't live in their editor but instead live in their shell, which is a use-case very befitting of edit and which you should consider supporting.

nano also persists search queries in search_history, allowing to simply up- and down-arrow in the find dialog like at the shell prompt between nano launches. Very, very handy.

My workflows depend so much on rapidly and usefully entering and exiting my editor that I'm finding myself wanting to write my own just so I can make it dump/persist its text selection and undo history, too (which nano doesn't do).

My request is for the capability of dumping the editor state to disk in a trivially readable and editable format fit for integration with other tools and scripts. In trying to suggest this in the most appropriate way and looking at #17 I think that this feature should be suggested as an extension? By editor state I have in mind:

• Opened file path
• Cursor position
• Scroll offset
• Selections (relevant: Add support for multiple cursors #24)
• Search/replace history
• Undo history

This feature has very high synergy with #89 and together they present a highly integrating view of program extension which gels really well with composition of small tools (as opposed to giant monolithic tools like VSCode, Visual Studio, etc).

[stianhoiland]

As a side note, certain architectural decisions in the editor can hinder or support such a "close to the disk" approach. If I didn't perceive the current implementation as at least okay for this use-case, I wouldn't have suggested this.

[lhecker]

If we used a piece table, persisting the changes to a file (and change history) would definitely be a lot easier. But writing a good piece table implementation is really difficult, so I didn't do that yet...

All the other things should be "relatively" easy to persist though. I wonder if it would make sense to persist it in a binary format to make the code simpler... I guess so.