Added WithPageSize AskOpt

[AlecAivazis]

This PR is part of the work summarized in #201. It adds the survey.WithPageSize AskOpt that replaces the modification of survey.PageSize as the way to modify the default page size for prompts.

Since we now have to have a place for "global" configuration of prompts, I had to change the Prompt interface to include a reference to the config.

[coryb]

I see the if pageSize == 0 logic repeated a few times for pagable prompts. I wonder if it would make sense to factor some of this out into a Pagable struct with composition, something like:

type Select struct {
  Pagable
  ...
}
type Pagable struct {
  PageSize int
}
func (p *Pagable) pageSize(config *PromptConfig) int {
  if p.PageSize == 0 {
    return config.PageSize
  }
  return p.PageSize
}

Then in your code:

func (s *Select) OnChange(key run, config *PromptConfig) bool {
  ...
  pageSize := s.pageSize(config)
  ...
}

Going to approve this PR since I dont think the above changes are necessary, just something to think about.

[AlecAivazis]

Yea I thought about that while I was putting this together but it felt like a lot of ceremony for an if statement, especially considering I'd still have to pass the config in. There could be an argument for encapsulating the paginate function into a method. I'll take a look and see if its worth it before merging - thanks for the review!

[AlecAivazis]

So I tried to consolidate the paginate logic into a method on a Pager interface like you suggested. Unfortunately, since you can't set promoted fields, this would force the API to be:

Select{
    Pager{ PageSize: 7 }
}

which is just a little too verbose for me

[coryb]

Okay, yeah, I agree, forgot about that aspect. We could minimize this issue by having a NewSelect etc, with variadic args, ie NewSelect(opts ...func(*Select)) and WithPageSize(s *Select). Not sure if there are other issues that would be resolved or made worse by this direction though.

[AlecAivazis]

Yea that's something to keep in mind. It starts to become very verbose and I think so long as we have sane interpretations of a zero value, we should keep the struct-based API as I think its much simpler for people to grok quickly

[AlecAivazis]

It just occurred to me that it's also very possible that sort of API is what a solution to #105 would look like.