From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#73387: 30.0.90; C-x v v in diff-mode doesn't work after C-c C-n Date: Wed, 02 Oct 2024 09:17:45 +0300 Message-ID: <86setf1112.fsf@gnu.org> References: <87zfo28fzu.fsf@zephyr.silentflame.com> <8d0b046e-4b29-4551-b421-e98e212a7b40@yandex.ru> <86msjxefkv.fsf@mail.linkov.net> <87cykt2gkl.fsf@zephyr.silentflame.com> <87jzf01bsk.fsf@zephyr.silentflame.com> <87y13dfgzz.fsf@melete.silentflame.com> <5e956e3b-5891-401a-a898-e339f52ea307@yandex.ru> <87h69ydnvd.fsf@melete.silentflame.com> <878qv9scps.fsf@melete.silentflame.com> <12b28146-5cbc-48cd-b0e2-0c528d4b9b1c@yandex.ru> <87ikudqocz.fsf@melete.silentflame.com> <86jzet2po6.fsf@gnu.org> <875xqcr6ho.fsf@melete.silentflame.com> <868qv73joh.fsf@gnu.org> <7d19c2a7-5b5b-4b92-a98e-232e05ec8403@yandex.ru> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17674"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 73387@debbugs.gnu.org, juri@linkov.net, monnier@iro.umontreal.ca, spwhitton@spwhitton.name To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Oct 02 08:19:10 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1svshZ-0004Q6-RV for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 02 Oct 2024 08:19:10 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1svshT-0006VR-8A; Wed, 02 Oct 2024 02:19:03 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1svshS-0006Uy-41 for bug-gnu-emacs@gnu.org; Wed, 02 Oct 2024 02:19:02 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1svshR-0008A3-Rn for bug-gnu-emacs@gnu.org; Wed, 02 Oct 2024 02:19:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=References:In-Reply-To:From:Date:To:Subject; bh=TArhabXAKQy31rcd8mTSnMJCGf4NrN+bMIBoSER4MVs=; b=XeGKNUgyczknRAd8SSwlFQi6LJbI3mlXXdnQse86fjSzr/U/CMeRz4Zr3up6lSwhQkUWk9YzHkGZXXtNU2HFL2LkXJ1WscYeazBP2gv87G5HQxc6j9LlG1ODO7/D01UX5s4zSE8ZpXmrbGsJbK8tMu1CsF05CZ9Z45Uq5EmRrK5aq/S1rZQqkK4QHlqznsskO05oovb5st6CbrJuxG+ECNfbnGTNbAmt6i62YC2enmAnOHRojc1JomMEHY39ocyRBH7mizIWXuPwhBGxAXTot1CT+3SC6Wr5tczlv/HkwX6kizLGNoRjAi71C9z9RAOFM5O9fAzjZx5GZ+5JFov4QQ==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1svshR-0002Gl-Sb for bug-gnu-emacs@gnu.org; Wed, 02 Oct 2024 02:19:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 02 Oct 2024 06:19:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73387 X-GNU-PR-Package: emacs Original-Received: via spool by 73387-submit@debbugs.gnu.org id=B73387.17278498868661 (code B ref 73387); Wed, 02 Oct 2024 06:19:01 +0000 Original-Received: (at 73387) by debbugs.gnu.org; 2 Oct 2024 06:18:06 +0000 Original-Received: from localhost ([127.0.0.1]:56326 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1svsgY-0002Fd-9z for submit@debbugs.gnu.org; Wed, 02 Oct 2024 02:18:06 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:60978) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1svsgW-0002F6-Bw for 73387@debbugs.gnu.org; Wed, 02 Oct 2024 02:18:05 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1svsgO-00087R-Oz; Wed, 02 Oct 2024 02:17:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=TArhabXAKQy31rcd8mTSnMJCGf4NrN+bMIBoSER4MVs=; b=VGdrnTJh3Yjp gMadV9LCCGWCQCgQxjPfky9GfR5oKz8Lk8v7kvRiNW+JblPqO/GQdzJ+/JjejhJzVq3+GrjNn8rFm AXgmISNlWpo1X9OTqVWWi9/cIEubvR4LOScHHOs4ugdmz8bO0es4gBIqCmYOONJlcwQM8kGsHDyh6 9wzf3rMMWuQ4wmKN33nCX1bsu+jZfzS6KwTtyp/QL3hRVKBC51B8I3r9x22p+qMbyM1XNDNQ1pHEy h5NFWu7J8Buv4+Gz3c9sdGqQui3DNsTKlgZ3Tfpgke4k3vX5poVWCD0ioBCj+3wiTOHacVOLGXNUQ do7wUIK/9Tb4b0N+/V5tOQ==; In-Reply-To: <7d19c2a7-5b5b-4b92-a98e-232e05ec8403@yandex.ru> (message from Dmitry Gutov on Tue, 1 Oct 2024 22:13:03 +0300) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:292817 Archived-At: > Date: Tue, 1 Oct 2024 22:13:03 +0300 > Cc: 73387@debbugs.gnu.org, juri@linkov.net, monnier@iro.umontreal.ca > From: Dmitry Gutov > > On 01/10/2024 18:51, Eli Zaretskii wrote: > > I can explain the rationale for doing the opposite: when describing > > the operation with active region, we usually start with "If the region > > is active..." or with some other similar conditional language. This > > then makes it natural to explain the behavior in the other cases, > > because the active-region one is clearly conditional, and thus not the > > general case. > > When using commands like kill-region, or kill-ring-save, etc, having an > active region is the "usual" case (among other things because without it > the user doesn't see the bounds that would be acted on). > > With the command in question, not having an active region will likely be > the more frequent case, and the boundaries of the text acted upon are > already visible in the buffer. Thanks for providing the rationale. However, IME, clarity of documentation is so important that it trumps many other considerations of the order of describing things, so I'm still not happy with your proposed order. If you search diff-mode.el for "region", you will see that this very file uses the conventions I explained above. Here's one example: (defun diff-context->unified (start end &optional to-context) "Convert context diffs to unified diffs. START and END are either taken from the region \(when it is highlighted) or else cover the whole buffer. With a prefix argument, convert unified format to context format."