bug#19102: 24.4; outline-move-subtree-up/down error at last and second-last subtree

[Stephen Berman <stephen.berman@gmx.net>]

On Sat, 22 Nov 2014 11:32:21 -0500 Stefan Monnier <monnier@IRO.UMontreal.CA> wrote:

>> 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.
>
> I don't understand why there'd be a difference between file and
> non-file buffers.  Outline-mode doesn't care about files at all.
>
> The buffer can end without a newline both in the file and in the
> non-file case, regardless of the require-final-newline setting.

But by default, when a file in outline-mode is saved, if it doesn't end
in a new line one is added, so on revisiting the file the user would
have to delete the final newline for there to be none.  Otherwise, the
only problematic case is a buffer in outline-mode that hasn't been
written to a file yet, since here the user has to add a final newline to
avoid errors.  Here's a minimal recipe to show the problem:

0. emacs -Q
1. C-x b test RET
2. evaluate this sexp:
   (progn
     (switch-to-buffer (generate-new-buffer "test"))
     (insert "* one\n* two\n")
     (outline-mode))
3. Typing `C-c C-v' (outline-move-subtree-down) with point on either
   line, or typing `C-c C-^' (outline-move-subtree-up) with point on the
   second line, raises the error "Wrong type argument:
   number-or-marker-p, nil".  (This is the error of the OP of this bug.)
4. You can avoid this error by replacing both occurrences of `=' with
   `eq' in outline-move-subtree-down, and now `C-c C-v' and `C-c C-^'
   work as expected.
5. Now delete the final newline, so that eob is after the "o" in line 2.
=> Now typing either `C-c C-v' with point on line one or `C-c C-^' with
   point line two result in the buffer containing the single line
   "* two* one".

So once the error in step 3 is fixed, you still have to make sure
there's a final newline.

> OTOH, we can add a final newline pretty much any time we feel like it
> (better not do it gratuitously, but in the present case I can't think
> of any reason why we'd go out of our way just to avoid adding a final
> newline).

Does "we" refer to the outline.el code?  If so, the proposed patch does
just the opposite: it makes sure there's a final newline.

Does this make things clearer?

Steve Berman