From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: npostavs@users.sourceforge.net Newsgroups: gmane.emacs.bugs Subject: bug#25777: 25.1; [PATCH] `rectangle--pos-cols' should not move point Date: Wed, 01 Mar 2017 20:21:44 -0500 Message-ID: <87zih4bhhz.fsf@users.sourceforge.net> 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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1488417681 8711 195.159.176.226 (2 Mar 2017 01:21:21 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 2 Mar 2017 01:21:21 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) Cc: 25777@debbugs.gnu.org To: Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Mar 02 02:21:14 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 1cjFQb-0001Cr-UP for geb-bug-gnu-emacs@m.gmane.org; Thu, 02 Mar 2017 02:21:10 +0100 Original-Received: from localhost ([::1]:49610 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cjFQh-00076S-TO for geb-bug-gnu-emacs@m.gmane.org; Wed, 01 Mar 2017 20:21:15 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44521) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cjFQY-00072o-4U for bug-gnu-emacs@gnu.org; Wed, 01 Mar 2017 20:21:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cjFQU-0000ec-SS for bug-gnu-emacs@gnu.org; Wed, 01 Mar 2017 20:21:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:36927) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cjFQU-0000eM-OR for bug-gnu-emacs@gnu.org; Wed, 01 Mar 2017 20:21:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1cjFQU-0006Xn-JD for bug-gnu-emacs@gnu.org; Wed, 01 Mar 2017 20:21:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: npostavs@users.sourceforge.net Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 02 Mar 2017 01:21: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.148841764025105 (code B ref 25777); Thu, 02 Mar 2017 01:21:02 +0000 Original-Received: (at 25777) by debbugs.gnu.org; 2 Mar 2017 01:20:40 +0000 Original-Received: from localhost ([127.0.0.1]:35126 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cjFQ7-0006Wr-OL for submit@debbugs.gnu.org; Wed, 01 Mar 2017 20:20:39 -0500 Original-Received: from mail-it0-f41.google.com ([209.85.214.41]:38385) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cjFQ5-0006We-Dy for 25777@debbugs.gnu.org; Wed, 01 Mar 2017 20:20:37 -0500 Original-Received: by mail-it0-f41.google.com with SMTP id m27so20111957iti.1 for <25777@debbugs.gnu.org>; Wed, 01 Mar 2017 17:20:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=8hkqOGYDPLkG2LZsmnQjEx0M9gnaLqBJIfdn27sm3kw=; b=JhPpHdfnREqEqSltUGK6ilmRFU2rwCvVCz9DzwHfRABitgAuCv18zsQndMw38Qnbar GtVUAHSnPWpJJj5E3PhVPV4FrFDJ7ZfDQurOgLiub3mKlXIorHBgvqeasErWJnLj/PZE t+WJjQoNFE/9/J0GqGzdtyhqyXoqLbIuP7I7BhkmyockRwEEokQgSu/s5Qd2SKRYfYkX VngsXf+oHkl2r5qYd0V20X/woWglSkesSW2o2zx53zGzaUkYrsKfRkq2+LsgeBBm+Cdn xQ6+VR0kzVRtyR/onaHxYLLJo/dHG/DnYGoIJyIrz/rQ1IP025QWskhXYvqdpIUPZDSe 95sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:references:date :in-reply-to:message-id:user-agent:mime-version; bh=8hkqOGYDPLkG2LZsmnQjEx0M9gnaLqBJIfdn27sm3kw=; b=oaTExf3ScWArPU67ShmS2VOSY7qta6EIpA7QCirhZW0pVlnfcPJBM2BzH/iQP5aVu/ gDvFZANwbA2UO7//kaXW4Bwq5HPsVyMn95b5PIcajt03xmefGQekHoyhC3+B/7nkLIYi oXsELV/HLWBhyg6LcLbT3WspKvcRsTwuPksZPiQ5OKv0LB75tvuuneWW/21r5nw0Ws5d YUQsTk8JdG2KTdq2udtYaDKHuqHMcjaAMX+wRwCHNgOx10ysq6K1zfoTFTsEMjjxMhAv DZLSx9wueS8/MJCkcJkKFuQvPAXaSuAjlWO/g1KnNHaK/5AgmXpvfWxdD2bdmyzP9/OK wDLw== X-Gm-Message-State: AMke39npy1XbF4v1ub7yJxmQWWHMg07N8t3H/cdYKqaOc9mmct5gIE4HJUAo1Iq05XzdOA== X-Received: by 10.36.137.68 with SMTP id s65mr6982978itd.70.1488417631883; Wed, 01 Mar 2017 17:20:31 -0800 (PST) Original-Received: from zony ([45.2.7.65]) by smtp.googlemail.com with ESMTPSA id h62sm2840217ioe.4.2017.03.01.17.20.30 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 01 Mar 2017 17:20:30 -0800 (PST) In-Reply-To: <512a3db8-49d0-4802-aecc-2d71049e0b25@default> (Drew Adams's message of "Tue, 28 Feb 2017 07:11:08 -0800 (PST)") 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:130023 Archived-At: On Tue, Feb 28, 2017 at 10:11 AM, Drew Adams wrote: > > But IMHO, it is generally better to scope a `save-excursion' > as tightly as possible around the movement that you want to > control (hide, erase, undo). Well, my opinion is just about the opposite, but I won't block the patch for that. > Why? Because it makes the code much clearer. It tells you > that outside the `save-excursion' zones point is unlikely > to be moved. And that makes maintenance easier and less > error-prone. I find wider scoping of `save-excursion' to be clearer. It tells you that the code outside the save-excursion zone cares about the original value of point. If there are multiple `save-excursion' zones, I have to look at what comes after each of them, to see what they're using point for. Therefore maintenance becomes harder and more error-prone with many smaller save-excursion calls. With a single save-excursion, it's immediately clear that the value of point is unchanged by the function. And it's clear that adding more code to the function will preserve that property, so maintenance is easier. > Putting a `s-e' at a wider location is analogous to putting > a mutex block at an unnecessarily wide location. (Yes, > there is no real connection between those two, but it comes > down to doing something only where/when it's needed.) I agree they are roughly analogous, but again come to the opposite conclusion. It would be simpler and clearer to make the mutex as wide as possible without causing deadlock, but for performance reasons, we choose as narrow a scope as possible. The performance reasons don't apply to save-excursion though. It comes down to doing something (grabbing/releasing a mutex or saving/restoring point) only where/when it's needed (which would be once at the beginning and end of the function in this case) rather than many redundant times (which would be each time goto-char is called). > If you confirm that you really want that wider scope here > for `s-e' then I'll do that. Otherwise, I'll keep the > `s-e' occurrences where they are but do the renaming and > add a doc string. Let me know. Thx. As I've explained, I prefer wider scope. However, the Emacs project doesn't have a policy on this as far as I know, so we're in a similar situation with pcase vs cond thing: the person making the patch makes the final decision. If you found my arguments for it unconvincing, and still feel strongly that narrower scope is better, I'll accept a patch with the small scopes too.