From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: hw Newsgroups: gmane.emacs.devel Subject: Re: visual-region-mode? Date: Mon, 17 Sep 2018 22:36:30 +0200 Organization: my virtual residence Message-ID: <878t403dn5.fsf@toy.adminart.net> References: <83k1nxvm5j.fsf@gnu.org> <877ejxsm18.fsf@toy.adminart.net> <874lf0oul4.fsf@toy.adminart.net> <877ejuabdt.fsf_-_@toy.adminart.net> <878t473dhg.fsf@toy.adminart.net> <87pnxii2b7.fsf@toy.adminart.net> <87k1nm7eit.fsf@toy.adminart.net> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1537222341 14185 195.159.176.226 (17 Sep 2018 22:12:21 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 17 Sep 2018 22:12:21 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: cpitclaudel@gmail.com, lokedhs@gmail.com, rms@gnu.org, emacs-devel@gnu.org To: charles@aurox.ch (Charles A. Roelli) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Sep 18 00:12:16 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1g21ke-0003bD-CJ for ged-emacs-devel@m.gmane.org; Tue, 18 Sep 2018 00:12:16 +0200 Original-Received: from localhost ([::1]:37552 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g21mk-000876-Ps for ged-emacs-devel@m.gmane.org; Mon, 17 Sep 2018 18:14:26 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59595) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g21lV-000861-O4 for emacs-devel@gnu.org; Mon, 17 Sep 2018 18:13:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1g21lU-0003Hp-N8 for emacs-devel@gnu.org; Mon, 17 Sep 2018 18:13:09 -0400 Original-Received: from mo6-p01-ob.smtp.rzone.de ([2a01:238:20a:202:5301::10]:16715) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1g21lU-0003GD-Fx; Mon, 17 Sep 2018 18:13:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1537222386; s=strato-dkim-0002; d=adminart.net; h=References:Message-ID:Date:In-Reply-To:Subject:Cc:To:From: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=gShU/bikYGiziSrj1wR0nvGc9moy2Ba4TsHHrl1YFzs=; b=tggQlRmiaOpW3gBJ/BTeDT6S+ZTASRY/9kOs0DgJ+7dSx51YqioFl9IDP9JKnHGCej 3Kx1GK3jod6Xzia9IW/FeXAkzXkQnHZBEUYjdodePzvXVuK7o080WX8+nNccFRI5FkbD ARZo9pEIhczEbsELrnljHFWA5khRFtMAU69Z9q6/5r88XMFmnpdy/Q1ispcSNaRQbl6Q zXl3JOgUu0X/jdbECoc2nWOeQSjB86A/iH5UbKPeJMj/FJESoqy22ioQdvBTpghG9vSI v2VFonOtyCndwRASaFnSOO++Jnbm+GO7fNsBJGL/1rccCTLqDn1XcJSWDKeUHQHi7AoW mBlg== X-RZG-AUTH: ":O2kGeEG7b/pS1FS4THaxjVF9w0vVgfQ9xGcjwO5WMRo5c+h5ceMqQWZ3yrBp+AVdIIwXjneEe9k=" X-RZG-CLASS-ID: mo00 Original-Received: from himinbjorg.adminart.net by smtp.strato.de (RZmta 44.1 DYNA|AUTH) with ESMTPSA id 20bdb7u8HMCxAxl (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate); Tue, 18 Sep 2018 00:12:59 +0200 (CEST) Original-Received: from toy.adminart.net ([192.168.3.55]) by himinbjorg.adminart.net with esmtp (Exim 4.90_1) (envelope-from ) id 1g21lL-0000XA-8o; Tue, 18 Sep 2018 00:12:59 +0200 In-Reply-To: (Charles A. Roelli's message of "Sun, 16 Sep 2018 21:31:24 +0200") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a01:238:20a:202:5301::10 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:229905 Archived-At: charles@aurox.ch (Charles A. Roelli) writes: >> From: hw >> Date: Sat, 15 Sep 2018 21:21:30 +0200 >> >> > and the commands using the region >> > are well-marked (e.g. "kill-region", "fill-region", "eval-region", >> > ...). >> >> How does this make hidden regions efficient? > > You have a clear set of actions that can work on the region, anytime, > no matter whether the region is "hidden", or active and visible, or > rectangular. Having clarified which operations can be used with a region doesn't mean that working with a region can be efficiently done. In practise, there is no clear set of operations for regions. Various modes and their options, combined with inconsistencies and weirdness, make it anything but clear what does what under which circumstances. >> I'm simply not using the mark, and it shouldn't be there. The hidden >> regions they create are a source for errors. Make it so they don't >> create regions, and the mark might become usable, provided it can be >> made visible. > > The "hidden regions" can only be a source of error if you type, say, > C-w or M-w at random during editing. What about upcase-region, downcase-region and others that don't come to mind atm? They already clash with transient-mark-mode and are as unsafe as C-w and M-w. Changing mark-even-if-inactive to nil is required to prevent that --- why isn't that the default? > I don't understand why you would do that, Yes, I wouldn't do that intentionally. That these things happen unintentionally is, as I said before, rather unlikely. The hidden regions mean that I always have to consider that they are always there so that I do not make a mistake in the first place. That makes me feel uneasy. It's like having to walk around with a loaded gun all the time: I wouldn't intentionally shoot my feet, and I wouldn't be the first one to accidentally shoot myself if I did. It's just easier to put the gun away and to only get it when I want to use it than it is to exercise perfect gun handling all the time. Do you carry a toolbox around all the time because you are a mechanic, or do you leave it at home when you go to a party where you won't need it? Emacs drags it around to every party because it doesn't know how to let go. If you ask Emacs about it, it'll say it's because it's fundamental. It can be difficult to argue with fundamental. > especially in your case if you haven't selected a region beforehand. You don't need to make a selection for a region you could make a mistake with to always exist once there is a mark somewhere in the buffer. That region always exists all by itself, fundamentally waiting for you to eventually make your mistake. > You could just as well have hit C-/ or C-k, which will also change > your buffer. Yes, there are mistakes users can make the software can not reasonably protect them against. That doesn't mean the software shouldn't protect the users when protecting them is reasonably possible. It also doesn't mean the software should make the mistake worse.