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: Wed, 19 Sep 2018 22:04:14 +0200 Organization: my virtual residence Message-ID: <87d0t9ckzl.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> <878t403dn5.fsf@toy.adminart.net> <878t3yv0p0.fsf@toy.adminart.net> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1537389592 30487 195.159.176.226 (19 Sep 2018 20:39:52 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 19 Sep 2018 20:39:52 +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 Wed Sep 19 22:39:48 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 1g2jGC-0007lF-Ib for ged-emacs-devel@m.gmane.org; Wed, 19 Sep 2018 22:39:44 +0200 Original-Received: from localhost ([::1]:47213 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g2jII-00027Y-Un for ged-emacs-devel@m.gmane.org; Wed, 19 Sep 2018 16:41:54 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47276) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g2jI8-00027M-9f for emacs-devel@gnu.org; Wed, 19 Sep 2018 16:41:45 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1g2jI7-00006O-1U for emacs-devel@gnu.org; Wed, 19 Sep 2018 16:41:44 -0400 Original-Received: from mo6-p00-ob.smtp.rzone.de ([2a01:238:20a:202:5300::10]:27207) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1g2jI6-0008TR-Dk; Wed, 19 Sep 2018 16:41:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1537389699; 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=4QZdb4sWIjg+nNWMDiKcZ/qdoqjd7oW7gACB67t5Q24=; b=hkyCuuDmVjwVlhMLVAutWfGTXAHNoHIRJkDJz6SbES+QTJ9gD9N8uB55rdBsTTy3ib Lag0m00EWUxFYpsk8FV183Lv5P1zubl6wqvSfmB5UsiEYggjvOobZJ7sJkjnEnW/QLLE 89z+ChkXChu9klWsm+3/VE0yxnRrtc5YLvfeignLugiu2J6kRBjEA6yc+b91a/oUT1tf aZoHm6MwZNq3j1cmF+Z0/KS5iXXR9TOOvvoX7NJTGADRJi7xBHnoTky6LfQbx30kNCxJ y9N2b61d6dKXpwilOgjg2X6zTJ/LvP8L0yFvy8stiki5dRYlJ9266jOwB6QV4lgYPxAH ppzQ== 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 20bdb7u8JKfVKRe (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); Wed, 19 Sep 2018 22:41:31 +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 1g2jHt-0000lS-RJ; Wed, 19 Sep 2018 22:41:29 +0200 In-Reply-To: (Charles A. Roelli's message of "Wed, 19 Sep 2018 21:22:29 +0200") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a01:238:20a:202:5300::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:229969 Archived-At: charles@aurox.ch (Charles A. Roelli) writes: >> From: hw >> Date: Wed, 19 Sep 2018 03:45:23 +0200 >> >> >> Having clarified which operations can be used with a region doesn't mean >> >> that working with a region can be efficiently done. >> > >> > It does for me. For example, see the output of M-x -region TAB. By >> > just knowing a smidgeon of these commands, you can work very >> > efficiently with a region, with all the documentation and help Emacs >> > provides. >> >> That's like saying it doesn't matter how inefficient a procedure is if >> you only have some instructions to perform it. > > When these instructions are so simple, they cannot help being > efficient. Simple instructions can be very inefficient, for example by leaving out important information, by oversimplifying things or by trying to dumb things down. Look at the products Ubiquity makes, they are extremely good examples for oversimplified instructions which make their otherwise great products extremely inefficient whenever you need instructions. Another example are simple instructions for your portable generator which don't make it efficient to power your home (or anything else) with it. They would only make it obvious that the complexity or lack thereof of instructions has nothing to do with how efficient something is. > But if you reject the main building block they use (the > region, active or not), then it makes sense that you find them > inefficient. Rejecting the region or not is entirely unrelated to that clarifying operations to work with it doesn't magically make something efficient. Besides, there are many examples showing that the operations aren't clarified much. >> > If we somehow "disarm" the region by default (as you have >> > suggested), the use of all these commands would be less efficient. >> >> That was Elis idea, and it doesn't refer to commands implying "region" >> but, IIUC, to how to deal with that users might sometimes want to delete >> a region by inserting characters and sometimes not. > > Ok. > >> Well, I have delete-active-region and mark-even-if-inactive set to nil >> and am testing this: >> >> >> (defun my-exchange-point-and-mark (&optional arg) >> "Put the mark where point is now, and point where the mark is >> now. With a prefix argument, toggle the activeness of the >> region. >> >> This function itself is ignorant of `transient-mark-mode'." >> (interactive "P") >> (let ((omark (marker-position (mark-marker)))) >> (if (null omark) >> (user-error "No mark set in this buffer")) >> (set-marker (mark-marker) (point)) >> (goto-char omark)) >> (if arg >> (if mark-active (deactivate-mark) >> (activate-mark t)))) >> >> >> Now I have the region fortified and am able to use the mark for >> navigation without making (or unmaking) a selection from the region >> unless I actually want to. > > Ok. If you decided to turn "t-m-m" off, though, how would you use > "my-exchange-point-and-mark" to ever activate the mark again? In > order for the region to be considered active, "t-m-m" has to enabled > (if only temporarily), hence the current wrangling in > "exchange-point-and-mark" to turn it on temporarily when the user asks > for it. With t-m-m disabled, there is no way to fortify the region, and there is no highlighting. Why would I disable it? With t-m-m disabled, the region can not be activated, so why would I try to do that? My function is ignorant of t-m-m anyway. Why would I disable t-m-m only to ask to temporarily enable it? Are there any disadvantages of having t-m-m enabled that would overcome all the advantages of having it disabled?