GNU bug report logs - #14853
24.3.50; fill-paragraph doesn't account for whitespace quite right

Previous Next

Package: emacs;

Reported by: Barry OReilly <gundaetiapo <at> gmail.com>

Date: Fri, 12 Jul 2013 17:03:02 UTC

Severity: minor

Tags: notabug

Found in version 24.3.50

Done: Stefan Kangas <stefan <at> marxist.se>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Stefan Kangas <stefan <at> marxist.se>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#14853: closed (24.3.50; fill-paragraph doesn't account for
 whitespace quite right)
Date: Wed, 14 Aug 2019 09:28:02 +0000
[Message part 1 (text/plain, inline)]
Your message dated Wed, 14 Aug 2019 11:26:43 +0200
with message-id <CADwFkmn5EHfEvhtdkTo9DTmDzzpkxgE4KpKwooziiXFtxz8mmA <at> mail.gmail.com>
and subject line Re: bug#14853: 24.3.50; fill-paragraph doesn't account for whitespace quite right
has caused the debbugs.gnu.org bug report #14853,
regarding 24.3.50; fill-paragraph doesn't account for whitespace quite right
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
14853: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=14853
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
From: Barry OReilly <gundaetiapo <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3.50; fill-paragraph doesn't account for whitespace quite right
Date: Fri, 12 Jul 2013 13:02:43 -0400
[Message part 3 (text/plain, inline)]
Let foo.txt have this text:

xxxxx xx x xxxxxxx xxxx xxxx xxxxxx xxx xxxxxxx xxxxxxxxxx. xxxxx xx x
xxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xx x xxxxxxx xx
xxxxxxxxxxxxxx. xxxx xxxxxxxxxx xxxxx x xxxxxxxx xxxxxx xxx xxxx xxx'x
xxx xxx xxxx xxxxx xxxxxxxx xxxxx.

Select all of the text and execute the fill-paragraph command.

Expected:

xxxxx xx x xxxxxxx xxxx xxxx xxxxxx xxx xxxxxxx xxxxxxxxxx. xxxxx xx x
xxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xx x xxxxxxx xx xxxxxxxxxxxxxx.
xxxx xxxxxxxxxx xxxxx x xxxxxxxx xxxxxx xxx xxxx xxx'x xxx xxx xxxx
xxxxx xxxxxxxx xxxxx.

But it leaves it unchanged. It seems to let the space following the
period unduly influence whether to pull the word up to the second
line.

---

In GNU Emacs 24.3.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.10.4)
 of 2013-06-18 on psd15
Windowing system distributor `The X.Org Foundation', version 11.0.70101000
System Description:    Red Hat Enterprise Linux Client release 5.4 (Tikanga)

Configured using:
 `configure
 --prefix=/redacted/user/boreilly/sw/emacs-install-trunk-20899d085afe62520113b5acbfe3dbba57823dc9
 --with-gif=no'

Important settings:
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=none
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: Text

Minor modes in effect:
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
<help-echo> <help-echo> <help-echo> <help-echo> <down-mouse-1>
<mouse-movement> <mouse-movement> <drag-mouse-1> M-q
<down-mouse-1> <mouse-1> M-x r e p o r t <tab> <re
turn>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
foo.txt has auto save data; consider M-x recover-this-file

Load-path shadows:
None found.

Features:
(shadow sort nadvice gnus-util mail-extr emacsbug message format-spec
rfc822 mml easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse
rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils time-date tooltip ediff-hook
vc-hooks lisp-float-type mwheel x-win x-dnd tool-bar dnd fontset image
regexp-opt fringe tabulated-list newcomment lisp-mode register page
menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core frame cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote make-network-process dbusbind dynamic-setting
system-font-setting font-render-setting move-toolbar gtk x-toolkit x
multi-tty emacs)
[Message part 4 (text/html, inline)]
[Message part 5 (message/rfc822, inline)]
From: Stefan Kangas <stefan <at> marxist.se>
To: Noam Postavsky <npostavs <at> users.sourceforge.net>
Cc: 14853-done <at> debbugs.gnu.org, Barry OReilly <gundaetiapo <at> gmail.com>,
 Andreas Schwab <schwab <at> linux-m68k.org>
Subject: Re: bug#14853: 24.3.50; fill-paragraph doesn't account for whitespace
 quite right
Date: Wed, 14 Aug 2019 11:26:43 +0200
npostavs <at> users.sourceforge.net writes:

> tags 14853 notabug
> quit
>
> Barry OReilly <gundaetiapo <at> gmail.com> writes:
>
>> On Fri, Jul 12, 2013 at 1:18 PM, Andreas Schwab <schwab <at> linux-m68k.org>wrote:
>>
>>> See sentence-end-double-space.
>>>
>>>
>> Does it matter when the period is going at the end of the line? In that
>> case there are zero spaces after it. Anyway, I reproduced the issue with
>> sentence-end-double-space t and nil.
>
> With sentence-double-end-space t this
>
> xxxxx xx x xxxxxxx xxxx xxxx xxxxxx xxx xxxxxxx xxxxxxxxxx.  xxxx xx x
> xxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xx x xxxxxxx xx
> xxxxxxxxxxxxxx.  xxx xxxxxxxxxx xxxxx x xxxxxxxx xxxxxx xxx xxxx xxx'x
> xxx xxx xxxx xxxxx xxxxxxxx xxxxx.
>
> fills to
>
> xxxxx xx x xxxxxxx xxxx xxxx xxxxxx xxx xxxxxxx xxxxxxxxxx.  xxxx xx x
> xxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xx x xxxxxxx xx xxxxxxxxxxxxxx.
> xxx xxxxxxxxxx xxxxx x xxxxxxxx xxxxxx xxx xxxx xxx'x xxx xxx xxxx
> xxxxx xxxxxxxx xxxxx.
>
> so notabug?

Yes.  When sentence-end-double-space is nil on current master, this
text from the original report:

xxxxx xx x xxxxxxx xxxx xxxx xxxxxx xxx xxxxxxx xxxxxxxxxx. xxxx xx x
xxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xx x xxxxxxx
xxxxxxxxxxxxxxxx. xxx xxxxxxxxxx xxxxx x xxxxxxxx xxxxxx xxx xxxx
xxx'x xxx xxx xxxx xxxxx xxxxxxxx xxxxx.

Fills to this:

xxxxx xx x xxxxxxx xxxx xxxx xxxxxx xxx xxxxxxx xxxxxxxxxx. xxxx xx x
xxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xx x xxxxxxx xxxxxxxxxxxxxxxx.
xxx xxxxxxxxxx xxxxx x xxxxxxxx xxxxxx xxx xxxx xxx'x xxx xxx xxxx
xxxxx xxxxxxxx xxxxx.

This is what was indicated as expected in the original report.  I'm
therefore closing this bug.

Thanks,
Stefan Kangas


This bug report was last modified 5 years and 361 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.