Re: Probable bug in nnimap

[Jeff Senn <senn@maya.com>]

Simon Josefsson <jas@pdc.kth.se> writes:

> Jeff Senn <senn@maya.com> writes:
> 
> > (I haven't looked at nnimap.el lately...) Is there some reason it
> > needs to be an integer as far as emacs is concerned (rather than a
> > string)? You can still do lexical sorting on (an non-interpreted)
> > string value. ...Might be somewhat less efficient, I guess...
> 
> Emacs doesn't care, Gnus does. It would take quite a rewrite of Gnus
> to make it use strings to reference articles, instead of integers. And
> IMHO the amount of work needed isn't worth it.

Ah...yes (duh!) 

Well how about this (in case someone is desperate and in this
situation): since it is much less likely that there is a _range_ of
uids bigger than 24-bits, you could have an offset (lowest known uid)
that was determined (and remembered) the first time that nnimap sees
the group.  Then you just need a emacs-safe add/subtract for numbers
represented as long strings of digits...

> But we never know what tricks Easter Gnus might perform. ;-)

True :-)

On a more philosophical note: it will be nice when(if?) this
dependence on a linear, numeric primary key for article identity goes
away in gnus... Indeed gnus started life as a nntp-news reader, but I
don't even use it for that anymore... email (in various flavors) and
the web-group stuff is far more useful day-to-day...

I would love (even more) a gnus that was my integrated browser/reader
of all kinds of collections of "documents" that are made up of
"attribute-values"...

-- 
-Jas