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

4 choices; YONV variant #8

Open
wants to merge 6 commits into
base: master
Choose a base branch
from

Conversation

esiegerman
Copy link

I've just started using local_vimrc. It rocks!

Here's an enhancement. The answers it accepts to its prompt are asymmetrical. Only yes is "sticky"; if you say no, it asks you again the next time, and the next, ....

Basically, there are two independent questions encompassed by that prompt:

  • Read the file this time?
  • Remember the answer for next time?

yielding, of course, four possible combinations, of which only two are implemented.

This branch implements the other two.

I actually came up with two variants. Implementations are identical; it's just the names for the choices offered to the user that are different.

One variant, which I'll refer to as YONV for obvious reasons, gives the user these options:

  • Yes: read the file; sticky
  • Once: read the file; not sticky
  • No: don't read the file; not sticky
  • neVer: don't read the file; sticky

That's what's in this PR.

The other variant, YNAV, is:

  • Yes: read the file; not sticky
  • No: don't read the file; not sticky
  • Always: read the file; sticky
  • neVer: don't read the file; sticky

The advantages of YNAV are that yes and no "match", in that neither one is sticky; and the words always and never have nicely matching sticky meanings to go with the sticky choices they represent. The down side is that yes becomes non-sticky, which isn't backward compatible.

YONV is backward compatible; it preserves the current meanings of both yes and no. Plus, I kind of like once as the name for its option. But yes and no remain asymmetrical -- one sticky, one not -- which goes against the grain for me.

In the end, I can't decide which I prefer. So I'm offering you both choices ... um, meta-choices I guess :-) Assuming you like this idea at all, please pick one of the PRs to review, and just close the other one. And speaking of review, this is my first attempt at nontrivial VimL, so please review it especially carefully.

Thanks.

  • Eric

@MarcWeber
Copy link
Owner

I prefer (my) plugins to be as simple as possible. Thus tell me which is the use case for saying "N" permanently?
Another (most simple) solution would be introducing a balcklist. eg

let g:local_vimrc_ignore_path_regex_patterns = [ "/home/foo/par/.*", ".*/my-project/.* ]

This way you can match projects no matter where they are located.

or such. Reading your long message alone scares me (and would scare users).
Thus let's talk about your use case first :)

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

Successfully merging this pull request may close these issues.

2 participants