Slight bug in the `gnus-use-correct-string-widths' implementation.

Slight bug in the `gnus-use-correct-string-widths' implementation.

[Daniel Pittman]

The implementation of `gnus-use-correct-string-widths' is really nifty
and stuff, but it's not /quite/ complete at the moment.

When I go into a summary buffer with the following format:

(setq gnus-summary-line-format "%U%R%[%(%4,-4uL %ub%-20,20f%)%]: %B%S\n")

This expands, in the evaluation of the code, to the following Lisp:

,----
| (let ((val (eval (gnus-summary-from-or-to-or-newsgroups gnus-tmp-header))))
|   (if (> (gnus-correct-length val) 20)
|     (gnus-correct-substring val 0 20) val))
`----

As far as I can see, this is the /only/ time that Gnus tries to limit
the length for the `%-20,20f' expansion in the code above.

Now, that isn't strictly correct because, deep inside the code
somewhere, the result of that function (6 columns) is padded with spaces
-- 17 of them.

I get the following header:

! [ 668  Brian J. Watson     ]: [PATCH 2.4.7] generic hash table implementation
! [ 251  Jason Thomas        ]: [PATCH] patch's for vmware 2.0.4 for use with linux-2.4.8 kernel
  [ 810  김용일                 ]: presario 1700 lan card
  [  20 +David S. Miller     ]: Re: [UPDATE] 2.4.10-pre2 PCI64, API changes README

So, it looks like something in the padding code for summary lines isn't
quite right, at least on XEmacs, for `gnus-use-correct-string-widths'.

      Daniel

-- 
It's a kind of war
Where I plant bombs inside
of myself
        -- Anne Sexton, _The Addict_

Re: Slight bug in the `gnus-use-correct-string-widths' implementation.

[Jinhyok Heo]

>>>>> "DP" == Daniel Pittman <daniel@rimspace.net> writes:

    DP> I get the following header:

    DP> [ 810  김용일                 ]: presario 1700 lan card
    DP> [  20 +David S. Miller     ]: Re: [UPDATE] 2.4.10-pre2 PCI64, API changes README

    DP> So, it looks like something in the padding code for summary lines isn't
    DP> quite right, at least on XEmacs, for `gnus-use-correct-string-widths'.

I think it's XEmacs' problem. This problem is occurred while using 2
byte charaters(e.g. Korean).

This subject was discussed on another thread on this list. GNU Emacs
users reported their summary lines were lined up correctly.

It's quite nagging to me because I usually send and receive Korean
mails.

-- 
|  Jinhyok Heo            mailto : novembre @ournature.org
|                         whoami : <http://ournature.org/~novembre/>
|  "We are still reaching for the sky. In the developed countries people
|  are coming back down, saying, `It's empty up there.'" --- a Ladakhi monk

Re: Slight bug in the `gnus-use-correct-string-widths' implementation.

[Daniel Pittman]

[-- Attachment #1: Type: text/plain, Size: 1978 bytes --]

On Mon, 03 Sep 2001, Jinhyok Heo wrote:
>>>>>> "DP" == Daniel Pittman <daniel@rimspace.net> writes:
> 
>     DP> I get the following header:
> 
>     DP> [ 810  김용일                 ]: presario 1700 lan card
>     DP> [  20 +David S. Miller     ]: Re: [UPDATE] 2.4.10-pre2 PCI64, API changes README
> 
>     DP> So, it looks like something in the padding code for summary
>     DP> lines isn't quite right, at least on XEmacs, for
>     DP> `gnus-use-correct-string-widths'.
> 
> I think it's XEmacs' problem. This problem is occurred while using 2
> byte charaters(e.g. Korean).

Right. That's it. I nailed the rat bastard of a thing. It's an
Emacs/XEmacs thing all right -- XEmacs behave the way you would expect,
GNU Emacs doesn't...

...as long as you expect coherent behavior from characters regardless of
their encoded length in bytes.

Basically, the problem is visible if you evaluate the following in both
XEmacs and GNU Emacs:

(length (format "%-10s" "김용일"))
GNU Emacs => 17
XEmacs => 20

So, GNU Emacs will eat *two* spaces of padding for a double width
character and one for a single width character.

XEmacs, on the other hand, eats one space of padding for each character
regardless of it's width. Thus, XEmacs gets three extra spaces added to
the output string.

This makes sense if you look at `format' as acting on a character level
and producing the expected string...

...but it fails when Gnus expects it to produce a fixed width (20
column, not character) string for double-width characters.


The GNU Emacs behavior is arguably correct, for some definition of
correct, if you assume that `format' is used to get fixed-width display
done...

[...]

> It's quite nagging to me because I usually send and receive Korean
> mails.

The attached patch fixes is, but it's probably quite ugly and offensive
to the eyes of the Gnus experts[1] so I trust that one of them will
rewrite it to be nicer...


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 1983 bytes --]

Index: gnus-spec.el
===================================================================
RCS file: /usr/local/cvsroot/gnus/lisp/gnus-spec.el,v
retrieving revision 6.12
diff -u -u -p -r6.12 gnus-spec.el
--- gnus-spec.el	2001/08/24 21:09:19	6.12
+++ gnus-spec.el	2001/09/07 11:59:58
@@ -372,6 +372,22 @@
        (if (equal val ,ignore-value)
 	   "" val))))
 
+(defun gnus-correct-pad-form (el pad-width)
+  "Return a form that pads EL to PAD-WIDTH accounting for multi-column
+characters correctly. This is because `format' may pad to columns or to
+characters when given a pad value."
+  (let ((pad (abs pad-width)))
+    (if (symbolp el)
+	`(let ((need (- ,pad (gnus-correct-length ,el))))
+	   (if (> need 0)
+	       (concat ,el (make-string need ?\ ))
+	     ,el))
+      `(let* ((val (eval ,el))
+	      (need (- ,pad (gnus-correct-length ,el))))
+	 (if (> need 0)
+	     (concat ,el (make-string need ?\ ))
+	   ,el)))))
+
 (defun gnus-parse-format (format spec-alist &optional insert)
   ;; This function parses the FORMAT string with the help of the
   ;; SPEC-ALIST and returns a list that can be eval'ed to return the
@@ -536,10 +552,14 @@
 	    (setq elem '("*" ?s))))
 	  (setq elem-type (cadr elem))
 	  ;; Insert the new format elements.
-	  (when pad-width
+	  (when (and pad-width
+		     (not (and (featurep 'xemacs)
+			       gnus-use-correct-string-widths)))
 	    (insert (number-to-string pad-width)))
 	  ;; Create the form to be evaled.
-	  (if (or max-width cut-width ignore-value)
+	  (if (or max-width cut-width ignore-value
+		  (and (featurep 'xemacs)
+		       gnus-use-correct-string-widths))
 	      (progn
 		(insert ?s)
 		(let ((el (car elem)))
@@ -553,6 +573,8 @@
 		    (setq el (gnus-tilde-cut-form el cut-width)))
 		  (when max-width
 		    (setq el (gnus-tilde-max-form el max-width)))
+		  (when pad-width
+		    (setq el (gnus-correct-pad-form el pad-width)))
 		  (push el flist)))
 	    (insert elem-type)
 	    (push (car elem) flist))))

[-- Attachment #3: Type: text/plain, Size: 316 bytes --]



Footnotes: 
[1]  I know this because /I/ think it's ugly and I write poor Lisp to
     start with. :)

-- 
Many people suffer with their thoughts, not knowing that revealing them on
paper, continuously over a two hour period, removes the stinging bitterness
which they are tightly wrapped within.
        -- Asmos

Re: Slight bug in the `gnus-use-correct-string-widths' implementation.

[Daniel Pittman]

On Fri, 07 Sep 2001, Daniel Pittman wrote:

[...]

> Basically, the problem is visible if you evaluate the following in
> both XEmacs and GNU Emacs:
> 
> (length (format "%-10s" "김용일"))
> GNU Emacs => 17
> XEmacs => 20

Oh, rats. Read '7 and 10' there, not 17 and 20. I forgot to adjust the
results down along with the width in the format when I stole it from my
testing.

That will teach me to fudge the results. ;)
        Daniel

-- 
This paperback is very interesting, but I find it will never replace a
hardcover book -- it makes a very poor doorstop.
        -- Alfred Hitchcock

Re: Slight bug in the `gnus-use-correct-string-widths' implementation.

[Jinhyok Heo]

>>>>> "DP" == Daniel Pittman <daniel@rimspace.net> writes:

    DP> The attached patch fixes is, but it's probably quite ugly and
    DP> offensive to the eyes of the Gnus experts[1] so I trust that
    DP> one of them will rewrite it to be nicer...

Wow, I've fixed the problem with your patch. :-)
I really appreciate it.

Can someone who has write access on CVS commit the patch?

-- 
|  Jinhyok Heo            mailto : novembre @ournature.org
|                         whoami : <http://ournature.org/~novembre/>
|  "We are still reaching for the sky. In the developed countries people
|  are coming back down, saying, `It's empty up there.'" --- a Ladakhi monk

Re: Slight bug in the `gnus-use-correct-string-widths' implementation.

[Simon Josefsson]

Daniel Pittman <daniel@rimspace.net> writes:

>> It's quite nagging to me because I usually send and receive Korean
>> mails.
>
> The attached patch fixes is, but it's probably quite ugly and offensive
> to the eyes of the Gnus experts[1] so I trust that one of them will
> rewrite it to be nicer...

I committed it, trusting that someone will send a patch cleaning it up
if necessary.

Re: Slight bug in the `gnus-use-correct-string-widths' implementation.

[Michael Totschnig]

Simon Josefsson <jas@extundo.com> wrote:

> Daniel Pittman <daniel@rimspace.net> writes:
>
>>> It's quite nagging to me because I usually send and receive Korean
>>> mails.
>>
>> The attached patch fixes is, but it's probably quite ugly and offensive
>> to the eyes of the Gnus experts[1] so I trust that one of them will
>> rewrite it to be nicer...
>
> I committed it, trusting that someone will send a patch cleaning it up
> if necessary.

I have the impression that this patch could be responsible for a
problem with specifications I observe since updating today:

If the format specification uses padding, it seems to be done always
to the right, for example I have "%3y: %(%-20g%)%l%M%S%p
" as gnus-group-line-format and since today I see
155: nntp+news.gnus.org:gnu.emacs.gnus   
7  : nntp+news.gnus.org:gnus.cvslog   
8  : nntp+news.gnus.org:gnus.ding   

instead of 
155: nntp+news.gnus.org:gnu.emacs.gnus   
  7: nntp+news.gnus.org:gnus.cvslog   
  8: nntp+news.gnus.org:gnus.ding   

Regards,

Michael

Re: Slight bug in the `gnus-use-correct-string-widths' implementation.

[Daniel Pittman]

[-- Attachment #1: Type: text/plain, Size: 813 bytes --]

On Sat, 08 Sep 2001, Michael Totschnig wrote:
> Simon Josefsson <jas@extundo.com> wrote:
> 
>> Daniel Pittman <daniel@rimspace.net> writes:
>>
>>>> It's quite nagging to me because I usually send and receive Korean
>>>> mails.
>>>
>>> The attached patch fixes is, but it's probably quite ugly and
>>> offensive to the eyes of the Gnus experts[1] so I trust that one of
>>> them will rewrite it to be nicer...
>>
>> I committed it, trusting that someone will send a patch cleaning it
>> up if necessary.
> 
> I have the impression that this patch could be responsible for a
> problem with specifications I observe since updating today:

Rats. You got me; I missed that glitch in my code. It now respects the
side that the padding should be on as well as the width of it, with the
attached patch.

         Daniel


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 1186 bytes --]

Index: gnus-spec.el
===================================================================
RCS file: /usr/local/cvsroot/gnus/lisp/gnus-spec.el,v
retrieving revision 6.13
diff -u -u -p -r6.13 gnus-spec.el
--- gnus-spec.el	2001/09/08 07:53:16	6.13
+++ gnus-spec.el	2001/09/10 01:12:00
@@ -376,16 +376,21 @@
   "Return a form that pads EL to PAD-WIDTH accounting for multi-column
 characters correctly. This is because `format' may pad to columns or to
 characters when given a pad value."
-  (let ((pad (abs pad-width)))
+  (let ((pad (abs pad-width))
+	(side (< 0 pad-width)))
     (if (symbolp el)
 	`(let ((need (- ,pad (gnus-correct-length ,el))))
 	   (if (> need 0)
-	       (concat ,el (make-string need ?\ ))
+	       (concat ,(when side '(make-string need ?\ ))
+		       ,el
+		       ,(when (not side) '(make-string need ?\ )))
 	     ,el))
       `(let* ((val (eval ,el))
 	      (need (- ,pad (gnus-correct-length ,el))))
 	 (if (> need 0)
-	     (concat ,el (make-string need ?\ ))
+	     (concat ,(when side '(make-string need ?\ ))
+		     ,el
+		     ,(when (not side) '(make-string need ?\ )))
 	   ,el)))))
 
 (defun gnus-parse-format (format spec-alist &optional insert)

[-- Attachment #3: Type: text/plain, Size: 94 bytes --]


-- 
When your hammer is C++, everything begins to look like a thumb.
        -- Simon Brooke