From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: charles@aurox.ch (Charles A. Roelli) Newsgroups: gmane.emacs.devel Subject: Re: visual-region-mode? Date: Thu, 27 Sep 2018 23:01:52 +0200 Message-ID: References: <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> <87d0t9ckzl.fsf@toy.adminart.net> <87a7oa1toa.fsf@toy.adminart.net> <87h8ibx6k5.fsf@toy.adminart.net> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1538081834 12029 195.159.176.226 (27 Sep 2018 20:57:14 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 27 Sep 2018 20:57:14 +0000 (UTC) Cc: emacs-devel@gnu.org To: hw Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Sep 27 22:57:10 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 1g5dLQ-00030m-Rv for ged-emacs-devel@m.gmane.org; Thu, 27 Sep 2018 22:57:09 +0200 Original-Received: from localhost ([::1]:39374 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g5dNX-000360-9k for ged-emacs-devel@m.gmane.org; Thu, 27 Sep 2018 16:59:19 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47470) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g5dNL-00035i-Dt for emacs-devel@gnu.org; Thu, 27 Sep 2018 16:59:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1g5dNH-0002p6-Bh for emacs-devel@gnu.org; Thu, 27 Sep 2018 16:59:07 -0400 Original-Received: from sinyavsky.aurox.ch ([37.35.109.145]:56940) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1g5dNG-0002O6-ST for emacs-devel@gnu.org; Thu, 27 Sep 2018 16:59:03 -0400 Original-Received: from sinyavsky.aurox.ch (sinyavsky.aurox.ch [127.0.0.1]) by sinyavsky.aurox.ch (Postfix) with ESMTP id 021EC2287D for ; Thu, 27 Sep 2018 21:02:48 +0000 (UTC) Authentication-Results: sinyavsky.aurox.ch (amavisd-new); dkim=pass reason="pass (just generated, assumed good)" header.d=aurox.ch DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aurox.ch; h= content-transfer-encoding:content-type:content-type:mime-version :references:subject:subject:in-reply-to:to:from:from:message-id :date:date; s=dkim; t=1538082165; x=1538946166; bh=cKrTvytBJ1G4r pAw9w3xGKlOJx4ORmQfKAZUT0xQZS0=; b=YWVQh9E+Eoav/yNckSVb5RCBXrvIH r8+5s523wuTP4WUPIqzWsw/coX9/ebjoptUvC7cZHE0MmwOcIHsY8GTRerk0HOfV aypxBcWtn8kVPSdBjkBOpfJcf3sVT5nAKAgBvk49erkFRzmUhvWhmH3q+0eYeeCZ WU1vRBJVzWURd4= X-Virus-Scanned: Debian amavisd-new at test.virtualizor.com Original-Received: from sinyavsky.aurox.ch ([127.0.0.1]) by sinyavsky.aurox.ch (sinyavsky.aurox.ch [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id bLRiPPrVe_RN for ; Thu, 27 Sep 2018 21:02:45 +0000 (UTC) Original-Received: from gray (unknown [IPv6:2a02:1205:c693:2d60:c62c:3ff:fe30:b864]) by sinyavsky.aurox.ch (Postfix) with ESMTPSA id 70D3422867; Thu, 27 Sep 2018 21:02:45 +0000 (UTC) In-reply-to: <87h8ibx6k5.fsf@toy.adminart.net> (message from hw on Thu, 27 Sep 2018 00:00:42 +0200) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 37.35.109.145 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:230097 Archived-At: > From: hw > Cc: emacs-devel@gnu.org > Date: Thu, 27 Sep 2018 00:00:42 +0200 > > > Yes, but since we have commands that offer behavior specific to activ= e > > regions, we have the so-called "temporary transient mark mode" -- > > which is a hack to get around this problem. I'd rather have a way to > > explicitly activate/deactivate the region. >=20 > I'm not sure this is a distinct mode; it seems more like the region is > activated regardless of t-m-m being enabled or not and gets somehow > disabled eventually. For what it's worth, the doc of the variable "transient-mark-mode" says: - The pair (only . OLDVAL) enables Transient Mark mode temporarily. After any subsequent point motion command that is not shift-translated, or any other action that would normally deactivate the mark (e.g. buffer modification), the value of =E2=80=98transient-mark-mode=E2=80=99 is set to OLDVAL. > Why would I disable it permanently? I wouldn't have highlighting, ther= e > would be no way to fortify the region --- which is a requirement becaus= e > it can not really be disabled due to a fundamental design flaw --- and = I > would have to narrow the buffer all the time to do something with a > region and to widen it afterwards. You disable "t-m-m" if you don't want a "transient" mark -- as in, activating and deactivating itself seemingly of its own volition. > >> > and without the region randomly deactivating itself after certain > >> > commands as it does with "t-m-m" switched on. > >>=20 > >> [...] > >> > >> Are you referring to commands deactivating the region? =20 > > > > Yes. See the doc of "t-m-m": > > > > The mark is "deactivated" by changing the buffer, > > and after certain other operations that set the mark but whose > > main purpose is something else--for example, incremental search, > > M-<, and M->. >=20 > So this doesn't happen randomly but intentionally --- and you could > re-activate the region if you still want to do something with it. Actually, the documentation lacks at least one other case: scrolling that results in point moving, either with the keyboard or with the mouse. That's one of several arbitrary decisions in the design of t-m-m. > > I'd like to be able to carry this behavior over to commands that > > require an active region for certain things, like M-% does for > > replacing inside a region. >=20 > I guess the right, or consistent, way to do that might be to write more > antagonistic functions that imply "region", like `query-replace-region'= . >=20 > Why don't you make a selection when you want to do something with one? > With t-m-m enabled, that automatically activates the region, and it is > much better than doing stuff with random parts of the buffer. I'd rather tells Emacs when the region is active, than the other way round. > Other than that, I wonder what would go wrong if you made a key binding > to a function that toggles `use-region-p' which you use before and > perhaps after calling functions you want to have a different behaviour. > Maybe `query-replace-region' could make use of that. This would be a binding to activate or deactivate the region, I think. No extra command ("query-replace-region") should be necessary. > Of course, functions implying "region" don't make sense when t-m-m is > enabled: t-m-m already implies "region" in the sense of "selection", > somewhat overcoming the fundamental design flaw of "the region" and the > idea of doing stuff randomly with parts of buffers. The functions > implying "region" are merely children of this design flaw because they > were only invented because nobody wants to narrow and widen their > buffers to do something with parts of them. Narrowing still has its place in everyday editing. > (global-set-key "\C-x\C-x" 'my-exchange-point-and-mark) > (global-set-key (kbd "") > (lambda () > "Toggle the activeness of the region." > (interactive) > (if mark-active (deactivate-mark) > (activate-mark t)))) > (global-set-key [C-f2] 'my-exchange-point-and-mark) > (global-set-key [C-f3] 'previous-buffer) > (global-set-key [C-f5] 'next-buffer) >=20 > Those are actual keys, i. e. I press only one key for them. It's rathe= r > convenient. (The key caps are labeled Print, Help, Record and Play.) >=20 > Unfortunately, it seems Unicomp is the only manufacturer still making > really good keyboards, and the only one for 122 keys ... (The fine > keyboard started working again the next day after I banged it a little, > but I really like having more keys.) Neat, let us know how this approach goes. I don't know what key we could allocate to a command that activates or deactivates the region, since there are not free ones left on average keyboards... > On a side note, why is the function that activates the region called > activate-mark and not activate-region? Is there some purpose or > distinction involved we don't know about? People use "active mark" and "active region" interchangeably, AFAIK. (I know I do!) > > [...] > > Btw, I'm culling most of the CC list since it seems no longer relevan= t. >=20 > I don't know who/what created this list; I suspect it might have been > gnus. Those people had responded to this thread earlier, so they ended up on the list automatically.