Jeff King <peff@xxxxxxxx> writes: > ... > does complicate the point of my series, which was to add more intimate > logic about how we handle LESS. > ... > return !x || strchr(x, 'R'); > } > > [...] > } > > but we are still hard-coding a lot of intelligence about "less" here. I am not sure if it is even a good idea for us to have so intimate logic for various pagers in the first place. I'd seriously wonder if it is better to take this position: A platform packager who sets the default pager and/or the default environment for the pager at the build time, or an individual user who tells your Git what pager you want to use and/or with what setting that pager should be run under with environment variables. These people ought to know far better than Git what their specific choices do. Do not try to second-guess them. The potential breakage caused by setting MORE=R unconditionally is a good example. A careless "intimate logic" may think that any pager that is called 'more' would behave like traditional 'more', breaking half the 'more' user population while catering to the other half. > I > wonder if the abstraction provided by the Makefile variable is really > worthwhile. Anybody adding a new line to it would also want to tweak > pager_can_handle_color to add similar logic. And that is why I am not enthused by the idea of adding such logic in the first place. I view the Makefile customization as a way for the packager to offer a sensible default for their platform without touching the code, which is slightly different from your 1. below. > Taking a step back for a moment, we are getting two things out of such a > Makefile variable: > > 1. An easy way for packager to add intelligence about common pagers on > their system. > > 2. DRY between git-sh-setup and the C code. > > I do like (1), but I do not know if we want to try to encode the "can > handle color" logic into a Makefile variable. What would it look like? > > For (2), an alternate method would be to simply provide "git pager" as C > code, which spawns the appropriate pager as the C code would. Then > git-sh-setup can easily build around that. And as to 2., if the answer to the other issue "do we want our code to be intimately aware of pager-specific quirks, or do we just want to give packagers a knob to express their choice of the default?" resolves to the former, I would think that "git pager" would be not just a workable alternative, but would be the only viable one. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html