From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jens Schmidt via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#66780: [PATCH] Improve rectangle-mark-mode when transient-mark-mode is off Date: Sat, 28 Oct 2023 18:36:49 +0200 Message-ID: <87v8aq3dr2.fsf@sappc2.fritz.box> References: <0b1f5f23-b683-4367-beae-332a8d850d32@vodafonemail.de> <83zg03clik.fsf@gnu.org> <871qdf3trr.fsf@sappc2.fritz.box> <83lebnc8tn.fsf@gnu.org> <87y1fm3o78.fsf@sappc2.fritz.box> <83edhedgy4.fsf@gnu.org> Reply-To: Jens Schmidt Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37811"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) Cc: 66780@debbugs.gnu.org, Stefan Kangas To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Oct 28 18:37:49 2023 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 1qwmJp-0009hH-Pj for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 28 Oct 2023 18:37:49 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qwmJY-0008Lx-8W; Sat, 28 Oct 2023 12:37:32 -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 1qwmJW-0008Ln-MS for bug-gnu-emacs@gnu.org; Sat, 28 Oct 2023 12:37:30 -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 1qwmJW-00086B-D3 for bug-gnu-emacs@gnu.org; Sat, 28 Oct 2023 12:37:30 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qwmK2-0008F0-6W for bug-gnu-emacs@gnu.org; Sat, 28 Oct 2023 12:38:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Jens Schmidt Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 28 Oct 2023 16:38:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66780 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 66780-submit@debbugs.gnu.org id=B66780.169851106731659 (code B ref 66780); Sat, 28 Oct 2023 16:38:02 +0000 Original-Received: (at 66780) by debbugs.gnu.org; 28 Oct 2023 16:37:47 +0000 Original-Received: from localhost ([127.0.0.1]:39457 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qwmJn-0008EY-2j for submit@debbugs.gnu.org; Sat, 28 Oct 2023 12:37:47 -0400 Original-Received: from mr4.vodafonemail.de ([145.253.228.164]:37962) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qwmJh-0008EH-HE for 66780@debbugs.gnu.org; Sat, 28 Oct 2023 12:37:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vodafonemail.de; s=vfde-mb-mr2-23sep; t=1698511024; bh=n3MQnNFCp3bX6ECAMwku7flv5yat0AJRY7Pbzh+D8w4=; h=From:To:Subject:References:Date:In-Reply-To:Message-ID:User-Agent: Content-Type:From; b=Se1OVkhh5JyklflAqnpzuFY0h7qNnk+OKTMprS2CYBL36NuZm9qFtyWUr4qhuYOQV 82lrrzHtGlI6EgXQSnBsdKw6T8Zc8PSoMs3eMbkHaaFps2kr3hGlhIGstFt5e/i0RZ YFZWwnZnvmgXxNkKwgytTfI513n91z+/cJsu0skU= Original-Received: from smtp.vodafone.de (unknown [10.0.0.2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by mr4.vodafonemail.de (Postfix) with ESMTPS id 4SHlYX01xyz1xxG; Sat, 28 Oct 2023 16:37:03 +0000 (UTC) Original-Received: from sappc2 (port-92-194-18-245.dynamic.as20676.net [92.194.18.245]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp.vodafone.de (Postfix) with ESMTPSA id 4SHlYK3BnQzHpxb; Sat, 28 Oct 2023 16:36:50 +0000 (UTC) In-Reply-To: <83edhedgy4.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 28 Oct 2023 16:17:39 +0300") X-purgate-type: clean X-purgate: clean X-purgate-size: 5840 X-purgate-ID: 155817::1698511019-E3FFE18D-CB51784C/0/0 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:273451 Archived-At: Eli Zaretskii writes: >> From: Jens Schmidt >> Cc: 66780@debbugs.gnu.org >> Date: Sat, 28 Oct 2023 14:51:07 +0200 >> >> Eli Zaretskii writes: >> >> >> From: Jens Schmidt >> >> Cc: 66780@debbugs.gnu.org >> >> Date: Sat, 28 Oct 2023 12:50:48 +0200 >> >> A general question first: Notwithstanding the discussion of how many use >> it, do we agree that the combination of using shift-select-mode >> _without_ permanent transient-mark-mode ("shift-select-mode-only >> scenario") is a supported scenario in Emacs? > > It is supported de-facto, yes. But that doesn't mean we must > recommend that people use it, if the results are confusing and hard to > predict and understand. Whoever uses this combination, if they > understand the consequences, are free to use it, of course. But if > they don't understand the consequences well enough to be using this > combination in a way that's useful to them, then there's nothing wrong > with saying don't do that. > >> Because that's what this bug is about, in the end: Instead of >> discouraging the shift-select-mode-only users to use rectangle-mark-mode >> I would like to find a solution that helps them. Without affecting any >> other users. Is that not a valid, probably even noble ambition? > > Not necessarily, not where I stand. You found something that you'd > like to fix for your own reasons. That is perfectly legitimate, and > you have all the means of doing so locally: that's what makes Emacs > the perfectly customizable tool. But when you come here and propose > patches, you say something else: that your personal preferences and > itches you'd like to scratch are important enough and general enough > to make those changes in Emacs core so that they affect everyone else. > And that is something that doesn't automatically follows from your > personal preferences and use patterns. It needs more serious > justifications. > > IOW, when you call this a "bug", I can easily agree with you if "bug" > is interpreted as "bug under your personal preferences and use > patterns". But if you want to convince me that it is a "bug" worthy > of making changes in Emacs that will affect everyone, it is not enough > to describe your own personal use case. > >> >> Another option would have been to turn off the confusing bits of RMM >> >> when *permanent* TMM is off. I would have preferred that, actually: A >> >> rectangle-mark-mode that *really* only shows the region-rectangle when >> >> permanent TMM is off but leaves all other functionality (kill, yank, C-x >> >> C-x) unchanged. In that case a conditional minor mode lighter would not >> >> be neccessary, either. >> >> >> >> What do you think about that option? >> > >> > It would be a backward-incompatible change, so it has even more >> > disadvantages IMO. >> >> It would be backward-incompatible only where the behavior currently is >> confusing. > > It is confusing for you, I get that. But we have no reason to believe > it's confusing for everyone else. > >> Another option, not featuring backward-incompatiblity at all but still >> helping shift-select-mode-only users: Adding a rectangle-light-mark-mode >> that provides the selection capabilities, but not the editing surprises >> of rectangle-mark-mode. The documentation could then provide the >> recommendation to use that new mode instead of the other. > > And here you suggest a complication in Emacs, which again, as far as > I'm concerned, requires to be justified. Once again I ask: why not > make these changes, or others that you propose, in your own local > Emacs, and be done? Emacs makes it very easy to make such changes, > definitely for someone who can write patches you submitted in this bug > report. Why do you insist on making these changes in upstream, to > affect everyone else, when all you have is your personal negative > experience with these features? Thanks for your detailed reply, which I feel somewhat hard to reply in the usual inlined style, so please let me allow to pick your points and reply to them: > And that is something that doesn't automatically follows from your > personal preferences and use patterns. It needs more serious > justifications. It's not only my "personal preferences and use patterns". See Sean's bug#42663 plus Michael's bug#16066. So every now and then somebody having transient-mark-mode switched off comes across this. > Why do you insist on making these changes in upstream, to > affect everyone else [...] It's not "everyone else". My solution of adding a conditional minor mode lighter has been designed to specifically affect (== help) only those that do not use permanent transient-mark-mode. > You found something that you'd > like to fix for your own reasons. Really? Go through all that effort of carefully describing the issue and discussing with you just for my own reasons, where I have (indeed) fixed that issue in my .emacs in 10mins? > Once again I ask: why not > make these changes, or others that you propose, in your own local > Emacs, and be done? ^^^^^^^^^^^^^^^^^^^^^^^^^^ That's a rather discouraging request. Is is somewhat in contrast to this statements from the README: You may encounter bugs in this release. If you do, please report them; your bug reports are valuable contributions to the FSF, since they allow us to notice and fix problems on machines we don't have, or in code we don't use often. So are you asking me not to file any bugs? Any "edge-case bugs" in code that you don't use often? Or, in other words: Which of my change requests so far had truly the quality to affect me and only me?