From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#25777: 25.1; [PATCH] `rectangle--pos-cols' should not move point Date: Fri, 3 Mar 2017 08:44:26 -0800 (PST) Message-ID: <2b01eb6e-53b3-4ca1-abe9-ef3090981863@default> References: <1efbacdb-7d86-454d-b0e0-7a783c47b804@default> <87poi4e7mv.fsf@users.sourceforge.net> <877f4beok7.fsf@users.sourceforge.net> <87tw7edi9d.fsf@users.sourceforge.net> <512a3db8-49d0-4802-aecc-2d71049e0b25@default> <87zih4bhhz.fsf@users.sourceforge.net> <2560c8d7-532e-4882-b3d4-3845312d218f@default> <8737evaz7b.fsf@users.sourceforge.net> <9d559ea2-b66f-4b05-9b95-243651239e13@default> <87zih2a3qg.fsf@users.sourceforge.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 1488559527 25160 195.159.176.226 (3 Mar 2017 16:45:27 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 3 Mar 2017 16:45:27 +0000 (UTC) Cc: 25777@debbugs.gnu.org To: npostavs@users.sourceforge.net Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Mar 03 17:45:17 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1cjqKN-0005Td-Ai for geb-bug-gnu-emacs@m.gmane.org; Fri, 03 Mar 2017 17:45:11 +0100 Original-Received: from localhost ([::1]:59031 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cjqKT-0007dr-9l for geb-bug-gnu-emacs@m.gmane.org; Fri, 03 Mar 2017 11:45:17 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36106) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cjqKJ-0007bs-Dz for bug-gnu-emacs@gnu.org; Fri, 03 Mar 2017 11:45:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cjqKE-0007eI-HE for bug-gnu-emacs@gnu.org; Fri, 03 Mar 2017 11:45:07 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:40474) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cjqKE-0007e3-Cx for bug-gnu-emacs@gnu.org; Fri, 03 Mar 2017 11:45:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1cjqKE-0003Jo-3r for bug-gnu-emacs@gnu.org; Fri, 03 Mar 2017 11:45:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 03 Mar 2017 16:45:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25777 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 25777-submit@debbugs.gnu.org id=B25777.148855947812700 (code B ref 25777); Fri, 03 Mar 2017 16:45:02 +0000 Original-Received: (at 25777) by debbugs.gnu.org; 3 Mar 2017 16:44:38 +0000 Original-Received: from localhost ([127.0.0.1]:38673 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cjqJp-0003Im-QN for submit@debbugs.gnu.org; Fri, 03 Mar 2017 11:44:38 -0500 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:25091) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cjqJn-0003IZ-B0 for 25777@debbugs.gnu.org; Fri, 03 Mar 2017 11:44:36 -0500 Original-Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v23GiSWL001115 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 3 Mar 2017 16:44:29 GMT Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v23GiSOK022224 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 3 Mar 2017 16:44:28 GMT Original-Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v23GiRLi011679; Fri, 3 Mar 2017 16:44:28 GMT In-Reply-To: <87zih2a3qg.fsf@users.sourceforge.net> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 12.0.6753.5000 (x86)] X-Source-IP: aserv0022.oracle.com [141.146.126.234] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 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.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:130116 Archived-At: > >> And looking at the function body again, I think it's checking some oth= er > >> things, and seems to have some side effects with respect to the curren= t > >> rectangle. > > > > No, I don't think so. What did you have in mind? It can > > reset window parameter `rectangle--point-crutches' or variable > > `rectangle--mark-crutches', but I don't think those actions are > > worth mentioning. Do you? >=20 > I thought they might be important. I'm not really sure what the > user-visible effect of those are though. AFAICT, those make use of recorded "crutches" (which are nowhere described explicitly, but which apparently associate a buffer position with a display column). And that, for a given window. They seem important for proper handling of a rectangle regarded with respect to display (columns are a display thing in this context). Put differently, and comparing the code and doc for Emacs 25 with previous releases, it seems that Emacs 25 started treating rectangles, in at least some cases, wrt _display_ and not just buffer position: respect of wide chars, window, places past eol, overlay, redisplay highlighting, even bidi to some extent, etc. The Emacs 25 NEWS says: Rectangle Mark mode can have corners past EOL or in the middle of a TAB. 'C-x C-x' in 'rectangle-mark-mode' now cycles through the four corners. 'string-rectangle' provides on-the-fly preview of the result. This seems to be an ongoing initiative (see the code comments, including for `rectangle--*-char'). We can perhaps expect even more treatment of a "rectangle" wrt its display. > But perhaps if you're not interested in them, we should just > add a function that does only what you want? >=20 > (defun rectangle-columns (start end)... That handles a rectangle in the older sense, but not, I guess, wrt the new concerns that Emacs 25 starts to address (display characteristics and needs - see above). I am really no expert on this. Perhaps the author of the Emacs 25 rectangle code could weigh in on it. My suggestion would be to stick to the code as is, since it is the way it is in order to handle rectangle display better. Sure, the housekeeping code it includes that deals with the "crutches" might not be needed to return columns in most cases. But it is apparently needed in some cases. Columns do need to take wide chars etc. into account. In any case, this code is used in the context of other rect.el code, where that housekeeping seems to play a role. I'd opt for keeping the display/housekeeping code, since the more complex code and the use cases that it handles subsumes the simpler use case that you propose. You can use it wrt rectangle appearance generally, including the rectangular region in a particular window. The use case I have, in `modeline-posn.el', is about the rectangular region. It tries to report on displayed columns, not buffer positions. So I think that for my use case, at least, I need the full-blown `rectangle--pos-cols' code (under whatever name). Now, you will say that `current-column' also claims to DTRT wrt display, taking into account "widths of all the displayed representations of the character...". I don't understand this stuff well enough to say why so much more code apparatus (crutches, a window parameter) is needed for the Emacs 25 support of rectangles. Partly out of concern for my ignorance I'd opt to not try to simplify this. Just one opinion, and quite uninformed in this case. Enlightenment welcome.