On Wed, 27 Nov 2019 at 22:46, Drew Adams wrote: > > I suppose you’re saying that exactly two ‘inclusivities’ suffice: ‘up > to/until’ and 'through' in your case, which makes complete sense. > > I wasn't speaking to what might suffice. I was just > pointing out that we use `up-to' for zapping and `until' for searching - > and we mean the same thing by them. And I mentioned `through' as a > possible name for including the final char. > > > I have found that both 'up to' and 'until' are still ambiguous, for > instance when trying to agree on a date with someone. This ambiguity might > carry over to the Emacs world, where a user might not know that there is > another distinct inclusivity called 'through'. 'up to' and 'until' can mean > either 'inclusive' or 'exclusive', this seemingly depending on the phase of > the Moon. I still use the words 'inclusive' and 'exclusive' to confirm. I > hope that at least programmers don't find that silly. Of course, there is > an existing precedent of 'up to', 'until', 'through' and 'to'. > > Yes, the terms are ambiguous. If we use consistent > names and the doc is clear then I don't think there's > a problem in practice. But yes, in conversation, > and particularly with dates/times, people can need > to discuss a bit to be sure to be on the same page. Fair enough. > > > Regardless of the naming, wouldn’t an inclusivity modifier over the set > of two inclusivities be a nice thing to have? > > No idea. Modifier where? Here we're talking about > function names. I don't think we need to or should > add such a thing to the names. > The idea was that there could be a key combination entered before commands related to movement, killing, searching and so on which would pass an argument to those commands determining their inclusivity. Similar to the idea behind T and t in viper-mode. Not sure how it would tie in with the numerical argument, though.