GNU bug report logs -
#50139
27.2; An issue with outline-move-subtree-down
Previous Next
To reply to this bug, email your comments to 50139 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#50139
; Package
emacs
.
(Fri, 20 Aug 2021 20:27:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Alex <alex.giorev <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Fri, 20 Aug 2021 20:27:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Consider a buffer in |outline-mode| having the following text (it is
important that the buffer ends in a newline):
* first heading
the body of the first heading
* second heading
the body of the second heading
Now position point on the second heading and invoke |M-x
outline-hide-subtree|, after which go to the first heading and invoke
|M-x outline-move-subtree-down|. On my computer, this resulted in the
first heading appearing to be on the same visual line as the second.
I've figured out why this happens. It is because
|outline-end-of-subtree| works a bit differently depending on whether
the subtree is the last one in the buffer. In this case, point will be
positioned at the end of the buffer, but when the subtree is not the
last one, it will be positioned on the last position of the last line of
the subtree, before the newline which separates it from the next
heading. I think this implementation is more consistent, as it works the
same in both cases:
|(defun outline-end-of-subtree ()
"Move to the end of the current subtree.
More precisely, move to the last position of the last line of the
subtree: the
position before the newline character of that line."
(outline-back-to-heading)
(let ((level (funcall outline-level)))
;; this loop stops at the end of the buffer or on the first heading
whose
;; level is not less than that of the current subtree
(while (and (not (eobp))
(> (progn (outline-next-heading)
(funcall outline-level))
level)))
(if (eobp)
(if (= (char-before) ?\n) (backward-char))
(backward-char)))) |
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#50139
; Package
emacs
.
(Sat, 21 Aug 2021 13:01:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 50139 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Alex <alex.giorev <at> gmail.com> writes:
> Consider a buffer in outline-mode having the following text (it is important
> that the buffer ends in a newline):
> * first heading
> the body of the first heading
> * second heading
> the body of the second heading
>
> Now position point on the second heading and invoke M-x
> outline-hide-subtree, after which go to the first heading and invoke M-x
> outline-move-subtree-down. On my computer, this resulted in the first heading
> appearing to be on the same visual line as the second.
I'm unable to reproduce this in Emacs 27.2. After following this
recipe, I get a buffer that looks like:
[Message part 2 (image/png, inline)]
[Message part 3 (text/plain, inline)]
Which seems correct to me.
Is this a complete recipe for reproducing the bug, starting from "emacs -Q"?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Added tag(s) moreinfo.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Sat, 21 Aug 2021 13:01:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#50139
; Package
emacs
.
(Sat, 21 Aug 2021 13:20:02 GMT)
Full text and
rfc822 format available.
Message #13 received at 50139 <at> debbugs.gnu.org (full text, mbox):
On Sat, 21 Aug 2021 14:59:59 +0200 Lars Ingebrigtsen <larsi <at> gnus.org> wrote:
> Alex <alex.giorev <at> gmail.com> writes:
>
>> Consider a buffer in outline-mode having the following text (it is important
>> that the buffer ends in a newline):
>> * first heading
>> the body of the first heading
>> * second heading
>> the body of the second heading
>>
>> Now position point on the second heading and invoke M-x
>> outline-hide-subtree, after which go to the first heading and invoke M-x
>> outline-move-subtree-down. On my computer, this resulted in the first heading
>> appearing to be on the same visual line as the second.
>
> I'm unable to reproduce this in Emacs 27.2. After following this
> recipe, I get a buffer that looks like:
[...]
> Which seems correct to me.
>
> Is this a complete recipe for reproducing the bug, starting from "emacs -Q"?
Your image looks like you hid the subtree of the first heading, not the
second as in the recipe. Following the recipe exactly, I can reproduce
the problem in Emacs 27 and 28.
Steve Berman
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#50139
; Package
emacs
.
(Sat, 21 Aug 2021 13:30:02 GMT)
Full text and
rfc822 format available.
Message #16 received at 50139 <at> debbugs.gnu.org (full text, mbox):
Stephen Berman <stephen.berman <at> gmx.net> writes:
> Your image looks like you hid the subtree of the first heading, not the
> second as in the recipe. Following the recipe exactly, I can reproduce
> the problem in Emacs 27 and 28.
Oh, right; misread that. Yes, when I follow the recipe correctly, I can
reproduce the problem here, too.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Removed tag(s) moreinfo.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Sat, 18 Sep 2021 14:17:01 GMT)
Full text and
rfc822 format available.
This bug report was last modified 3 years and 271 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.