* Re: Group, Summary buffers: End of line contain whitespaces [not found] <87abfkmuko.fsf@jondo.cante.net> @ 2008-08-13 8:29 ` Katsumi Yamaoka 2008-08-13 18:56 ` Reiner Steib 2008-08-22 15:52 ` Ted Zlatanov 0 siblings, 2 replies; 31+ messages in thread From: Katsumi Yamaoka @ 2008-08-13 8:29 UTC (permalink / raw) To: Jari Aalto; +Cc: bugs, ding >>>>> Jari Aalto wrote: > With setting: > (setq-default show-trailing-whitespace t) > The *Group* and **Summary* buffers seem to have EOL whitespaces. It > would be nice if these could be taken cared of (consider: copy/pasting > the buffer contents/areas elsewhere). > [2. Summary buffer --- image/png; gnus-1.png] => http://www.jpl.org/tmp/gnus-1.png > [3. Group buffer --- image/png; gnus-2.png] => http://www.jpl.org/tmp/gnus-2.png It is due to the space character that the default values of the following variables contain: `gnus-group-line-format' "%M\%S\%p\%P\%5y:%B%(%g%)%l %O\n" --- Gnus v5.11 "%M\%S\%p\%P\%5y:%B%(%g%)%O\n" --- Gnus v5.13 `gnus-summary-line-format' "%U%R%z%I%(%[%4L: %-23,23f%]%) %s\n" --- Gnus v5.11 and v5.13 You use Gnus v5.11. So, for *Group* you can simply replace it with that of Gnus v5.13 since GroupLens (i.e. %l) is no longer available. For *Summary*, though it doesn't look good for me, this will work: (setq gnus-summary-line-format "%U%R%z%I%(%[%4L: %-23,23f%]%)%s\n") I'm not sure what is the best way but I have two ideas. One is to remove trailing whitespace after the group buffer and the summary buffer have been generated or updated: --8<---------------cut here---------------start------------->8--- (add-hook 'gnus-group-prepare-hook (lambda nil (save-excursion (goto-char (point-min)) (while (re-search-forward " +$" nil t) (delete-region (match-beginning 0) (match-end 0)))))) (add-hook 'gnus-group-update-group-hook (lambda nil (end-of-line) (skip-chars-backward " ") (delete-region (point) (point-at-eol)))) (add-hook 'gnus-summary-prepare-hook (lambda nil (while (re-search-forward " +$" nil t) (delete-region (match-beginning 0) (match-end 0))) (goto-char (point-min)))) --8<---------------cut here---------------end--------------->8--- The other is to make the format-spec (which is a Lisp form) remove trailing whitespace by itself: --8<---------------cut here---------------start------------->8--- --- gnus-spec.el~ 2008-03-02 21:50:11 +0000 +++ gnus-spec.el 2008-08-13 08:25:45 +0000 @@ -703,7 +703,14 @@ (when result (if dontinsert result - (cons 'insert result))) + `(progn + (insert ,@result) + (if (bolp) + (progn + (end-of-line 0) + (skip-chars-backward " ") + (delete-region (point) (point-at-eol)) + (forward-line 1)))))) (cond ((stringp result) result) ((consp result) --8<---------------cut here---------------end--------------->8--- Maybe the former is faster than the later. Before trying the later, you need to eval the form: (gnus-update-format-specifications t 'group 'summary) Regards, ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Group, Summary buffers: End of line contain whitespaces 2008-08-13 8:29 ` Group, Summary buffers: End of line contain whitespaces Katsumi Yamaoka @ 2008-08-13 18:56 ` Reiner Steib 2008-08-13 21:47 ` Jari Aalto 2008-08-22 15:52 ` Ted Zlatanov 1 sibling, 1 reply; 31+ messages in thread From: Reiner Steib @ 2008-08-13 18:56 UTC (permalink / raw) To: Jari Aalto, ding On Wed, Aug 13 2008, Katsumi Yamaoka wrote: >>>>>> Jari Aalto wrote: >> (setq-default show-trailing-whitespace t) [...] > I'm not sure what is the best way but I have two ideas. One is > to remove trailing whitespace after the group buffer and the summary > buffer have been generated or updated: [...] Why not just set show-trailing-whitespace to nil buffer-locally? Bye, Reiner. -- ,,, (o o) ---ooO-(_)-Ooo--- | PGP key available | http://rsteib.home.pages.de/ ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Group, Summary buffers: End of line contain whitespaces 2008-08-13 18:56 ` Reiner Steib @ 2008-08-13 21:47 ` Jari Aalto 2008-08-15 16:31 ` jidanni 2008-08-19 11:48 ` Miles Bader 0 siblings, 2 replies; 31+ messages in thread From: Jari Aalto @ 2008-08-13 21:47 UTC (permalink / raw) To: ding Reiner Steib <reinersteib+gmane@imap.cc> writes: > On Wed, Aug 13 2008, Katsumi Yamaoka wrote: > >>>>>>> Jari Aalto wrote: >>> (setq-default show-trailing-whitespace t) > [...] >> I'm not sure what is the best way but I have two ideas. One is >> to remove trailing whitespace after the group buffer and the summary >> buffer have been generated or updated: [...] > > Why not just set show-trailing-whitespace to nil buffer-locally? Copying the files from buffer with copy/paste is still a problem with trailing spaces. It would be best if buffer had none. Jari ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Group, Summary buffers: End of line contain whitespaces 2008-08-13 21:47 ` Jari Aalto @ 2008-08-15 16:31 ` jidanni 2008-08-19 11:48 ` Miles Bader 1 sibling, 0 replies; 31+ messages in thread From: jidanni @ 2008-08-15 16:31 UTC (permalink / raw) To: ding > Why not just set show-trailing-whitespace to nil buffer-locally? Shame on such "sweep the problem under the rug" thoughts. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Group, Summary buffers: End of line contain whitespaces 2008-08-13 21:47 ` Jari Aalto 2008-08-15 16:31 ` jidanni @ 2008-08-19 11:48 ` Miles Bader 1 sibling, 0 replies; 31+ messages in thread From: Miles Bader @ 2008-08-19 11:48 UTC (permalink / raw) To: ding Jari Aalto <jari.aalto@cante.net> writes: >> Why not just set show-trailing-whitespace to nil buffer-locally? > > Copying the files from buffer with copy/paste is still a problem with > trailing spaces. It would be best if buffer had none. If you don't like it, you can always use "M-x delete-trailing-whitespace" after pasting. -Miles -- Year, n. A period of three hundred and sixty-five disappointments. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Group, Summary buffers: End of line contain whitespaces 2008-08-13 8:29 ` Group, Summary buffers: End of line contain whitespaces Katsumi Yamaoka 2008-08-13 18:56 ` Reiner Steib @ 2008-08-22 15:52 ` Ted Zlatanov 2008-08-27 23:01 ` Miles Bader 1 sibling, 1 reply; 31+ messages in thread From: Ted Zlatanov @ 2008-08-22 15:52 UTC (permalink / raw) To: ding On Wed, 13 Aug 2008 17:29:40 +0900 Katsumi Yamaoka <yamaoka@jpl.org> wrote: KY> The other is to make the format-spec (which is a Lisp form) remove KY> trailing whitespace by itself: KY> --- gnus-spec.el~ 2008-03-02 21:50:11 +0000 KY> +++ gnus-spec.el 2008-08-13 08:25:45 +0000 KY> @@ -703,7 +703,14 @@ KY> (when result KY> (if dontinsert KY> result KY> - (cons 'insert result))) KY> + `(progn KY> + (insert ,@result) KY> + (if (bolp) KY> + (progn KY> + (end-of-line 0) KY> + (skip-chars-backward " ") KY> + (delete-region (point) (point-at-eol)) KY> + (forward-line 1)))))) KY> (cond ((stringp result) KY> result) KY> ((consp result) I think this is the right solution. No one has explained why we need the trailing spaces AFAIK. Ted ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Group, Summary buffers: End of line contain whitespaces 2008-08-22 15:52 ` Ted Zlatanov @ 2008-08-27 23:01 ` Miles Bader 2008-08-28 13:51 ` Ted Zlatanov 0 siblings, 1 reply; 31+ messages in thread From: Miles Bader @ 2008-08-27 23:01 UTC (permalink / raw) To: Ted Zlatanov; +Cc: ding Ted Zlatanov <tzz@lifelogs.com> writes: > I think this is the right solution. No one has explained why we need > the trailing spaces AFAIK. I don't think anyone has claimed they're _needed_. It's more than they aren't particularly harmful, and going to great lengths to avoid them is silly. -Miles -- Advice, n. The smallest current coin. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Group, Summary buffers: End of line contain whitespaces 2008-08-27 23:01 ` Miles Bader @ 2008-08-28 13:51 ` Ted Zlatanov 2008-08-29 11:15 ` Reiner Steib ` (2 more replies) 0 siblings, 3 replies; 31+ messages in thread From: Ted Zlatanov @ 2008-08-28 13:51 UTC (permalink / raw) To: ding On Thu, 28 Aug 2008 08:01:56 +0900 Miles Bader <miles@gnu.org> wrote: MB> Ted Zlatanov <tzz@lifelogs.com> writes: >> I think this is the right solution. No one has explained why we need >> the trailing spaces AFAIK. MB> I don't think anyone has claimed they're _needed_. It's more than they MB> aren't particularly harmful, and going to great lengths to avoid them is MB> silly. I don't think it's silly: we're producing unneeded data for no clear purpose, and there's no harm in removing it. If so, it should be removed. I can do it unless someone explains why I shouldn't. Ted ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Group, Summary buffers: End of line contain whitespaces 2008-08-28 13:51 ` Ted Zlatanov @ 2008-08-29 11:15 ` Reiner Steib 2008-08-29 15:12 ` bugs and features (was: Group, Summary buffers: End of line contain whitespaces) Ted Zlatanov 2008-08-29 13:51 ` Group, Summary buffers: End of line contain whitespaces Ted Zlatanov 2008-08-29 15:31 ` Daiki Ueno 2 siblings, 1 reply; 31+ messages in thread From: Reiner Steib @ 2008-08-29 11:15 UTC (permalink / raw) To: ding On Thu, Aug 28 2008, Ted Zlatanov wrote: > On Thu, 28 Aug 2008 08:01:56 +0900 Miles Bader <miles@gnu.org> wrote: > > MB> Ted Zlatanov <tzz@lifelogs.com> writes: >>> I think this is the right solution. No one has explained why we need >>> the trailing spaces AFAIK. > > MB> I don't think anyone has claimed they're _needed_. It's more than they > MB> aren't particularly harmful, and going to great lengths to avoid them is > MB> silly. > > I don't think it's silly: we're producing unneeded data for no clear > purpose, and there's no harm in removing it. If so, it should be > removed. I can do it unless someone explains why I shouldn't. IMHO it's a minor cosmetic "problem". There are dozens of real bugs that are more important to fix: I have ~200 ticked articles in ding and more in gnus.gnus-bug and gmane.emacs.*. Most of them are bug reports for Gnus. I hoped to be able to at least forward them to the Emacs bug tracker. AFAIK, there's not Emacs/Gnus function to do this conveniently yet [1]. So, if you think is worth to care about this trailing whitespace in the Summary buffer, I won't object. But I think there's much more useful and important work to do. Bye, Reiner. [1] Cf. http://thread.gmane.org/gmane.emacs.devel/93575/focus=94338 http://thread.gmane.org/gmane.emacs.devel/97827/focus=97932 -- ,,, (o o) ---ooO-(_)-Ooo--- | PGP key available | http://rsteib.home.pages.de/ ^ permalink raw reply [flat|nested] 31+ messages in thread
* bugs and features (was: Group, Summary buffers: End of line contain whitespaces) 2008-08-29 11:15 ` Reiner Steib @ 2008-08-29 15:12 ` Ted Zlatanov 2008-09-15 21:00 ` registry doc patch (was: bugs and features) Ted Zlatanov 0 siblings, 1 reply; 31+ messages in thread From: Ted Zlatanov @ 2008-08-29 15:12 UTC (permalink / raw) To: ding On Fri, 29 Aug 2008 13:15:51 +0200 Reiner Steib <reinersteib+gmane@imap.cc> wrote: RS> IMHO it's a minor cosmetic "problem". RS> There are dozens of real bugs that are more important to fix: I have RS> ~200 ticked articles in ding and more in gnus.gnus-bug and RS> gmane.emacs.*. Most of them are bug reports for Gnus. I hoped to be RS> able to at least forward them to the Emacs bug tracker. AFAIK, RS> there's not Emacs/Gnus function to do this conveniently yet [1]. I wish I could work on more issues: it's for lack of time and not for lack of interest that I've been less productive. Daiki Ueno's fix for IMAP also needs to be examined; that and Vitaly's IMAP and backend patches are a pretty major undertaking. I also need to write the gnus-registry documentation sometime this century. RS> So, if you think is worth to care about this trailing whitespace in RS> the Summary buffer, I won't object. But I think there's much more RS> useful and important work to do. I agree. But we had a patch, and it annoyed more than one person apparently. Ted ^ permalink raw reply [flat|nested] 31+ messages in thread
* registry doc patch (was: bugs and features) 2008-08-29 15:12 ` bugs and features (was: Group, Summary buffers: End of line contain whitespaces) Ted Zlatanov @ 2008-09-15 21:00 ` Ted Zlatanov 2008-09-16 9:17 ` registry doc patch Rupert Swarbrick 2008-09-16 12:30 ` Magnus Henoch 0 siblings, 2 replies; 31+ messages in thread From: Ted Zlatanov @ 2008-09-15 21:00 UTC (permalink / raw) To: ding [-- Attachment #1: Type: text/plain, Size: 541 bytes --] On Fri, 29 Aug 2008 10:12:06 -0500 Ted Zlatanov <tzz@lifelogs.com> wrote: TZ> I also need to write the gnus-registry documentation sometime this century. The unthinkable has happened. Attached is a patch to the docs to document the Gnus registry. I didn't commit it because I'd like some comments (it's a very quick read) and because the menu update screwed up the Gnus menus in it (I edited that out of the patch), so I am not sure if the menus are correct. It's been many years since I edited Texinfo so any hints are welcome. Ted [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: registry.gnus.texi.patch --] [-- Type: text/x-diff, Size: 8698 bytes --] Index: gnus.texi =================================================================== RCS file: /usr/local/cvsroot/gnus/texi/gnus.texi,v retrieving revision 7.305 diff -c -r7.305 gnus.texi *** gnus.texi 8 Sep 2008 21:29:47 -0000 7.305 --- gnus.texi 15 Sep 2008 20:50:27 -0000 *************** *** 22740,22745 **** --- 22209,22215 ---- * Fuzzy Matching:: What's the big fuzz? * Thwarting Email Spam:: Simple ways to avoid unsolicited commercial email. * Spam Package:: A package for filtering and processing spam. + * The Gnus Registry:: A package for tracking messages by Message-ID. * Other modes:: Interaction with other modes. * Various Various:: Things that are really various. @end menu *************** *** 26502,26507 **** --- 25972,26190 ---- Save table: (spam-stat-save) @end smallexample + @node The Gnus Registry + @section The Gnus Registry + + @cindex registry + @cindex split + @cindex track + + The Gnus registry is a package that tracks messages by their + Message-ID across all backends. This allows Gnus users to do several + cool things, be the envy of the locals, get free haircuts, and be + experts on world issues. Well, maybe not all of those, but the + features are pretty cool. + + Although they will be explained in detail shortly, here's a quick list + of said features in case your attention span is... never mind. + + @enumerate + + @item Split messages to their parent + This keeps discussions in the same group. You can use the subject and + the sender in addition to the Message-ID. Several strategies are + available. + + @item Store custom flags and keywords + The registry can store custom flags and keywords for a message. For + instance, you can mark a message ``To-Do'' this way and the flag will + persist whether the message is in the nnimap, nnml, nnmaildir, + etc. backends. + + @item Store arbitrary data + Through a simple ELisp API, the registry can remember any data for a + message. A built-in inverse map, when activated, allows quick lookups + of all messages matching a particular set of criteria. + + @end enumerate + + + @menu + * Setup:: + * Fancy splitting to parent:: + * Store custom flags and keywords:: + * Store arbitrary data:: + @end menu + + @node Setup + @subsection Setup + + Fortunately, setting up the Gnus registry is pretty easy: + + @lisp + (setq gnus-registry-max-entries 2500 + gnus-registry-use-long-group-names t) + + (gnus-registry-initialize) + @end lisp + + This adds registry saves to Gnus newsrc saves (which happen on exit + and when you press @kbd{s} from the @code{*Group*} buffer. It also + adds registry calls to article actions in Gnus (copy, move, etc.) so + it's not easy to undo the initialization. See + @code{gnus-registry-initialize} for the gory details. + + Here are other settings used by the author of the registry (understand + what they do before you copy them blindly). + + @lisp + (setq + gnus-registry-split-strategy 'majority + gnus-registry-ignored-groups '(("nntp" t) + ("nnrss" t) + ("spam" t) + ("train" t)) + gnus-registry-max-entries 500000 + gnus-registry-use-long-group-names t + gnus-registry-track-extra '(sender subject)) + @end lisp + + They say: keep a lot of messages around, use long group names, track + messages by sender and subject (not just parent Message-ID), and when + the registry splits incoming mail, use a majority rule to decide where + messages should go if there's more than one possibility. In addition, + the registry should ignore messages in groups that match ``nntp'', + ``nnrss'', ``spam'', or ``train.'' + + You are doubtless impressed by all this, but you ask: ``I am a Gnus + user, I customize to live. Give me more.'' Here you go, these are + the general settings. + + @defvar gnus-registry-unfollowed-groups + The groups that will not be followed by + @code{gnus-registry-split-fancy-with-parent}. They will still be + remembered by the registry. This is a list of regular expressions. + @end defvar + + @defvar gnus-registry-ignored-groups + The groups that will not be remembered by the registry. This is a + list of regular expressions, also available through Group/Topic + customization (so you can ignore or keep a specific group or a whole + topic). + @end defvar + + @defvar gnus-registry-use-long-group-names + Whether the registry will use long group names. It's recommended to + set this to t, although everything works if you don't. Future + functionality will require it. + @end defvar + + @defvar gnus-registry-max-entries + The number (an integer or nil for unlimited) of entries the registry + will keep. + @end defvar + + @defvar gnus-registry-cache-file + The file where the registry will be stored between Gnus sessions. + @end defvar + + @node Fancy splitting to parent + @subsection Fancy splitting to parent + + Simply put, this lets you put followup e-mail where it belongs. + + Every message has a Message-ID, which is unique, and the registry + remembers it. When the message is moved or copied, the registry will + notice this and offer the new group as a choice to the splitting + strategy. + + When a followup is made, usually it mentions the original message's + Message-ID in the headers. The registry knows this and uses that + mention to find the group where the original message lives. You only + have to put a rule like this: + + @lisp + (setq nnimap-my-split-fancy '(| + + ;; split to parent: you need this + (: gnus-registry-split-fancy-with-parent) + + ;; other rules, as an example + (: spam-split) + ;; default mailbox + "mail") + @end lisp + + in your fancy split setup. In addition, you may want to customize the + following variables. + + @defvar gnus-registry-track-extra + This is a list of symbols, so it's best to change it from the + Customize interface. By default it's nil, but you may want to track + subject and sender as well when splitting by parent. It may work + for you. It can be annoying if your mail flow is large and people + don't stick to the same groups. + @end defvar + + @defvar gnus-registry-split-strategy + This is a symbol, so it's best to change it from the Customize + interface. By default it's nil, but you may want to set it to + @code{'majority} or @code{'first} to split by sender or subject based + on the majority of matches or on the first found. + @end defvar + + @node Store custom flags and keywords + @subsection Store custom flags and keywords + + The registry lets you set custom flags and keywords per message. You + can use the Gnus->Registry Marks menu or the @kbd{M M x} keyboard + shortcuts, where @code{x} is the first letter of the mark's name. + + @defvar gnus-registry-marks + The custom marks that the registry can use. You can modify the + default list, if you like. If you do, you'll have to exit Emacs + before they take effect (you can also unload the registry and reload + it or evaluate the specific macros you'll need, but you probably don't + want to bother). Use the Customize interface to modify the list. + + By default this list has the Important, Work, Personal, To-Do, and + Later marks. They all have keyboard shortcuts like @kbd{M M i} for + Important, using the first letter. + @end defvar + + @defun gnus-registry-mark-article + Call this function to mark an article with a custom registry mark. It + will offer the available marks for completion. + @end defun + + @node Store arbitrary data + @subsection Store arbitrary data + + The registry has a simple API that uses a Message-ID as the key to + store arbitrary data (as long as it can be converted to a list for + storage). + + @defun gnus-registry-store-extra-entry (id key value) + Store @code{value} in the extra data key @code{key} for message + @code{id}. + @end defun + + @defun gnus-registry-delete-extra-entry (id key) + Delete the extra data key @code{key} for message @code{id}. + @end defun + + @defun gnus-registry-fetch-extra (id key) + Get the extra data key @code{key} for message @code{id}. + @end defun + + @defvar gnus-registry-extra-entries-precious + If any extra entries are previous, their presence will make the + registry keep the whole entry forever, even if there are no groups for + the Message-ID and if the size limit of the registry is reached. By + default this is just @code{'(marks)} so the custom registry marks are + precious. + @end defvar + @node Other modes @section Interaction with other modes ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: registry doc patch 2008-09-15 21:00 ` registry doc patch (was: bugs and features) Ted Zlatanov @ 2008-09-16 9:17 ` Rupert Swarbrick 2008-09-16 13:36 ` Ted Zlatanov 2008-09-16 12:30 ` Magnus Henoch 1 sibling, 1 reply; 31+ messages in thread From: Rupert Swarbrick @ 2008-09-16 9:17 UTC (permalink / raw) To: Ted Zlatanov; +Cc: ding [-- Attachment #1: Type: text/plain, Size: 557 bytes --] Ted Zlatanov <tzz@lifelogs.com> writes: > The unthinkable has happened. Attached is a patch to the docs to > document the Gnus registry. I'm afraid I don't know much texinfo, but I have read through it for spelling and grammar (and information!) and didn't find anything wrong. I wasn't going to send anything, but thought maybe a +1 for "this looks good" was worth having. Rupert P.S. When hitting C-u f, I got asked whether to strip the old subject. It seems I've not replied to a message with an "old subject" before. That's a really cool feature! [-- Attachment #2: Type: application/pgp-signature, Size: 314 bytes --] ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: registry doc patch 2008-09-16 9:17 ` registry doc patch Rupert Swarbrick @ 2008-09-16 13:36 ` Ted Zlatanov 0 siblings, 0 replies; 31+ messages in thread From: Ted Zlatanov @ 2008-09-16 13:36 UTC (permalink / raw) To: ding On Tue, 16 Sep 2008 10:17:27 +0100 Rupert Swarbrick <rswarbrick@googlemail.com> wrote: RS> Ted Zlatanov <tzz@lifelogs.com> writes: >> The unthinkable has happened. Attached is a patch to the docs to >> document the Gnus registry. RS> I'm afraid I don't know much texinfo, but I have read through it for RS> spelling and grammar (and information!) and didn't find anything RS> wrong. I wasn't going to send anything, but thought maybe a +1 for "this RS> looks good" was worth having. Great, thanks. The goal is to make it cover only what people really need to know; I can expand on anything you think was not well covered. RS> P.S. When hitting C-u f, I got asked whether to strip the old RS> subject. It seems I've not replied to a message with an "old subject" RS> before. That's a really cool feature! Yeah, it even knows about the AW: syntax used sometimes (in Germany IIRC). Ted ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: registry doc patch 2008-09-15 21:00 ` registry doc patch (was: bugs and features) Ted Zlatanov 2008-09-16 9:17 ` registry doc patch Rupert Swarbrick @ 2008-09-16 12:30 ` Magnus Henoch 2008-09-16 13:39 ` Ted Zlatanov 1 sibling, 1 reply; 31+ messages in thread From: Magnus Henoch @ 2008-09-16 12:30 UTC (permalink / raw) To: ding Ted Zlatanov <tzz@lifelogs.com> writes: > + @defvar gnus-registry-extra-entries-precious > + If any extra entries are previous, their presence will make the That should be "precious", I think. Magnus ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: registry doc patch 2008-09-16 12:30 ` Magnus Henoch @ 2008-09-16 13:39 ` Ted Zlatanov 2008-09-18 23:19 ` Katsumi Yamaoka 0 siblings, 1 reply; 31+ messages in thread From: Ted Zlatanov @ 2008-09-16 13:39 UTC (permalink / raw) To: ding On Tue, 16 Sep 2008 14:30:56 +0200 Magnus Henoch <mange@freemail.hu> wrote: MH> Ted Zlatanov <tzz@lifelogs.com> writes: >> + @defvar gnus-registry-extra-entries-precious >> + If any extra entries are previous, their presence will make the MH> That should be "precious", I think. Thanks. With two looks, I'll assume it's not horrible and commit my patch. Please let me know if you have corrections or it needs more detail anywhere. Thanks Ted ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: registry doc patch 2008-09-16 13:39 ` Ted Zlatanov @ 2008-09-18 23:19 ` Katsumi Yamaoka 2008-09-19 16:19 ` Ted Zlatanov 0 siblings, 1 reply; 31+ messages in thread From: Katsumi Yamaoka @ 2008-09-18 23:19 UTC (permalink / raw) To: ding [-- Attachment #1: Type: text/plain, Size: 751 bytes --] >>>>> Ted Zlatanov wrote: > Please let me know if you have corrections or it needs more detail > anywhere. Thank you for uploading the Gnus Registry manual. It will be very useful for those who want to start using the registry (I'm not an exception ;-). When having been translating the manual into Japanese[1], I found some oddities there. The menu entry had better be put in the `Top' node, too. Conventionally `t' and `nil' are quoted with @code{} at least in the Gnus manual (even though they aren't so in a doc string). Some Lisp symbols used in values of the gnus-registry- variables aren't quoted. Or they are quoted as if they are in Lisp forms. A patch is attached below. Regards, [1] http://cvs.m17n.org/viewcvs/root/gnus-doc-ja/ [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: Type: text/x-patch, Size: 3662 bytes --] --- gnus.texi~ 2008-09-16 21:41:21 +0000 +++ gnus.texi 2008-09-18 23:17:52 +0000 @@ -827,6 +827,7 @@ * Fuzzy Matching:: What's the big fuzz? * Thwarting Email Spam:: Simple ways to avoid unsolicited commercial email. * Spam Package:: A package for filtering and processing spam. +* The Gnus Registry:: A package for tracking messages by Message-ID. * Other modes:: Interaction with other modes. * Various Various:: Things that are really various. @@ -26606,13 +26607,13 @@ @defvar gnus-registry-use-long-group-names Whether the registry will use long group names. It's recommended to -set this to t, although everything works if you don't. Future +set this to @code{t}, although everything works if you don't. Future functionality will require it. @end defvar @defvar gnus-registry-max-entries -The number (an integer or nil for unlimited) of entries the registry -will keep. +The number (an integer or @code{nil} for unlimited) of entries the +registry will keep. @end defvar @defvar gnus-registry-cache-file @@ -26627,7 +26628,7 @@ Every message has a Message-ID, which is unique, and the registry remembers it. When the message is moved or copied, the registry will notice this and offer the new group as a choice to the splitting -strategy. +strategy. When a followup is made, usually it mentions the original message's Message-ID in the headers. The registry knows this and uses that @@ -26651,17 +26652,17 @@ @defvar gnus-registry-track-extra This is a list of symbols, so it's best to change it from the -Customize interface. By default it's nil, but you may want to track -subject and sender as well when splitting by parent. It may work -for you. It can be annoying if your mail flow is large and people -don't stick to the same groups. +Customize interface. By default it's @code{nil}, but you may want to +track @code{subject} and @code{sender} as well when splitting by parent. +It may work for you. It can be annoying if your mail flow is large and +people don't stick to the same groups. @end defvar @defvar gnus-registry-split-strategy This is a symbol, so it's best to change it from the Customize -interface. By default it's nil, but you may want to set it to -@code{'majority} or @code{'first} to split by sender or subject based -on the majority of matches or on the first found. +interface. By default it's @code{nil}, but you may want to set it to +@code{majority} or @code{first} to split by sender or subject based on +the majority of matches or on the first found. @end defvar @node Store custom flags and keywords @@ -26678,9 +26679,10 @@ it or evaluate the specific macros you'll need, but you probably don't want to bother). Use the Customize interface to modify the list. -By default this list has the Important, Work, Personal, To-Do, and -Later marks. They all have keyboard shortcuts like @kbd{M M i} for -Important, using the first letter. +By default this list has the @code{Important}, @code{Work}, +@code{Personal}, @code{To-Do}, and @code{Later} marks. They all have +keyboard shortcuts like @kbd{M M i} for Important, using the first +letter. @end defvar @defun gnus-registry-mark-article @@ -26712,7 +26714,7 @@ If any extra entries are precious, their presence will make the registry keep the whole entry forever, even if there are no groups for the Message-ID and if the size limit of the registry is reached. By -default this is just @code{'(marks)} so the custom registry marks are +default this is just @code{(marks)} so the custom registry marks are precious. @end defvar ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: registry doc patch 2008-09-18 23:19 ` Katsumi Yamaoka @ 2008-09-19 16:19 ` Ted Zlatanov 2008-09-23 19:18 ` Reiner Steib 0 siblings, 1 reply; 31+ messages in thread From: Ted Zlatanov @ 2008-09-19 16:19 UTC (permalink / raw) To: ding On Fri, 19 Sep 2008 08:19:17 +0900 Katsumi Yamaoka <yamaoka@jpl.org> wrote: >>>>>> Ted Zlatanov wrote: >> Please let me know if you have corrections or it needs more detail >> anywhere. KY> Thank you for uploading the Gnus Registry manual. It will be KY> very useful for those who want to start using the registry (I'm KY> not an exception ;-). When having been translating the manual KY> into Japanese[1], I found some oddities there. KY> The menu entry had better be put in the `Top' node, too. I thought I did that, oops. KY> Conventionally `t' and `nil' are quoted with @code{} at least in KY> the Gnus manual (even though they aren't so in a doc string). KY> Some Lisp symbols used in values of the gnus-registry- variables KY> aren't quoted. Or they are quoted as if they are in Lisp forms. KY> A patch is attached below. Thanks for catching all those issues. I applied your patch in your name to expedite things. Ted ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: registry doc patch 2008-09-19 16:19 ` Ted Zlatanov @ 2008-09-23 19:18 ` Reiner Steib 2008-09-24 0:37 ` Katsumi Yamaoka 0 siblings, 1 reply; 31+ messages in thread From: Reiner Steib @ 2008-09-23 19:18 UTC (permalink / raw) To: ding Hi, formating the gnus.texi with MAKEINFO=no fails: $ emacs -batch -q -no-site-file -l ./infohack.el -f batch-makeinfo gnus.texi [...] Formatting: Low-level interface to the spam-stat dictionary ... Formatting: The Gnus Registry ... Extraneous text at end of command line make: *** [gnus] Error 255 Could someone please fix this? Bye, Reiner. -- ,,, (o o) ---ooO-(_)-Ooo--- | PGP key available | http://rsteib.home.pages.de/ ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: registry doc patch 2008-09-23 19:18 ` Reiner Steib @ 2008-09-24 0:37 ` Katsumi Yamaoka 2008-09-24 6:45 ` Katsumi Yamaoka 2008-09-24 16:44 ` informat.el: `Info-split' split size (was: registry doc patch) Reiner Steib 0 siblings, 2 replies; 31+ messages in thread From: Katsumi Yamaoka @ 2008-09-24 0:37 UTC (permalink / raw) To: ding >>>>> Reiner Steib wrote: > Hi, > formating the gnus.texi with MAKEINFO=no fails: > $ emacs -batch -q -no-site-file -l ./infohack.el -f batch-makeinfo gnus.texi > [...] > Formatting: Low-level interface to the spam-stat dictionary ... > Formatting: The Gnus Registry ... > Extraneous text at end of command line > make: *** [gnus] Error 255 > Could someone please fix this? Fixed in the Gnus trunk. For texinfmt.el the @item command used in the @enumerate section seems not to allow argument, so I've modified the lines "@item TITLE\n" into "@item\nTITLE\n\n". BTW, with MAKEINFO=no the Gnus Info files are divided into 24 files (gnus, gnus-1, ..., gnus-23). Those are too small, aren't they? The threshold is hard-coded in `Info-split' (informat.el). A workaround I added to the Japanese edition of the Gnus Info is: --8<---------------cut here---------------start------------->8--- ;; Reduce the number of split Info files. (if (featurep 'xemacs) (if (load "informat.el" t t) (let* ((fn (symbol-function 'Info-split)) (fns (prin1-to-string fn))) (load "informat.elc" t t) (when (and (string-match "\\([\t\n ]+\\)50000\\([\t\n )]+\\)" fns) (condition-case nil (setq fn (byte-compile (read (replace-match "\\1200000\\2" nil nil fns)))) (error nil)) (fset 'Info-split fn))))) (require 'informat) (let* ((fn (symbol-function 'Info-split)) (fns (prin1-to-string fn))) (when (string-match "\\([\t\n ]+\\)50000\\([\t\n ]+\\)" fns) (condition-case nil (fset 'Info-split (read (replace-match "\\1200000\\2" nil nil fns))) (error (fset 'Info-split fn)))))) --8<---------------cut here---------------end--------------->8--- Regards, ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: registry doc patch 2008-09-24 0:37 ` Katsumi Yamaoka @ 2008-09-24 6:45 ` Katsumi Yamaoka 2008-09-24 16:45 ` Reiner Steib 2008-09-24 16:44 ` informat.el: `Info-split' split size (was: registry doc patch) Reiner Steib 1 sibling, 1 reply; 31+ messages in thread From: Katsumi Yamaoka @ 2008-09-24 6:45 UTC (permalink / raw) To: ding >>>>> Katsumi Yamaoka wrote: >>>>>> Reiner Steib wrote: >> formating the gnus.texi with MAKEINFO=no fails: [...] > Fixed in the Gnus trunk. I've installed another fix to infohack.el. The Gnus Info generated with MAKEINFO=no was unable to read using the recent `info' command. Regards, ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: registry doc patch 2008-09-24 6:45 ` Katsumi Yamaoka @ 2008-09-24 16:45 ` Reiner Steib 0 siblings, 0 replies; 31+ messages in thread From: Reiner Steib @ 2008-09-24 16:45 UTC (permalink / raw) To: ding On Wed, Sep 24 2008, Katsumi Yamaoka wrote: >>>>>> Katsumi Yamaoka wrote: >>>>>>> Reiner Steib wrote: >>> formating the gnus.texi with MAKEINFO=no fails: > [...] >> Fixed in the Gnus trunk. > > I've installed another fix to infohack.el. The Gnus Info generated > with MAKEINFO=no was unable to read using the recent `info' command. Thanks. Bye, Reiner. -- ,,, (o o) ---ooO-(_)-Ooo--- | PGP key available | http://rsteib.home.pages.de/ ^ permalink raw reply [flat|nested] 31+ messages in thread
* informat.el: `Info-split' split size (was: registry doc patch) 2008-09-24 0:37 ` Katsumi Yamaoka 2008-09-24 6:45 ` Katsumi Yamaoka @ 2008-09-24 16:44 ` Reiner Steib 2008-09-24 23:58 ` informat.el: `Info-split' split size Katsumi Yamaoka 1 sibling, 1 reply; 31+ messages in thread From: Reiner Steib @ 2008-09-24 16:44 UTC (permalink / raw) To: emacs-devel, Katsumi Yamaoka; +Cc: ding On Wed, Sep 24 2008, Katsumi Yamaoka wrote: > BTW, with MAKEINFO=no the Gnus Info files are divided into 24 > files (gnus, gnus-1, ..., gnus-23). Those are too small, aren't > they? The threshold is hard-coded in `Info-split' (informat.el). ,----[ <f1> f Info-split RET ] | Info-split is an interactive autoloaded Lisp function in `informat'. | (Info-split) | | Split an info file into an indirect file plus bounded-size subfiles. | Each subfile will be up to 50,000 characters plus one node. [...] `---- I think the threshold should not be hard-coded and it's default should be like makeinfo's so that we don't need such workarounds: > A workaround I added to the Japanese edition of the Gnus Info is: > > ;; Reduce the number of split Info files. > (if (featurep 'xemacs) > (if (load "informat.el" t t) > (let* ((fn (symbol-function 'Info-split)) > (fns (prin1-to-string fn))) > (load "informat.elc" t t) > (when (and (string-match "\\([\t\n ]+\\)50000\\([\t\n )]+\\)" fns) > (condition-case nil > (setq fn (byte-compile > (read (replace-match "\\1200000\\2" nil nil > fns)))) > (error nil)) > (fset 'Info-split fn))))) > (require 'informat) > (let* ((fn (symbol-function 'Info-split)) > (fns (prin1-to-string fn))) > (when (string-match "\\([\t\n ]+\\)50000\\([\t\n ]+\\)" fns) > (condition-case nil > (fset 'Info-split (read (replace-match "\\1200000\\2" nil nil fns))) > (error > (fset 'Info-split fn)))))) Bye, Reiner. -- ,,, (o o) ---ooO-(_)-Ooo--- | PGP key available | http://rsteib.home.pages.de/ ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: informat.el: `Info-split' split size 2008-09-24 16:44 ` informat.el: `Info-split' split size (was: registry doc patch) Reiner Steib @ 2008-09-24 23:58 ` Katsumi Yamaoka 2008-09-25 3:10 ` Eli Zaretskii 2008-09-25 23:10 ` Katsumi Yamaoka 0 siblings, 2 replies; 31+ messages in thread From: Katsumi Yamaoka @ 2008-09-24 23:58 UTC (permalink / raw) To: emacs-devel; +Cc: ding [-- Attachment #1: Type: text/plain, Size: 1536 bytes --] >>>>> Reiner Steib wrote: > On Wed, Sep 24 2008, Katsumi Yamaoka wrote: >> BTW, with MAKEINFO=no the Gnus Info files are divided into 24 >> files (gnus, gnus-1, ..., gnus-23). Those are too small, aren't >> they? The threshold is hard-coded in `Info-split' (informat.el). > ,----[ <f1> f Info-split RET ] >| Info-split is an interactive autoloaded Lisp function in `informat'. >| (Info-split) >| >| Split an info file into an indirect file plus bounded-size subfiles. >| Each subfile will be up to 50,000 characters plus one node. [...] > `---- > I think the threshold should not be hard-coded and it's default should > be like makeinfo's so that we don't need such workarounds: >> A workaround I added to the Japanese edition of the Gnus Info is: [...] >> (require 'informat) >> (let* ((fn (symbol-function 'Info-split)) >> (fns (prin1-to-string fn))) >> (when (string-match "\\([\t\n ]+\\)50000\\([\t\n ]+\\)" fns) >> (condition-case nil >> (fset 'Info-split (read (replace-match "\\1200000\\2" nil nil fns))) >> (error >> (fset 'Info-split fn))))) Thank you for following it up. How about the attached patch? While the threshold of makeinfo is 30000, I tried it with some texinfo files and reduced it a bit for `Info-split'. Now the command ``./configure; make MAKEINFO=no info'' performed in the Gnus trunk splits the Gnus Info into six files. (Note that loaddefs.el, i.e. ldefs-boot.el, should be updated if this patch is applied because of autoloading `Info-split-threshold'.) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: Type: text/x-diff, Size: 1732 bytes --] --- informat.el~ 2008-05-06 07:57:40 +0000 +++ informat.el 2008-09-24 23:54:45 +0000 @@ -153,9 +153,16 @@ \f ;;;###autoload +(defcustom Info-split-threshold 262144 + "The number of characters by which `Info-split' splits an info file." + :type 'integer + :group 'texinfo) + +;;;###autoload (defun Info-split () "Split an info file into an indirect file plus bounded-size subfiles. -Each subfile will be up to 50,000 characters plus one node. +Each subfile will be up to the number of characters that +`Info-split-threshold' specifies, plus one node. To use this command, first visit a large Info file that has a tag table. The buffer is modified into a (small) indirect info file which @@ -167,7 +174,7 @@ contains just the tag table and a directory of subfiles." (interactive) - (if (< (buffer-size) 70000) + (if (< (buffer-size) (+ 20000 Info-split-threshold)) (error "This is too small to be worth splitting")) (goto-char (point-min)) (search-forward "\^_") @@ -192,7 +199,7 @@ (narrow-to-region (point-min) (point)) (goto-char (point-min)) (while (< (1+ (point)) (point-max)) - (goto-char (min (+ (point) 50000) (point-max))) + (goto-char (min (+ (point) Info-split-threshold) (point-max))) (search-forward "\^_" nil 'move) (setq subfiles (cons (list (+ start chars-deleted) --- textmodes/texinfmt.el~ 2008-07-31 21:47:43 +0000 +++ textmodes/texinfmt.el 2008-09-24 23:54:45 +0000 @@ -166,7 +166,7 @@ (Info-tagify) (if nosplit nil - (if (> (buffer-size) 100000) + (if (> (buffer-size) (+ 50000 Info-split-threshold)) (progn (message (setq lastmessage "Splitting Info file...")) (Info-split)))) ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: informat.el: `Info-split' split size 2008-09-24 23:58 ` informat.el: `Info-split' split size Katsumi Yamaoka @ 2008-09-25 3:10 ` Eli Zaretskii 2008-09-25 4:01 ` Katsumi Yamaoka 2008-09-25 23:10 ` Katsumi Yamaoka 1 sibling, 1 reply; 31+ messages in thread From: Eli Zaretskii @ 2008-09-25 3:10 UTC (permalink / raw) To: Katsumi Yamaoka; +Cc: ding, emacs-devel > Date: Thu, 25 Sep 2008 08:58:06 +0900 > From: Katsumi Yamaoka <yamaoka@jpl.org> > Cc: ding@gnus.org > > > ,----[ <f1> f Info-split RET ] > >| Info-split is an interactive autoloaded Lisp function in `informat'. > >| (Info-split) > >| > >| Split an info file into an indirect file plus bounded-size subfiles. > >| Each subfile will be up to 50,000 characters plus one node. [...] > > `---- > > > I think the threshold should not be hard-coded and it's default should > > be like makeinfo's so that we don't need such workarounds: > > >> A workaround I added to the Japanese edition of the Gnus Info is: > [...] > >> (require 'informat) > >> (let* ((fn (symbol-function 'Info-split)) > >> (fns (prin1-to-string fn))) > >> (when (string-match "\\([\t\n ]+\\)50000\\([\t\n ]+\\)" fns) > >> (condition-case nil > >> (fset 'Info-split (read (replace-match "\\1200000\\2" nil nil fns))) > >> (error > >> (fset 'Info-split fn))))) > > Thank you for following it up. How about the attached patch? > While the threshold of makeinfo is 30000, I tried it with some ^^^^^ You mean 300000, right? ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: informat.el: `Info-split' split size 2008-09-25 3:10 ` Eli Zaretskii @ 2008-09-25 4:01 ` Katsumi Yamaoka 0 siblings, 0 replies; 31+ messages in thread From: Katsumi Yamaoka @ 2008-09-25 4:01 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel, ding >>>>> Eli Zaretskii wrote: >> While the threshold of makeinfo is 30000, I tried it with some > ^^^^^ > You mean 300000, right? Oops. You're right. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: informat.el: `Info-split' split size 2008-09-24 23:58 ` informat.el: `Info-split' split size Katsumi Yamaoka 2008-09-25 3:10 ` Eli Zaretskii @ 2008-09-25 23:10 ` Katsumi Yamaoka 1 sibling, 0 replies; 31+ messages in thread From: Katsumi Yamaoka @ 2008-09-25 23:10 UTC (permalink / raw) To: emacs-devel; +Cc: ding >>>>> Katsumi Yamaoka wrote: > While the threshold of makeinfo is 30000, I tried it with some no, that's 300000 to be accurate > texinfo files and reduced it a bit for `Info-split'. Now the > command ``./configure; make MAKEINFO=no info'' performed in the > Gnus trunk splits the Gnus Info into six files. > (Note that loaddefs.el, i.e. ldefs-boot.el, should be updated if > this patch is applied because of autoloading `Info-split-threshold'.) > --- informat.el~ 2008-05-06 07:57:40 +0000 > +++ informat.el 2008-09-24 23:54:45 +0000 [...] > +(defcustom Info-split-threshold 262144 > + "The number of characters by which `Info-split' splits an info file." > + :type 'integer > + :group 'texinfo) I've installed the fix with ``:version "23.1"''. Regards, ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Group, Summary buffers: End of line contain whitespaces 2008-08-28 13:51 ` Ted Zlatanov 2008-08-29 11:15 ` Reiner Steib @ 2008-08-29 13:51 ` Ted Zlatanov 2008-08-29 15:31 ` Daiki Ueno 2 siblings, 0 replies; 31+ messages in thread From: Ted Zlatanov @ 2008-08-29 13:51 UTC (permalink / raw) To: ding On Thu, 28 Aug 2008 08:51:00 -0500 Ted Zlatanov <tzz@lifelogs.com> wrote: TZ> I don't think it's silly: we're producing unneeded data for no clear TZ> purpose, and there's no harm in removing it. If so, it should be TZ> removed. I can do it unless someone explains why I shouldn't. I comitted Katsumi Yamaoka's patch, let me know if you see any issues. Ted ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Group, Summary buffers: End of line contain whitespaces 2008-08-28 13:51 ` Ted Zlatanov 2008-08-29 11:15 ` Reiner Steib 2008-08-29 13:51 ` Group, Summary buffers: End of line contain whitespaces Ted Zlatanov @ 2008-08-29 15:31 ` Daiki Ueno 2008-08-29 15:55 ` Ted Zlatanov 2 siblings, 1 reply; 31+ messages in thread From: Daiki Ueno @ 2008-08-29 15:31 UTC (permalink / raw) To: Ted Zlatanov; +Cc: ding Ted Zlatanov <tzz@lifelogs.com> writes: > On Thu, 28 Aug 2008 08:01:56 +0900 Miles Bader <miles@gnu.org> wrote: > > MB> Ted Zlatanov <tzz@lifelogs.com> writes: >>> I think this is the right solution. No one has explained why we need >>> the trailing spaces AFAIK. > > MB> I don't think anyone has claimed they're _needed_. It's more than they > MB> aren't particularly harmful, and going to great lengths to avoid them is > MB> silly. > > I don't think it's silly: we're producing unneeded data for no clear > purpose, and there's no harm in removing it. If so, it should be > removed. I can do it unless someone explains why I shouldn't. I also think that it's silly. After the patch applied, (gnus-parse-format "%A" '((?A "ABCDE " ?s))) => (concat "ABCDE ") (gnus-parse-format "%A" '((?A "ABCDE " ?s)) t) => "ABCDE" Future Gnus developers will be troubled with the difference of the results. Also, this change makes gnus-parse-simple-format specific for rendering *Group* and *Summary* lines. That's a layer breakage. I think Katsumi's first approach is even better. Regards, -- Daiki Ueno ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Group, Summary buffers: End of line contain whitespaces 2008-08-29 15:31 ` Daiki Ueno @ 2008-08-29 15:55 ` Ted Zlatanov 2008-08-30 5:07 ` Katsumi Yamaoka 0 siblings, 1 reply; 31+ messages in thread From: Ted Zlatanov @ 2008-08-29 15:55 UTC (permalink / raw) To: ding On Sat, 30 Aug 2008 00:31:24 +0900 Daiki Ueno <ueno@unixuser.org> wrote: DU> Ted Zlatanov <tzz@lifelogs.com> writes: >> On Thu, 28 Aug 2008 08:01:56 +0900 Miles Bader <miles@gnu.org> wrote: >> MB> Ted Zlatanov <tzz@lifelogs.com> writes: >>>> I think this is the right solution. No one has explained why we need >>>> the trailing spaces AFAIK. >> MB> I don't think anyone has claimed they're _needed_. It's more than they MB> aren't particularly harmful, and going to great lengths to avoid them is MB> silly. >> >> I don't think it's silly: we're producing unneeded data for no clear >> purpose, and there's no harm in removing it. If so, it should be >> removed. I can do it unless someone explains why I shouldn't. DU> I also think that it's silly. After the patch applied, DU> (gnus-parse-format "%A" '((?A "ABCDE " ?s))) DU> => (concat "ABCDE ") DU> (gnus-parse-format "%A" '((?A "ABCDE " ?s)) t) DU> => "ABCDE" DU> Future Gnus developers will be troubled with the difference of the DU> results. Also, this change makes gnus-parse-simple-format specific for DU> rendering *Group* and *Summary* lines. That's a layer breakage. DU> I think Katsumi's first approach is even better. Before I revert and apply the other patch, I'd like to hear what Katsumi thinks. I agree format and layer breakage is bad, and don't want to break more inadvertently. Thanks Ted ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Group, Summary buffers: End of line contain whitespaces 2008-08-29 15:55 ` Ted Zlatanov @ 2008-08-30 5:07 ` Katsumi Yamaoka 2008-08-30 9:33 ` Ted Zlatanov 0 siblings, 1 reply; 31+ messages in thread From: Katsumi Yamaoka @ 2008-08-30 5:07 UTC (permalink / raw) To: ding >>>>> In <864p53ke7n.fsf@lifelogs.com> >>>>> Ted Zlatanov <tzz@lifelogs.com> wrote: DU> I think Katsumi's first approach is even better. > Before I revert and apply the other patch, I'd like to hear what Katsumi > thinks. I agree format and layer breakage is bad, and don't want to > break more inadvertently. I hesitated to propose that one because it will not only make the Summary buffer generation slow a bit but also remove trailing space characters *unconditionally*. So I agree with Daiki and agree to revert the last change in gnus-spec.el. Regards, ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Group, Summary buffers: End of line contain whitespaces 2008-08-30 5:07 ` Katsumi Yamaoka @ 2008-08-30 9:33 ` Ted Zlatanov 0 siblings, 0 replies; 31+ messages in thread From: Ted Zlatanov @ 2008-08-30 9:33 UTC (permalink / raw) To: Katsumi Yamaoka; +Cc: ding On Sat, 30 Aug 2008 14:07:54 +0900 Katsumi Yamaoka <yamaoka@jpl.org> wrote: >>>>>> In <864p53ke7n.fsf@lifelogs.com> >>>>>> Ted Zlatanov <tzz@lifelogs.com> wrote: DU> I think Katsumi's first approach is even better. >> Before I revert and apply the other patch, I'd like to hear what Katsumi >> thinks. I agree format and layer breakage is bad, and don't want to >> break more inadvertently. KY> I hesitated to propose that one because it will not only make KY> the Summary buffer generation slow a bit but also remove trailing KY> space characters *unconditionally*. So I agree with Daiki and KY> agree to revert the last change in gnus-spec.el. All right, it's undone. We'll revisit this in 2020 :) Ted ^ permalink raw reply [flat|nested] 31+ messages in thread
end of thread, other threads:[~2008-09-25 23:10 UTC | newest] Thread overview: 31+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <87abfkmuko.fsf@jondo.cante.net> 2008-08-13 8:29 ` Group, Summary buffers: End of line contain whitespaces Katsumi Yamaoka 2008-08-13 18:56 ` Reiner Steib 2008-08-13 21:47 ` Jari Aalto 2008-08-15 16:31 ` jidanni 2008-08-19 11:48 ` Miles Bader 2008-08-22 15:52 ` Ted Zlatanov 2008-08-27 23:01 ` Miles Bader 2008-08-28 13:51 ` Ted Zlatanov 2008-08-29 11:15 ` Reiner Steib 2008-08-29 15:12 ` bugs and features (was: Group, Summary buffers: End of line contain whitespaces) Ted Zlatanov 2008-09-15 21:00 ` registry doc patch (was: bugs and features) Ted Zlatanov 2008-09-16 9:17 ` registry doc patch Rupert Swarbrick 2008-09-16 13:36 ` Ted Zlatanov 2008-09-16 12:30 ` Magnus Henoch 2008-09-16 13:39 ` Ted Zlatanov 2008-09-18 23:19 ` Katsumi Yamaoka 2008-09-19 16:19 ` Ted Zlatanov 2008-09-23 19:18 ` Reiner Steib 2008-09-24 0:37 ` Katsumi Yamaoka 2008-09-24 6:45 ` Katsumi Yamaoka 2008-09-24 16:45 ` Reiner Steib 2008-09-24 16:44 ` informat.el: `Info-split' split size (was: registry doc patch) Reiner Steib 2008-09-24 23:58 ` informat.el: `Info-split' split size Katsumi Yamaoka 2008-09-25 3:10 ` Eli Zaretskii 2008-09-25 4:01 ` Katsumi Yamaoka 2008-09-25 23:10 ` Katsumi Yamaoka 2008-08-29 13:51 ` Group, Summary buffers: End of line contain whitespaces Ted Zlatanov 2008-08-29 15:31 ` Daiki Ueno 2008-08-29 15:55 ` Ted Zlatanov 2008-08-30 5:07 ` Katsumi Yamaoka 2008-08-30 9:33 ` Ted Zlatanov
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).