--- Begin Message ---
|
Subject: |
possible bug in fill-paragraph |
|
Date: |
Tue, 27 Jul 2010 01:10:37 -0700 |
Hello,
Here's a possible bug in fill-paragraph. In my twenty years of using
Emacs (and fill-paragraph), I've never come across something like this.
In addition to observing this bug with:
In GNU Emacs 22.2.1 (i486-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
of 2008-11-09 on raven, modified by Debian
running under:
Debian 5.0.5 Lenny
, I've reproduced it with:
GNU Emacs 23.2.1 (i386-mingw-nt5.1.2600) of 2010-05-08 on G41R2F1
running under:
Windows XP Professional
Build 2600.xpsp_sp3_gdr.100216-1514 (Service Pack 3)
Here are the gory details:
--------CUT HERE----BEGIN SECTION 1 OF 2--------
0. Invoke Emacs with "emacs -nw -q"
1. Start with this 3-line paragraph:
A former executive testified that David H. Brooks misused company
funds to buy a belt buckle encrusted with rubies, pornographic videos
for his son and prostitutes for his workers.
2. Invoke << C-u 20 C-x f >> with cursor positioned on first word "A".
3. Invoke << M-1 M-q >>.
4. Observe paragraph reformatted to this, incorrectly:
A former executive
testified that David
H. Brooks misused
company funds to buy
a belt buckle
encrusted with
rubies, pornographic
videos for his son
and prostitutes for
his workers.
i.e. with the 6th line ("encrusted with") taking up 21 columns
rather than 20 columns.
--------CUT HERE----BEGIN SECTION 2 OF 2--------
In GNU Emacs 22.2.1 (i486-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
of 2008-11-09 on raven, modified by Debian
configured using `configure '--build=i486-linux-gnu'
'--host=i486-linux-gnu' '--prefix=/usr' '--sharedstatedir=/var/lib'
'--libexecdir=/usr/lib' '--localstatedir=/var/lib'
'--infodir=/usr/share/info' '--mandir=/usr/share/man' '--with-pop=yes'
'--enable-locallisppath=/etc/emacs22:\
/etc/emacs:/usr/local/share/emacs/22.2/site-lisp:\
/usr/local/share/emacs/site-lisp:/usr/share/emacs/22.2/site-lisp:\
/usr/share/emacs/site-lisp:/usr/share/emacs/22.2/leim'
'--with-x=yes' '--with-x-toolkit=athena' '--with-toolkit-scroll-bars'
'build_alias=i486-linux-gnu' 'host_alias=i486-linux-gnu'
'CFLAGS=-DDEBIAN -g -O2' 'LDFLAGS=-g' 'CPPFLAGS=''
Important settings:
value of $LC_ALL: nil
value of $LC_COLLATE: nil
value of $LC_CTYPE: nil
value of $LC_MESSAGES: nil
value of $LC_MONETARY: nil
value of $LC_NUMERIC: nil
value of $LC_TIME: nil
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8
default-enable-multibyte-characters: t
Major mode: Fundamental
Minor modes in effect:
encoded-kbd-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
unify-8859-on-encoding-mode: t
utf-translate-cjk-mode: t
auto-compression-mode: t
line-number-mode: t
Recent input:
ESC x r e p o r t - e m a c s - b u g RET
Recent messages:
Loading debian-ispell...
Loading /var/cache/dictionaries-common/emacsen-ispell-default.el (source)...done
Loading debian-ispell...done
Loading /var/cache/dictionaries-common/emacsen-ispell-dicts.el (source)...done
Loading /etc/emacs/site-start.d/50dictionaries-common.el (source)...done
For information about GNU Emacs and the GNU system, type C-h C-a.
Loading emacsbug...
/usr/bin/mail is not an executable. Setting mail-interactive to t.
Loading regexp-opt...done
Loading emacsbug...done
--------CUT HERE----END SECTION 2 OF 2--------
If you need more information, please don't hesitate to ask.
Regards,
Eric
--
Eric De Mund
address@hidden
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#6738: possible bug in fill-paragraph |
|
Date: |
Mon, 02 Aug 2010 12:27:31 +0200 |
|
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) |
> It seems that the algorithm in justify-current-line doesn't work so well
> for a two-word line: it correctly calculates the number of additional
> space characters needed (ncols) but expects to fractionally distribute
> them, as it does in the other lines, so it adds more space, in this case
> wrongly. In such a situation, it suffices to just stick with ncols, as
> in the following patch (but I haven't tested this in other cases, so
> maybe it isn't the best fix).
I've changed the curr-fracspace calculation instead. Not sure why it
was doing a +1 on nspaces, and removing it fixes this problem (I'm not
sure it doesn't introduce another one, but at least my tests lead me to
think that's not the case).
Stefan
--- End Message ---