emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Pushing the `gnus-range-*' functions down into the C layer


From: Ted Zlatanov
Subject: Re: Pushing the `gnus-range-*' functions down into the C layer
Date: Thu, 09 Sep 2010 14:01:00 -0500
User-agent: Gnus/5.110011 (No Gnus v0.11) Emacs/24.0.50 (gnu/linux)

On Thu, 09 Sep 2010 17:16:56 +0200 Lars Magne Ingebrigtsen <address@hidden> 
wrote: 

LMI> Would anyone mind if I implemented the `gnus-range-*' functions in C for
LMI> Emacs 24?  Gnus spends significant time on group entry/exit doing range
LMI> handling/compressing/etc, and I think the functions are (slightly)
LMI> generally useful.

LMI> Gnus addresses articles by their number, so you have things like the
LMI> "marked" list of articles that looks like

LMI> (3 4 5 6 7 11 14 15 16 17 18)

LMI> (or something).  To save loading/saving time, these are stored in the
LMI> .newsrc.eld file as range structures, which look like this:

LMI> ((3 . 7) 11 (14 . 18))

LMI> To handle this, Gnus has a set of functions for computing
LMI> intersections/differences/etc on the range structures.  However, Emacs
LMI> Lisp isn't really fast at doing this, so if you exit from a group that
LMI> needs lots (I mean *lots*) of range handling, you get an annoying wait
LMI> while it sits there computing.

LMI> So I'm proposing implementing a set of useful functions in C, like
LMI> `range-memq', `range-add', `range-intersection' and stuff.

I think it's a good idea.  We've seen IMAP article numbers overflow
native Emacs ints at least once and it's been discussed a few times, e.g.:

http://article.gmane.org/gmane.emacs.gnus.general/65390/match=overflow

so maybe this API needs to support true 32-bit ints (perhaps through
doubles) as per RFC 3501.

Ted




reply via email to

[Prev in Thread] Current Thread [Next in Thread]