From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Boruch Baum Newsgroups: gmane.emacs.bugs Subject: bug#30085: 25.2: Documentation for cua-rectangle-mark-mode Date: Wed, 28 Oct 2020 02:40:35 -0400 Message-ID: <20201028064035.anyar4nzv2qv4vce@E15-2016.optimum.net> References: <20180112071426.uq2x3nlcs6jo57hm@E15-2016.optimum.net> <83mv1j2zz4.fsf@gnu.org> <0e8d20ba-84c9-1509-0f52-b8b4b649e00a@cua.dk> <834lnq3o4i.fsf@gnu.org> <20180321124836.puwmknqvo6zketnk@E15-2016.optimum.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17779"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: NeoMutt/20180716 Cc: 30085@debbugs.gnu.org, Kim Storm To: Stefan Kangas Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Oct 28 07:43:10 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1kXfAr-0004Ug-N1 for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 28 Oct 2020 07:43:09 +0100 Original-Received: from localhost ([::1]:35580 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kXfAq-0005ge-FD for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 28 Oct 2020 02:43:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45408) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kXf8p-00048z-Sc for bug-gnu-emacs@gnu.org; Wed, 28 Oct 2020 02:41:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:35324) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kXf8n-0008NE-UZ for bug-gnu-emacs@gnu.org; Wed, 28 Oct 2020 02:41:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kXf8n-0007JF-PS for bug-gnu-emacs@gnu.org; Wed, 28 Oct 2020 02:41:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Boruch Baum Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 28 Oct 2020 06:41:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 30085 X-GNU-PR-Package: emacs Original-Received: via spool by 30085-submit@debbugs.gnu.org id=B30085.160386724928070 (code B ref 30085); Wed, 28 Oct 2020 06:41:01 +0000 Original-Received: (at 30085) by debbugs.gnu.org; 28 Oct 2020 06:40:49 +0000 Original-Received: from localhost ([127.0.0.1]:46870 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kXf8b-0007Ig-BF for submit@debbugs.gnu.org; Wed, 28 Oct 2020 02:40:49 -0400 Original-Received: from mout.gmx.net ([212.227.15.18]:42635) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kXf8Z-0007IS-Cq for 30085@debbugs.gnu.org; Wed, 28 Oct 2020 02:40:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1603867239; bh=MizL/01A+yt7v+FVCdv37XJ5LztbqGmUBWsEBXq4w5g=; h=X-UI-Sender-Class:Date:From:To:Cc:Subject:References:In-Reply-To; b=jK5VIfsSDOvBW5Lmfr/Saq4cJnLT77jdf9Sl9t3q63sfxZD7r2qshI5Ho1SKtPNLe rFq8xS2IJ8tYTemexuwPmCgrIxTGKlkyE1ncnxlB3lxch47xDZARENMsyRWDqlW+Qg gmB+SooaKBTESwGdoj6DJHv7GfWcY3NU5sO3v5cI= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from E15-2016.optimum.net ([71.105.138.177]) by mail.gmx.com (mrgmx005 [212.227.17.184]) with ESMTPSA (Nemesis) id 1MIMfW-1kdBRL13Tg-00EOQw; Wed, 28 Oct 2020 07:40:39 +0100 Content-Disposition: inline In-Reply-To: X-Provags-ID: V03:K1:eO3o2CIX2Q5PCsk4c5XMpZoY4sY4vJZkgxr8rZeasmcUVcddc6n rnMg3kzvlwU0nzk2DQvY0/uFuaxqfKiKlA8Uqm+GC7XcuJPGisOIm//XmWfqF/pIHO8r3ei uRJRHZGxl2G+sYSkI32dsERHmK6lZLIuiqlWJ+L7durE1QBpPg0o3804SFYGXQlw7B1dUWX taZ70N4kNZ+cmPz2aUUwA== X-UI-Out-Filterresults: notjunk:1;V03:K0:OvS1Qyfbs88=:i2R7HD+rCzqk1p6RTuOK5i AnXUFZlG/UMapEOBxLr3SFv5EIFek6caeI8wP94vOEeilkxv8LPhlfWi7enxkRHvEpVe93M/e kX4pbKa0CWB/HmM8Us3PIV2EVe6E7UgT4suypXtHiSRCgamTurlSneeYb/93Gji0oxfx61wWm N2r9nWg4oW3eHJERVqf52k+sGXlCDFc7TYhn2KjmCoK8tmlSR5hdy0CDd2Smwk2q1kHKLmnBg 5SH1OU4FXo5hr+P9bpLzTy8uurJ84S7yJyOXOODDxG6wxmb97bG4/gPJmpSzvWcoDfPD9H/tX UF5sFD/fDfVq5jEjYh5A7t3nExHGGSLOLccIAQfYV0IsL6GC4RX63NQfhKgMK/+FWXQx/xAT1 +A04UI9oIwscvERauCmSB0lxBwBBjTkXoW6rj7K3jlgPZ6wkSgjEoRebGIN1JCDaPVFwro4GO VnOcvTh80gWvTZLReJ9IrsKnB8EDUke3rgSXpi3eUqIa+Syu6caT0DQq8pTdelgsQSXymj1bK nDl4J1qCv84JYm5r1X6NiziEsawFPPtMFuTlLkRSbMTJcH8h9Tjzmol2Z/qNvOhiXT7FWFOUJ ub86XEeruqPxIXEPa5lQVpxU2C2F8DDUTvYL2gs8zWs4XHsT9JIFA2XB8nR1fZUZsKbmEYAnk 2VNUCsnux1cozaUOMTs67yLFH35u40VW/4dwBSVPR0WViyWPnJpbkfhMokl4sWadoM1Sf5JvY GJu3Y1lm36ar3TeVVqpzVmmHlHc4Cu/5LC96rWEYXx4H4yxLK+JUJuiA7440iGGOwKNDWFFN X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:191813 Archived-At: Wow. This is what? Two years old? My vague memory was that this mode seemed very feature-rich and desirable but slightly overlapping the more common rectangle editing functions. When the thread went dead due to lack of response, I stopped investigating and using it. The desirable and unique feature that most stands out in my memory was the mode's ability toggle POINT amongst the four corners of a selected rectangle in order to resize it in any possible direction. I remember the mode had other cool features, but don't remember what they were. One of the deficiencies that I had wanted to address was the mode's lack of documentation, but with the discouraging (lack of) feedback, I just moved on. Following is some feedback: On 2020-10-26 18:50, Stefan Kangas wrote: > Boruch Baum writes: > > > 3. I noticed that `M-m' was bound to `cua-copy-rectangle-as-text' > > instead of `back-to-indentation', so I took the liberty of writing = a > > function `cua-resize-rectangle-back-to-indentation' and binding it = to > > `M-m', which is what most users would expect. If this approved, to > > what should be bound `cua-copy-rectangle-as-text' > > > > 4. Function `cua-resize-rectangle-bot' had a bug in that it always > > placed point at the actual (point-max) even though the rectangle > > corner would not be there. This would occur when (point-max) was at= a > > column number smaller than the left edge of the rectangle. The patc= h > > file includes the fix. > > > > 5. Two commonly used navigation functions, normally bound to `C-a' and > > `C-e' were not remapped. (DONE) > > Could you please provide instructions for how to test the above parts? > I don't use this mode and it's not clear to me what to do. I don't remember how to use the mode and its features (as I mentioned above, it's been two years of non-response), but I see that the notes.txt file that I included along with the patch that there are some tips. I *DO* remember that the remapped functions were to apply operations on the selected rectangle instead of upon the buffer. What I mean is that C-a would go the beginning of the line with the selected rectangle instead of the buffer's beginning of line. And likewise for C-e, M-m. You would need anyway to learn the basics of using the mode before patching it. Once you've figured that out, try C-a, C-e, M-m before and after the patch. Again, some tips are in the notes.txt file accompanying the patch. > Also, could you perhaps split the patch up and make it clear which > parts of your code belong to which of the above points? Nope. At least not anytime reasonably soon. I have a full plate of other FOSS stuff in my inbox just now and other life 'stuff'. > Ideally, if possible, you would also add ChangeLog entries as per > etc/CONTRIBUTE. > > > 6. The help message is remapped from `C-?' to `M-?' for the sanity of > > people like me who use emacs-nox and can only perform a `C-?' by > > typing `C-x @ c ?'. > > I don't understand which part of your patch this refers to, or how to > test it. Could you please clarify? That's easy. It's a single line in the patch... =2D-8<--cut here-(start)------------------------------------------- >8 + (define-key cua--rectangle-keymap (kbd "M-?") 'cua-help-for-rectangle) =2D-8<--cut here-(end)--------------------------------------------- >8 > > 7. The current keybindings are made using an old method of keystroke > > definition that I find a bit scary. Is it OK / desirable to change > > the method uniformly to use `kbd'? > > I have no strong opinion on this, but it seems relatively minor. Perhap= s > it's not worth the code churn. > > First slow steps. > > I've attached a diff with the parts of your patch that I didn't yet push > to master. > > Thanks. Thank you. Word of caution: In the bigger picture, there ought to be a consensus on whether to have two parallel packages that perform basically the same functions in two different ways with two different code-bases. IMO, only one should exist in emacs-core, and if that package can't incorporate the unique features of the other by merging code, the other package should be spun-off to ELPA/MELPA with a note that it has become abandon-ware but retains value. In that spirit, I remember that cua-rectangle mode was clearly *better*, but the development team might shrink from foisting something different on users. In any case, without clear documentation on how to even use the mode, I don't see a chance for the development team to adopt it that way. =2D- hkp://keys.gnupg.net CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0