From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Justin Paston-Cooper Newsgroups: gmane.emacs.bugs Subject: bug#38392: zap-up-to-char should appear in "Deletion and Killing" Emacs info section and "Command Index" Date: Wed, 27 Nov 2019 23:10:14 +0100 Message-ID: References: <83wobmqv4p.fsf@gnu.org> <83v9r6qu8c.fsf@gnu.org> <4eba4e99-0aa0-4194-a5d1-842b039e377d@default> <22696cf2-bdb7-44d4-a586-daf1a8901250@default> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000007ca7a205985b43e0" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="41786"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 38392@debbugs.gnu.org To: Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Nov 27 23:11:28 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1ia5Wx-000Ako-N5 for geb-bug-gnu-emacs@m.gmane.org; Wed, 27 Nov 2019 23:11:27 +0100 Original-Received: from localhost ([::1]:43682 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ia5Wv-0000mo-31 for geb-bug-gnu-emacs@m.gmane.org; Wed, 27 Nov 2019 17:11:26 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39807) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ia5We-0000jc-4J for bug-gnu-emacs@gnu.org; Wed, 27 Nov 2019 17:11:10 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ia5Wb-0006g2-Us for bug-gnu-emacs@gnu.org; Wed, 27 Nov 2019 17:11:08 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:50371) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ia5WY-0006eU-LN for bug-gnu-emacs@gnu.org; Wed, 27 Nov 2019 17:11:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ia5WY-000250-HJ for bug-gnu-emacs@gnu.org; Wed, 27 Nov 2019 17:11:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Justin Paston-Cooper Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 27 Nov 2019 22:11:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 38392 X-GNU-PR-Package: emacs Original-Received: via spool by 38392-submit@debbugs.gnu.org id=B38392.15748926337956 (code B ref 38392); Wed, 27 Nov 2019 22:11:02 +0000 Original-Received: (at 38392) by debbugs.gnu.org; 27 Nov 2019 22:10:33 +0000 Original-Received: from localhost ([127.0.0.1]:56344 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ia5W4-00024G-Nb for submit@debbugs.gnu.org; Wed, 27 Nov 2019 17:10:33 -0500 Original-Received: from mail-il1-f180.google.com ([209.85.166.180]:46599) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ia5W2-000241-Sa for 38392@debbugs.gnu.org; Wed, 27 Nov 2019 17:10:31 -0500 Original-Received: by mail-il1-f180.google.com with SMTP id q1so22373024ile.13 for <38392@debbugs.gnu.org>; Wed, 27 Nov 2019 14:10:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nZc2Sf4cXEus2e0kCF5VmiP6SSx3wv2LLEMe/yN2CE0=; b=V/edIPnrEZZutKmvZl5oj+5RB1z3tJLBQRbPU/ygclkx5Ds89Hy0+KWIg/aKqYICFS HJXz5CxhOlR/5EbD2sjT9tWZURpvvbf4IrFsed7JgKy7HtA1a4fFjvqGFpBPY6sMh8d/ aNQR+QgN71aP0GcD2uvBmuqihsZoIbpOLwrIQ4nwXSzg5RbA9hgRZ+C+sYVMhVoiyGil 4hSJQ5LfCdGvrr2DohCZ3eZ0G7Dl4T1TSnMquOUrRYk9UKq6v9AL9ozCM6HWwpguiSYV vISQvK0pSUyJhBhAIRgq87PyrALXLCyCxSHolCPLr3cz/F7fZwyvpI1LlYBq9sevfnAV kImQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nZc2Sf4cXEus2e0kCF5VmiP6SSx3wv2LLEMe/yN2CE0=; b=opgzoc1GBS3WTdc4PSdkrh5SJNv6iCp/ZHxBdww5s2hZ71avPvt8MRQXVAlr3R5K43 zzr+6SurjFWO4BPlZB1nTDs038VkFYaktSfrQMAn5DK5t9SMUKZQjJQDwErSDYJ9GFXo 6S+jzqD9LrrPuWDw7meUW7GvnlZ87uXDNHjFAfIWg4O6pWtSwkxBMZ5cI2S8eK3TQCXL 925UA3lKsN1UvBlh7qV1qwfsrq/MgQuLokAQh4RW8OMUxwKucpEAoY8EjWTUUjw4tUE5 PLk/naW975PABp6xrUFnZEq76P1XhPb5tIXyuV9grcVDItwuX/AP5oe5BKZPZgVR7CeV qweA== X-Gm-Message-State: APjAAAUyO9tBBfh7V4YHHxCFZ8A2TJFAHOzGjvAZ3OWzkqTM0Vo9vafW OmzROp9rCG/vztKjNSnwE3Ix9vLRaGKDkECtMIQ= X-Google-Smtp-Source: APXvYqyFC+mMHqtrcuCzNZ+DVd2us8IoKfbS43iVj/wPnOugyXvOjtI+Q/2Lfu0IjQmC6nG5AJ0mlTQBDzAWGMeVg0M= X-Received: by 2002:a92:5a0c:: with SMTP id o12mr49402625ilb.113.1574892625240; Wed, 27 Nov 2019 14:10:25 -0800 (PST) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:172569 Archived-At: --0000000000007ca7a205985b43e0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 27 Nov 2019 at 22:46, Drew Adams wrote: > > I suppose you=E2=80=99re saying that exactly two =E2=80=98inclusivities= =E2=80=99 suffice: =E2=80=98up > to/until=E2=80=99 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 migh= t > 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 me= an > 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=E2=80=99t 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 command= s 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. --0000000000007ca7a205985b43e0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, 27 Nov 2019 at 22:46, Drew Adams <drew.adams@oracle.com> wrote:
> = I suppose you=E2=80=99re saying that exactly two =E2=80=98inclusivities=E2= =80=99 suffice: =E2=80=98up to/until=E2=80=99 and 'through' in your= case, which makes complete sense.

I wasn't speaking to what might suffice.=C2=A0 I was just
pointing out that we use `up-to' for zapping and `until' for search= ing - and we mean the same thing by them.=C2=A0 And I mentioned `through= 9; as a possible name for including the final char.


> I have found that both 'up to' and 'until' are still a= mbiguous, for instance when trying to agree on a date with someone. This am= biguity might carry over to the Emacs world, where a user might not know th= at there is another distinct inclusivity called 'through'. 'up = to' and 'until' can mean either 'inclusive' or 'exc= lusive', this seemingly depending on the phase of the Moon. I still use= the words 'inclusive' and 'exclusive' to confirm. I hope t= hat at least programmers don't find that silly. Of course, there is an = existing precedent of 'up to', 'until', 'through' a= nd 'to'.

Yes, the terms are ambiguous.=C2=A0 If we use consistent
names and the doc is clear then I don't think there's
a problem in practice.=C2=A0 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.=C2=A0



> Regardless of the naming, wouldn=E2=80=99t an inclusivity modifier ove= r the set of two inclusivities be a nice thing to have?

No idea.=C2=A0 Modifier where?=C2=A0 Here we're talking about
function names.=C2=A0 I don't think we need to or should
add such a thing to the names.
<= br>
The idea was that there could be= a key combination entered before commands related to movement, killing, se= arching and so on which would pass an argument to those commands determinin= g 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.
--0000000000007ca7a205985b43e0--