Repository: neovim
Issue: add API for accessing timestamps of recently accessed files (combining shada and current buffers)
Labels: enhancement

### Actual behaviour

No easy way to get a list of recent file/buffer update times.

The shada file has information about recently accessed files (I'm not actually totally sure what is written here, there's marks and changes and some other stuff, but it appears you can extract some kind of recently accessed files list from it). On startup this is used to populate the v:oldfiles variable, which contains the filenames sorted in order of most recently accessed, but not the actual timestamps (as far as I'm aware) though presumably the timestamps seen in the shada file are used to order the oldfiles list.

By default, the shada information used to create oldfiles, is only updated on closing vim, or by doing so manually. Another ticket asked for this behaviour to be changed, but it seemed that actively updating the shada during use was seen as breaking vim compatability, and also something that could be easily done with a config, so not something that was taken forward: https://github.com/neovim/neovim/issues/9523

Neovim also tracks update times for edited buffers, when the file is edited outside of neovim, it compares the timestamp, to alert users if the change happened after their neovim changes and offers options to load or overwrite. I'm not sure if there's any way to actually access these timestamps directly though.

Startify, a plugin that lists your most recently updated files is mentioned in that neovim ticket about updating shada/oldfiles, and it appears it adds its own autocommand to keep the oldfiles list updated without waiting for vim to close (It's not clear to me if/how this affects what is written out to the shada at quit)

Telescope Frecency, a plugin that tries to list your most frecently accessed files, reads oldfiles on initial install, but then creates it's own sqlite database to track file accesses (updating only once per session, as it buckets access by time, and any access in the previous 4 hours is scored the same). Note they also need to track repeated visits to a file, which a simple list of recently accessed files would not.

I filed an issue with another Telescope plugin for switching projects (https://github.com/nvim-telescope/telescope-project.nvim) asking that the projects be sorted by the order in which the files within the project directory had been updated. I thought this would be possible via oldfiles, but the lack of timestamp, and the write on close behaviour meant the dev was looking at keeping their own project access timestamp, which would only be updated when their own tool is used to swap projects.

There are a few other projects doing things with Most Recently Updated, and most seem to either just use oldfiles, (which means some might work better if you happen to have Startify installed?) or invent their own thing. eg. Shougo/neomru.vim which writes to a file. 

### Expected behaviour

I believe this information is already held by Neovim in some form, since it reads it at open and later updates it on close (though exactly what the spec for that stored information is I'm not sure), and would expect that an API to access it, in terms of an oldfiles style ordered list or even better with timestamps would be useful in many different circumstances. I'm not sure if the extra frecency requirments could be easily met if only the most recent timestamps are kept per file, but might be worth considering if it could be added with relative ease.

Some of the objections to updating the shada in real time, were around temp buffers created behind the scenes polutting the data, so it might be worth considering some way to filter those out, either on adding info, or when retrieving it.

I use neovim in the terminal, but I note that one of the MRU plugins I looked at added an "open recent files" menu to GVim, which seems like another potential use case I hadn't thought of (or rather the same use case, but in a different UI). It might be worth canvassing the authors of such plugins as they'd have the most experience of what works for this use case and what other uses it could be put to.