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.devel Subject: Re: [External] : Re: Adding refactoring capabilities to Emacs Date: Fri, 29 Sep 2023 13:36:22 +0300 Message-ID: <83a5t51d21.fsf@gnu.org> References: <83fs4f36wi.fsf@gnu.org> <1b963d24-51b3-8128-ad14-e4af2c9f0c43@gutov.dev> <8408fa63-af93-ab36-8524-fa12de7918ea@gutov.dev> <87pm25qck5.fsf@posteo.net> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11319"; mail-complaints-to="usenet@ciao.gmane.io" Cc: drew.adams@oracle.com, dmitry@gutov.dev, joaotavora@gmail.com, philipk@posteo.net, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: "Alfred M. Szmidt" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Sep 29 12:37:58 2023 Return-path: Envelope-to: ged-emacs-devel@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 1qmAsg-0002b6-B5 for ged-emacs-devel@m.gmane-mx.org; Fri, 29 Sep 2023 12:37:58 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qmArX-0007Ql-8B; Fri, 29 Sep 2023 06:36:48 -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 1qmArU-0007JO-UN for emacs-devel@gnu.org; Fri, 29 Sep 2023 06:36:44 -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 1qmArS-0004wU-Rg; Fri, 29 Sep 2023 06:36:42 -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=zF6j5k+JahH4b6TBXaSxuIMYBQ27zOIhER43kl/p9so=; b=HQB/nmyIxz82 BHy5o5/O6WbwfvkVrR3YmUgaLAQYr/NorakXiulzvM+xAln7jk0gFh7lDJZgSjavmGzDEw4XF1YJo 8H8EM63uBrc/FtFRFRRrrsiIEGhQM9lmicTitWP3kHIVsj0D+3mVwqTDnTfFuTAIbx+Gg1z/G6/0p 9vj9NRSIJGrQdn+Ot9qzjoAtkrqEl1ypSgD199Lrm1mjd/L9x5r6/csiwHyb51ZQIjuJ7P4pW3OkC v2xDNHySVS4SeyQIdP9QWa6PK5qFnEl9bMHAp6XCx5De2/S04xJw8HtuM4Ys+Rr4sEV2rEpyAmGCO 8UNaPBJi+GhqA/P8LrQf/w==; In-Reply-To: (ams@gnu.org) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:311143 Archived-At: > From: "Alfred M. Szmidt" > Cc: dmitry@gutov.dev, joaotavora@gmail.com, philipk@posteo.net, > monnier@iro.umontreal.ca, eliz@gnu.org, emacs-devel@gnu.org > Date: Tue, 26 Sep 2023 11:22:20 -0400 > > Occur and grep buffers are by default read-only (and there is a > regression in that too It is only a "regression" if you still have your muscle memory from 20 years ago, since it's when we started making the compilation-mode buffers read-opnly. > -- you can no longer edit a grep/occur buffer > easily due to strange font lock or other properties). Of course, you can: this is just one "C-x C-q" away (as in any other read-only buffer). Let's not look for problems where there are none. > They are also not files, if you open a file (any file really) you will > expect to be able to edit it using normal commands not specific to the > mode (i.e. self-inser-command ...). vc-diff etc, are more akin to > occur and grep -- the user doesn't work against the file, but rather a > buffer. That depends on your workflows and preferences, of course. I can easily imagine someone working with *.diff and *.patrh files a lot. > We already have, and are used to, the universal idiom of `C-x C-q' > to toggle a buffer read-only. I use that in grep and occur buffers > without a second thought. Why isn't that "sufficient" for diff > buffers as well? > > Because we are also talking about files on disk. If you save a > compilation buffer (essentially the same thing as M-x grep or M-x > occur) to disk, and re-open it, it will not be read-only -- and it > would make little sense for it to be so. Where as M-x compile _will_ > be read-only. I don't see how this is a problem. There are kinds of files and buffers where sometimes it makes sense to have them editable and sometimes not, sometimes it makes sense to treat them as normal text files, and sometimes as specially-formatted files supported by special modes. Emacs lets you handle these cases in all of the above possibilities, and I see no reason to argue about what is The Only Right Thing here, because there isn't one. > I can see that some might want commands/keys that act on the buffer > content, including to change it in > structured/"legitimate"/refactoring ways, while keeping it > read-only. > > One can have both, diff-mode already allows you to edit the file, and > act on it in a structure manner -- much like any programming mode. And "C-x C-q" or "M-x fundamental-mode" or "M-x text-mode" lets you edit them if you need. > That way, by default, diff buffers would still be read-only by > default, quitable with `q', but also modifiable in all the usual > ways after `C-x C-q'. > > But diff buffers aren't read-only -- it depends on their context. The context depends on the use case and the workflow, and cannot be reliably determined by Emacs. So we picked one possibility, and the others are just one command away. So let's please stop this futile dispute, which once again is entirely about personal preferences.