GNU bug report logs -
#21785
25.0.50; sort-fields fails if region ends in a newline and sort-paragraph fails if it doesn't
Previous Next
Reported by: bruce.connor.am <at> gmail.com
Date: Thu, 29 Oct 2015 12:39:01 UTC
Severity: minor
Tags: fixed, patch
Found in version 25.0.50
Fixed in version 27.1
Done: Lars Ingebrigtsen <larsi <at> mouse.gnus.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 21785 in the body.
You can then email your comments to 21785 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#21785
; Package
emacs
.
(Thu, 29 Oct 2015 12:39:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
bruce.connor.am <at> gmail.com
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Thu, 29 Oct 2015 12:39:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
I noticed this while writing tests for sort.el
With the following buffer contents (the text between the dashes,
including a final newline), issue `C-x h M-x sort-numeric-fields'.
You'll get the error that the last line doesn't have enough fields. I
think that error should not be thrown because of a final newline.
---------------------
1 hi
2 bye
----------------------
Meanwhile take the following buffer contents,
--------------------
paragraph 2
paragraph 1
--------------------
If you issue `sort-paragraphs' on the whole buffer, you'll get this:
--------------------
paragraph 1
paragraph 2
-------------------
In my opinion both behavior are bugs. But surely one of them is, as
the functions should be somewhat consistent on demanding final
newlines.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#21785
; Package
emacs
.
(Thu, 01 Aug 2019 18:39:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 21785 <at> debbugs.gnu.org (full text, mbox):
(I'm going through old bug reports that have unfortunately not gotten
any responses.)
Artur Malabarba <bruce.connor.am <at> gmail.com> writes:
> I noticed this while writing tests for sort.el
>
> With the following buffer contents (the text between the dashes,
> including a final newline), issue `C-x h M-x sort-numeric-fields'.
> You'll get the error that the last line doesn't have enough fields. I
> think that error should not be thrown because of a final newline.
>
> ---------------------
> 1 hi
> 2 bye
>
> ----------------------
>
> Meanwhile take the following buffer contents,
> --------------------
> paragraph 2
>
> paragraph 1
> --------------------
>
> If you issue `sort-paragraphs' on the whole buffer, you'll get this:
> --------------------
> paragraph 1
> paragraph 2
>
> -------------------
>
> In my opinion both behavior are bugs. But surely one of them is, as
> the functions should be somewhat consistent on demanding final
> newlines.
I don't really think this first is a bug. You've asked Emacs to sort
numeric fields, and one of the lines in question doesn't have a numeric
field, so bugging out seems like what's required.
The second does seem like a bug. If the final paragraph doesn't end in
a newline, it's squashed into the following paragraph after sorting.
The following patch fixes the problem (by adding a newline in these
cases). Does this seems like the correct approach for everybody?
diff --git a/lisp/sort.el b/lisp/sort.el
index 6ea1c44060..6ceda8e448 100644
--- a/lisp/sort.el
+++ b/lisp/sort.el
@@ -225,11 +225,17 @@ sort-paragraphs
(narrow-to-region beg end)
(goto-char (point-min))
(sort-subr reverse
- (function
- (lambda ()
- (while (and (not (eobp)) (looking-at paragraph-separate))
- (forward-line 1))))
- 'forward-paragraph))))
+ (lambda ()
+ (while (and (not (eobp)) (looking-at paragraph-separate))
+ (forward-line 1)))
+ (lambda ()
+ (forward-paragraph)
+ ;; If the buffer doesn't end with a newline, add a
+ ;; newline to avoid having paragraphs being
+ ;; concatenated after sorting.
+ (when (and (eobp)
+ (not (bolp)))
+ (insert "\n")))))))
;;;###autoload
(defun sort-pages (reverse beg end)
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Added tag(s) patch.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Thu, 01 Aug 2019 18:39:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#21785
; Package
emacs
.
(Fri, 23 Aug 2019 01:45:02 GMT)
Full text and
rfc822 format available.
Message #13 received at 21785 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> The second does seem like a bug. If the final paragraph doesn't end in
> a newline, it's squashed into the following paragraph after sorting.
>
> The following patch fixes the problem (by adding a newline in these
> cases). Does this seems like the correct approach for everybody?
There were no comments, so I've applied the patch.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Added tag(s) fixed.
Request was from
Lars Ingebrigtsen <larsi <at> mouse.gnus.org>
to
control <at> debbugs.gnu.org
.
(Fri, 23 Aug 2019 01:45:02 GMT)
Full text and
rfc822 format available.
bug marked as fixed in version 27.1, send any further explanations to
21785 <at> debbugs.gnu.org and bruce.connor.am <at> gmail.com
Request was from
Lars Ingebrigtsen <larsi <at> mouse.gnus.org>
to
control <at> debbugs.gnu.org
.
(Fri, 23 Aug 2019 01:45:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Fri, 20 Sep 2019 11:24:10 GMT)
Full text and
rfc822 format available.
This bug report was last modified 4 years and 192 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.