From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/38656 Path: main.gmane.org!not-for-mail From: Daniel Pittman Newsgroups: gmane.emacs.gnus.general Subject: Re: Slight bug in the `gnus-use-correct-string-widths' implementation. Date: Fri, 07 Sep 2001 22:07:32 +1000 Organization: Not today, thank you, Mother. Message-ID: <87g09zrypn.fsf@inanna.rimspace.net> References: <87itf461hj.fsf@inanna.rimspace.net> NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Trace: main.gmane.org 1035174484 23636 80.91.224.250 (21 Oct 2002 04:28:04 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 21 Oct 2002 04:28:04 +0000 (UTC) Return-Path: Return-Path: Original-Received: (qmail 2311 invoked from network); 7 Sep 2001 12:07:51 -0000 Original-Received: from melancholia.rimspace.net (HELO melancholia.danann.net) (203.36.211.210) by gnus.org with SMTP; 7 Sep 2001 12:07:51 -0000 Original-Received: from localhost (melancholia.rimspace.net [203.36.211.210]) by melancholia.danann.net (Postfix) with ESMTP id 944AB2A839 for ; Fri, 7 Sep 2001 22:07:34 +1000 (EST) Original-Received: by localhost (Postfix, from userid 1000) id 537258203A; Fri, 7 Sep 2001 22:07:32 +1000 (EST) Original-To: ding@gnus.org In-Reply-To: (Jinhyok Heo's message of "Mon, 03 Sep 2001 10:32:00 +0900") X-Homepage: http://danann.net/ User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.5 (artichoke) Original-Lines: 69 Xref: main.gmane.org gmane.emacs.gnus.general:38656 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:38656 --=-=-= Content-Type: text/plain; charset=euc-kr Content-Transfer-Encoding: quoted-printable On Mon, 03 Sep 2001, Jinhyok Heo wrote: >>>>>> "DP" =3D=3D Daniel Pittman writes: >=20 > DP> I get the following header: >=20 > DP> [ 810 =B1=E8=BF=EB=C0=CF ]: presario 1700 lan ca= rd > DP> [ 20 +David S. Miller ]: Re: [UPDATE] 2.4.10-pre2 PCI64, API= changes README >=20 > 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'. >=20 > 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" "=B1=E8=BF=EB=C0=CF")) GNU Emacs =3D> 17 XEmacs =3D> 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... --=-=-= Content-Type: text/x-patch Content-Disposition: attachment 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)))) --=-=-= 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 --=-=-=--