* Slight bug in the `gnus-use-correct-string-widths' implementation. @ 2001-08-31 9:17 Daniel Pittman 2001-09-03 1:32 ` Jinhyok Heo 0 siblings, 1 reply; 8+ messages in thread From: Daniel Pittman @ 2001-08-31 9:17 UTC (permalink / raw) 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_ ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Slight bug in the `gnus-use-correct-string-widths' implementation. 2001-08-31 9:17 Slight bug in the `gnus-use-correct-string-widths' implementation Daniel Pittman @ 2001-09-03 1:32 ` Jinhyok Heo 2001-09-07 12:07 ` Daniel Pittman 0 siblings, 1 reply; 8+ messages in thread From: Jinhyok Heo @ 2001-09-03 1:32 UTC (permalink / raw) Cc: Daniel Pittman >>>>> "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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Slight bug in the `gnus-use-correct-string-widths' implementation. 2001-09-03 1:32 ` Jinhyok Heo @ 2001-09-07 12:07 ` Daniel Pittman 2001-09-07 12:12 ` Daniel Pittman ` (2 more replies) 0 siblings, 3 replies; 8+ messages in thread From: Daniel Pittman @ 2001-09-07 12:07 UTC (permalink / raw) [-- 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Slight bug in the `gnus-use-correct-string-widths' implementation. 2001-09-07 12:07 ` Daniel Pittman @ 2001-09-07 12:12 ` Daniel Pittman 2001-09-08 1:12 ` Jinhyok Heo 2001-09-08 7:55 ` Simon Josefsson 2 siblings, 0 replies; 8+ messages in thread From: Daniel Pittman @ 2001-09-07 12:12 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Slight bug in the `gnus-use-correct-string-widths' implementation. 2001-09-07 12:07 ` Daniel Pittman 2001-09-07 12:12 ` Daniel Pittman @ 2001-09-08 1:12 ` Jinhyok Heo 2001-09-08 7:55 ` Simon Josefsson 2 siblings, 0 replies; 8+ messages in thread From: Jinhyok Heo @ 2001-09-08 1:12 UTC (permalink / raw) Cc: ding >>>>> "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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Slight bug in the `gnus-use-correct-string-widths' implementation. 2001-09-07 12:07 ` Daniel Pittman 2001-09-07 12:12 ` Daniel Pittman 2001-09-08 1:12 ` Jinhyok Heo @ 2001-09-08 7:55 ` Simon Josefsson 2001-09-09 3:31 ` Michael Totschnig 2 siblings, 1 reply; 8+ messages in thread From: Simon Josefsson @ 2001-09-08 7:55 UTC (permalink / raw) Cc: ding 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Slight bug in the `gnus-use-correct-string-widths' implementation. 2001-09-08 7:55 ` Simon Josefsson @ 2001-09-09 3:31 ` Michael Totschnig 2001-09-10 1:13 ` Daniel Pittman 0 siblings, 1 reply; 8+ messages in thread From: Michael Totschnig @ 2001-09-09 3:31 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Slight bug in the `gnus-use-correct-string-widths' implementation. 2001-09-09 3:31 ` Michael Totschnig @ 2001-09-10 1:13 ` Daniel Pittman 0 siblings, 0 replies; 8+ messages in thread From: Daniel Pittman @ 2001-09-10 1:13 UTC (permalink / raw) [-- 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2001-09-10 1:13 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2001-08-31 9:17 Slight bug in the `gnus-use-correct-string-widths' implementation Daniel Pittman 2001-09-03 1:32 ` Jinhyok Heo 2001-09-07 12:07 ` Daniel Pittman 2001-09-07 12:12 ` Daniel Pittman 2001-09-08 1:12 ` Jinhyok Heo 2001-09-08 7:55 ` Simon Josefsson 2001-09-09 3:31 ` Michael Totschnig 2001-09-10 1:13 ` Daniel Pittman
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).