From: Stephen Berman <stephen.berman@gmx.net>
To: Stefan Monnier <monnier@IRO.UMontreal.CA>
Cc: paul@tilk.co, 19102@debbugs.gnu.org
Subject: bug#19102: 24.4; outline-move-subtree-up/down error at last and second-last subtree
Date: Sat, 22 Nov 2014 23:20:03 +0100 [thread overview]
Message-ID: <87oaryop2k.fsf@rosalinde.fritz.box> (raw)
In-Reply-To: <jwvwq6nurm8.fsf-monnier+emacsbugs@gnu.org> (Stefan Monnier's message of "Sat, 22 Nov 2014 11:32:21 -0500")
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
next prev parent reply other threads:[~2014-11-22 22:20 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-19 8:29 bug#19102: 24.4; outline-move-subtree-up/down error at last and second-last subtree Paul Rankin
2014-11-19 13:17 ` Stephen Berman
2014-11-19 15:54 ` Eli Zaretskii
2014-11-19 17:09 ` Stephen Berman
2014-11-19 18:56 ` Eli Zaretskii
2014-11-19 20:14 ` Stephen Berman
2014-11-19 20:32 ` Eli Zaretskii
2014-11-19 22:07 ` Stephen Berman
2014-11-20 6:46 ` Paul Rankin
2014-11-20 10:08 ` Stephen Berman
2014-11-20 13:26 ` Paul Rankin
2014-11-20 16:21 ` Eli Zaretskii
2014-11-21 10:32 ` Stephen Berman
2014-11-21 10:42 ` Eli Zaretskii
2014-11-21 17:31 ` Stephen Berman
2014-11-21 19:56 ` Eli Zaretskii
2014-11-21 20:04 ` Stephen Berman
2014-11-22 3:49 ` Paul Rankin
2014-11-22 16:32 ` Stefan Monnier
2014-11-22 16:45 ` Eli Zaretskii
2014-11-22 22:20 ` Stephen Berman [this message]
2014-11-24 4:07 ` Stefan Monnier
2014-11-25 21:58 ` Stephen Berman
2014-11-26 2:34 ` Paul Rankin
2014-11-26 13:38 ` Stephen Berman
2014-11-20 7:22 ` Paul Rankin
2014-11-20 10:09 ` Stephen Berman
2014-11-20 13:43 ` Paul Rankin
2014-11-21 10:33 ` Stephen Berman
2014-11-26 2:43 ` Stefan Monnier
2014-11-26 13:38 ` Stephen Berman
2014-11-26 15:54 ` Stefan Monnier
2014-11-26 19:04 ` Stephen Berman
2014-11-26 22:11 ` Stefan Monnier
2014-11-26 22:25 ` Stephen Berman
2014-11-27 2:18 ` Stefan Monnier
2014-11-27 10:12 ` Stephen Berman
2014-11-27 17:15 ` Stefan Monnier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87oaryop2k.fsf@rosalinde.fritz.box \
--to=stephen.berman@gmx.net \
--cc=19102@debbugs.gnu.org \
--cc=monnier@IRO.UMontreal.CA \
--cc=paul@tilk.co \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.