GNU bug report logs -
#19102
24.4; outline-move-subtree-up/down error at last and second-last subtree
Previous Next
Reported by: Paul Rankin <paul <at> tilk.co>
Date: Wed, 19 Nov 2014 08:34:01 UTC
Severity: normal
Found in version 24.4
Done: Stephen Berman <stephen.berman <at> gmx.net>
Bug is archived. No further changes may be made.
Full log
Message #53 received at 19102 <at> debbugs.gnu.org (full text, mbox):
On Thu, 20 Nov 2014 23:43:10 +1000 Paul Rankin <paul <at> tilk.co> wrote:
> Stephen Berman <stephen.berman <at> gmx.net> writes:
>
>> This basically does the same thing as the patch I proposed -- adding a
>> newline if necessary to ensure forward movement -- except that if there
>> was no empty line after the last subtree, your code leaves the added
>> newline dangling. If you add that bit then there is effectively no
>> difference between your version and mine.
>
> For my package's purposes I think it might be better to have that
> dangling newline created it's not already there, but yeah, not for
> outline-mode. (This may be a faux pas on my part.)
Actually, the faux pas seems to have been mine, see my latest reply to
Eli Zaretskii.
> However, how about this for the dangling line code?
>
> (unless empty-last-line
> (save-excursion
> (goto-char (point-max))
> (if (and (bolp) (eolp))
> (delete-char -1)))))
>
>
> That way it doesn't execute if it doesn't need to. Or am I over-thinking
> it?
I guess that could save a few CPU cycles, but I guess the issue is moot
now.
>> However, yours is slightly shorter and slightly cleaner, since it
>> avoids a couple of setq's of let-bound variables, so maybe it's the
>> better fix (after adding the line deletion bit; also, it's not
>> necessary and AFAIK stylistically discouraged to quote a lambda form;
>> and finally, I'm not sure if open-line is more or less appropriate
>> here than newline -- maybe both are too heavyweight and (insert "\n")
>> or even (terpri) would suffice?
>
> Awesome, thanks. I'm not proposing any of my code go into Emacs, so go
> with whatever you think is best.
>
>>> The only thing I'm not sure about is the line marked above. This is not
>>> intended for Emacs, just wanna see if I'm on the right track :)
>>
>> The line you marked tests whether we're moving the subtree down
>> (positive arg) and if so ensures we find the insertion point after it.
>> Or are you asking about something else?
>
> Thanks. Yes that was all, please do not be under any impression that I
> have any idea what I'm doing.
Well, you seem to have at least as much an idea about this as I do (you
probably shouldn't take that as a compliment ;-).
> I did find some problems with saving match data though, so just for the
Yes, the match data should be saved.
> heck of it, I've pasted the function I ended up going with for my
> package (it probably looks like I rewrote things from your patch just to
> be contrary, but it's just to fit with the internal style of the
> package):
> (defun fountain-outline-shift-down (&optional n)
> (interactive "p")
> (outline-back-to-heading)
> (let* ((move-func
> (if (< 0 n)
> 'outline-get-next-sibling
> 'outline-get-last-sibling))
> (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)))
> (insert-point (make-marker))
> (i (abs n)))
> (goto-char beg)
> (while (< 0 i)
> (or (funcall move-func)
> (progn (goto-char beg)
> (message "Cannot shift past higher level")))
> (setq i (1- i)))
> (if (< 0 n)
> (funcall end-point-func))
> (move-marker insert-point (point))
> (insert (delete-and-extract-region beg end))
> (goto-char insert-point)
> (if folded
> (hide-subtree))
> (set-marker insert-point nil)))
As far as I'm concerned it's fine to commit your fix (though probably
without the unrelated more or less stylistic differences); but since I'm
not the maintainer of outline.el nor a core Emacs maintainer, it's up to
(at least one of) them.
Steve Berman
This bug report was last modified 10 years and 238 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.