Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Save named, location and quickfix lists, viminfo alike #16

Open
ntnn opened this issue Sep 4, 2016 · 2 comments
Open

Save named, location and quickfix lists, viminfo alike #16

ntnn opened this issue Sep 4, 2016 · 2 comments
Assignees

Comments

@ntnn
Copy link
Collaborator

ntnn commented Sep 4, 2016

A neat feature would be to save the named lists as well as the
location/quickfix lists like a viminfo file.

For qf/named it's relatively easy, qf is global and named already have
their identifiers.

[quickfix]: {...}
named list 1: {...}
named list 2: {...}

Saving the file like this would make it relatively easy to reparse it,
using json_encode and json_decode to transform the lists.

For location lists, it might be sufficient to save those with their
referring filenames and an incrementing number, but that's still not
a very nice solution.

Or those could just be dropped and only the named (and maybe qf) lists
are saved.

Also this feature would primarily be usefule on a per-project basis, so
the files would need to be created in a separate folder with an
identifiable name, like vim-gutentags does it for tags.

@romainl
Copy link
Owner

romainl commented Sep 4, 2016

If people had ! in their viminfo option, we could simply have QF_QF_LIST, QF_LOC_LIST_FILENAME, QF_NAMED_LIST_LISTNAME, etc. saved directly and automatically in ~/.viminfo. I don't think it would be wise to force that option on the user, though.

Saving and restoring lists to/from a file will add a lot of complexity to the plugin. I'm not sure that's something I want but the idea is certainly interesting.

@ntnn
Copy link
Collaborator Author

ntnn commented Sep 4, 2016

Well, that could be mentioned in the docs - if a user would like to use
the functionality they'll have to add it.

Complexity is a fair point, especially the detection of the base
directory would duplicate lots of code already present in other plugins,
as well as loading/saving per-project.

While the addition would be appreciable I'm not sure if the work would
measure up to the usefull-ness.

I think it'd be more helpful to have auto-filled named lists, but thats
easily done with a function.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants