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: Sat, 15 Sep 2018 21:21:30 +0200 Organization: my virtual residence Message-ID: <87k1nm7eit.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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1537051039 27202 195.159.176.226 (15 Sep 2018 22:37:19 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 15 Sep 2018 22:37:19 +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 Sun Sep 16 00:37:15 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 1g1JBh-0006wE-To for ged-emacs-devel@m.gmane.org; Sun, 16 Sep 2018 00:37:14 +0200 Original-Received: from localhost ([::1]:56964 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g1JDo-0003fy-63 for ged-emacs-devel@m.gmane.org; Sat, 15 Sep 2018 18:39:24 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45557) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g1JCi-0003fs-JG for emacs-devel@gnu.org; Sat, 15 Sep 2018 18:38:17 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1g1JCg-0002AZ-W8 for emacs-devel@gnu.org; Sat, 15 Sep 2018 18:38:16 -0400 Original-Received: from mo6-p00-ob.smtp.rzone.de ([2a01:238:20a:202:5300::10]:33352) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1g1JCg-00020T-Gr; Sat, 15 Sep 2018 18:38:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1537051090; 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=pLJoMnsmn6bl14W/g1BtvmwGGtZM6er/a7Chb/4NvQ0=; b=BW8OiHWDJ6g7ZRMmGxb6mrAGuWP/nT0g42xuWyQg3DAjBjvruTYyZicO0rPv5ipyB/ t/EBoCohIBAroy321yzKYuRrfGAyONdNPOJidlXyWR+TCl0lTt6IiW3NUGVLoxzQyJMq iwmz09Wk53GSuJUbKmh98oAQRWN/px5G9X7SVAMoU5GKb0teBor2y19O83XHjRj4yMXC MGc2NsiZDLeBmLRiSI67SdMXoOUFZEEMRA4omBrzxu8LRyeROd848TfLLXLh30Unbh7g MfMlWKAt1FCRaY1ZV3cd/TEpiJ6ZtMP6O8JhXxxJ+Vr5qIPfBwZh9SddADwG/UmB+XvT lsaA== 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 20bdb7u8FMc36D1 (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); Sun, 16 Sep 2018 00:38:03 +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 1g1JCT-0001LT-Ux; Sun, 16 Sep 2018 00:38:01 +0200 In-Reply-To: (Charles A. Roelli's message of "Thu, 13 Sep 2018 22:42: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: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:229826 Archived-At: charles@aurox.ch (Charles A. Roelli) writes: >> From: hw >> Date: Thu, 13 Sep 2018 06:00:32 +0200 >> >> What is efficient about hidden regions the way they are? > > The region has a simple definition, Someone already pointed out that the definition isn't all that simple. > and the commands using the region > are well-marked (e.g. "kill-region", "fill-region", "eval-region", > ...). How does this make hidden regions efficient? >> When I want a region, i. e. a selection, I go where I want >> it and select what I want. > > No need, you have the mark already. ;) No, I don't. What I select doesn't have anything to do with this mark. >> And there is no way to show the mark? > > Besides the ways already mentioned, no. As Alan has suggested, it > becomes second nature to keep its position in your head. And if you > want to know how far away it is from point (as a reminder), there is > the key M-= (or ESC =). Sure, I'm going to remember the positions of marks in the 25 buffers or so I have open at work in the main Emacs session over months, plus the other 5 or 10 in every minor Emacs session plus the ones I have at home --- as if I had nothing better to do than to burden me with irrelevant stuff like that. 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 only purpose of the mark is to make a selection. After the >> selection has been used, editing moves on, and the location has become >> irrelevant. > > Sometimes yes, sometimes no. Better to err on the side of caution, > than to forget all previous marks (as other programs do). Wrong, leaving the mark lurking around to create a hidden region only means to make mistakes a user might make much worse. It is a design flaw. > [...] >> > This would be a good use case for registers storing regions, I think. >> > The mark ring is a useful tool, but it does not give easy, random >> > access to all previous selections. We need a bug report for this. >> >> A feature request for the possibility of having multiple regions that >> can be highlighted, first decoupling making selections from navigation, >> might be an option. I'm not sure if further discussion before making >> such a request is better because there might be pretty strong resistance >> against this from everyone used to and using things the way they have >> been for a long time --- and maybe we're missing something. > > I make a less ambitious suggestion: get registers to store regions > (i.e., two markers). Then we can add functions to highlight them, set > one of them as the "active region", and otherwise operate on them, > either individually or as a set -- a bit like the "zones" Drew has > detailed. Maybe it's better not to use "regions" but "selections". Transient-mark-mode already shows that people don't care about regions but about visible selections. How multiple selections would be implemented wasn't my concern, though. I wouldn't know the best way how to technically do that.