From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stephen Berman Newsgroups: gmane.emacs.bugs Subject: bug#19102: 24.4; outline-move-subtree-up/down error at last and second-last subtree Date: Fri, 21 Nov 2014 18:31:19 +0100 Message-ID: <87fvdcmpeg.fsf@rosalinde.fritz.box> References: <87lhn7s522.fsf@rosalinde.fritz.box> <83lhn789tq.fsf@gnu.org> <87h9xvruan.fsf@rosalinde.fritz.box> <83tx1v6mur.fsf@gnu.org> <87a93nrlql.fsf@rosalinde.fritz.box> <83lhn76iex.fsf@gnu.org> <8761easv3s.fsf@rosalinde.fritz.box> <87r3wytcaa.fsf@rosalinde.fritz.box> <83vbm96dxs.fsf@gnu.org> <87oas0n8sr.fsf@rosalinde.fritz.box> <8361e84yxb.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Trace: ger.gmane.org 1416591148 5665 80.91.229.3 (21 Nov 2014 17:32:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 21 Nov 2014 17:32:28 +0000 (UTC) Cc: paul@tilk.co, 19102@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Nov 21 18:32:20 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Xrs4A-0003Sf-LG for geb-bug-gnu-emacs@m.gmane.org; Fri, 21 Nov 2014 18:32:18 +0100 Original-Received: from localhost ([::1]:41813 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xrs4A-00043z-8c for geb-bug-gnu-emacs@m.gmane.org; Fri, 21 Nov 2014 12:32:18 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33702) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xrs41-00043o-NH for bug-gnu-emacs@gnu.org; Fri, 21 Nov 2014 12:32:15 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xrs3u-0005d8-Jo for bug-gnu-emacs@gnu.org; Fri, 21 Nov 2014 12:32:09 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:43918) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xrs3u-0005ct-Dh for bug-gnu-emacs@gnu.org; Fri, 21 Nov 2014 12:32:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Xrs3t-0001x4-TN for bug-gnu-emacs@gnu.org; Fri, 21 Nov 2014 12:32:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stephen Berman Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 21 Nov 2014 17:32:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19102 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 19102-submit@debbugs.gnu.org id=B19102.14165910987469 (code B ref 19102); Fri, 21 Nov 2014 17:32:01 +0000 Original-Received: (at 19102) by debbugs.gnu.org; 21 Nov 2014 17:31:38 +0000 Original-Received: from localhost ([127.0.0.1]:41131 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xrs3V-0001wO-DL for submit@debbugs.gnu.org; Fri, 21 Nov 2014 12:31:37 -0500 Original-Received: from mout.gmx.net ([212.227.15.18]:60802) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xrs3T-0001wE-21 for 19102@debbugs.gnu.org; Fri, 21 Nov 2014 12:31:36 -0500 Original-Received: from rosalinde.fritz.box ([89.245.122.145]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0Llmcq-1YRCno0SXI-00ZNyR; Fri, 21 Nov 2014 18:31:20 +0100 In-Reply-To: <8361e84yxb.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 21 Nov 2014 12:42:56 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-Provags-ID: V03:K0:93/KMCKveCfMLw32/37W1uyOkggI+S0xYMJ8f3moh/97ULU1bFU b/cWmRouW0TM0mjPrMKr6LbEyQSTyh5oanngXnLtqFRY8KShHPMCwBJwC/rtwOVjGfplX3g OtLlPFLFDfIST0O2pfQjzCLw4zosYRHiPeAHU0E3flfokWlZ4OhbITT5eVTgp+Bz15uGonV 9FT2aF07YK1dp1tbPGBlg== X-UI-Out-Filterresults: notjunk:1; X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.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-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:96388 --=-=-= Content-Type: text/plain On Fri, 21 Nov 2014 12:42:56 +0200 Eli Zaretskii wrote: >> From: Stephen Berman >> Cc: paul@tilk.co, 19102@debbugs.gnu.org >> Date: Fri, 21 Nov 2014 11:32:20 +0100 >> >> > Does it make sense to fix outline-move-subtree-up/down so that they >> > also work when there's no empty line after the last subtree? That's >> >> It didn't occur to me before, but your question prompted me to check and >> I see outline-mode derives from text-mode, which sets >> require-final-newline to mode-require-final-newline, so I guess the >> assumption is indeed that files in outline-mode should end in a newline. > > Does doing that solve the problem without the need to delete the added > line? Yes. As long as there is a final newline, the only change the current code needs is to replace `=' with `eq'. So given that require-final-newline is true for files in outline-mode, the only case that requires adding a final newline is a non-file outline-mode buffer that lacks a final newline. >> > one thing that looks inelegant in your patch, and might also cause >> > some (minor) trouble: what if the user types C-g before this function >> > finishes? >> >> We could avoid the trouble by wrapping the newline call in >> unwind-protect, couldn't we? > > Yes, but it's better to avoid that in the first place. > >> But can C-g really take effect here? >> There is no place in the function where execution halts to wait for user >> feedback. > > C-g sets a flag that is checked by evaluation. I don't understand how this could result in C-g taking effect before the function finishes; could you elaborate? >> I guess those are idle speculations, it does seem that just keeping a >> final newline added by the function is the simplest (and perhaps best) >> fix, so I guess we should commit some version of that fix and see if >> anyone complains. > > Go for it, and thanks. I think that, once the non-file buffer case is taken into account (and not doing means moving a subtree can corrupt the outline by putting two headers on the same line), the cleanest fix is basically the one Paul Rankin proposed in his last post. I've attached it as a diff against emacs-24, where I assume the fix should be committed (I added a comment and tweaked the function Paul posted to avoid irrelevant changes to the current code, and also restricted the error handling by making it a user-error and having it signal only when the user attempts to move over a higher outline level, avoiding an inappropriate message at bob or eob). Does this patch qualify as a tiny change, or does Paul have a copyright assignment on file (I don't have access to the file)? Steve Berman --=-=-= Content-Type: text/x-patch Content-Disposition: inline Content-Description: bug#19102 patch diff --git a/lisp/outline.el b/lisp/outline.el index c7cad31..3243e15 100644 --- a/lisp/outline.el +++ b/lisp/outline.el @@ -645,31 +645,38 @@ the match data is set appropriately." (defun outline-move-subtree-down (&optional arg) "Move the current subtree down past ARG headlines of the same level." (interactive "p") - (let ((movfunc (if (> arg 0) 'outline-get-next-sibling - 'outline-get-last-sibling)) - (ins-point (make-marker)) - (cnt (abs arg)) - beg end folded) - ;; Select the tree - (outline-back-to-heading) - (setq beg (point)) - (save-match-data - (save-excursion (outline-end-of-heading) - (setq folded (outline-invisible-p))) - (outline-end-of-subtree)) - (if (= (char-after) ?\n) (forward-char 1)) - (setq end (point)) - ;; Find insertion point, with error handling + (outline-back-to-heading) + (let* ((movfunc (if (> arg 0) 'outline-get-next-sibling + 'outline-get-last-sibling)) + ;; Find the end of the subtree to be moved as well as the point to + ;; move it to, adding a newline if necessary, to ensure these points + ;; are at bol on the line below the subtree. + (end-point-func (lambda () + (outline-end-of-subtree) + (if (and (eobp) (eolp) (not (bolp))) + (insert-char ?\n)) + (unless (eobp) + (forward-char 1)) + (point))) + (beg (point)) + (folded (save-match-data + (outline-end-of-heading) + (outline-invisible-p))) + (end (save-match-data + (funcall end-point-func))) + (ins-point (make-marker)) + (cnt (abs arg))) + ;; Find insertion point, with error handling. (goto-char beg) (while (> cnt 0) (or (funcall movfunc) - (progn (goto-char beg) - (error "Cannot move past superior level"))) + (unless (or (bobp) (eobp)) + (goto-char beg) + (user-error "Cannot shift past higher level"))) (setq cnt (1- cnt))) (if (> arg 0) - ;; Moving forward - still need to move over subtree - (progn (outline-end-of-subtree) - (if (= (char-after) ?\n) (forward-char 1)))) + ;; Moving forward - still need to move over subtree. + (funcall end-point-func)) (move-marker ins-point (point)) (insert (delete-and-extract-region beg end)) (goto-char ins-point) --=-=-=--