The advantage of multiple buffers is that the downloaded files can be
viewed straight away, with no further copying.
I am not sure what you're really trying to do here.
Is your goal to ultimately have each message in a separate buffer?
Or is the goal to write them into files on disk?
>> I agree that downloading a lot of files will be silly. Perhaps I will
>> set up a pool of 20 or so buffers for downloads and block or error
>> when the pool is exhausted.
>
> My guess is that the possible performance hit you'd get by using 100 or
> 1000 buffers would still be insignificant.
>
>
Richard Stallman <[EMAIL PROTECTED]> writes:
> The number of buffers would be 1:1 with the number of files being
> downloaded. Aggregating the data is the problem I was trying to avoid.
> Because the downloads all finish at different times it makes sorting
> the data difficult.
>
>
> I agree that downloading a lot of files will be silly. Perhaps I will
> set up a pool of 20 or so buffers for downloads and block or error
> when the pool is exhausted.
My guess is that the possible performance hit you'd get by using 100 or
1000 buffers would still be insignificant.
St
The number of buffers would be 1:1 with the number of files being
downloaded. Aggregating the data is the problem I was trying to avoid.
Because the downloads all finish at different times it makes sorting
the data difficult.
When you say "sorting the data", do you mean that litera
Nic Ferrier <[EMAIL PROTECTED]> writes:
> Richard Stallman <[EMAIL PROTECTED]> writes:
[...]
>> Creating that many buffers might cause various sorts of overload
>> for Emacs. Can't you use one buffer for all the information,
>> and sort it out at the end?
[...]
> I agree that downloading a lo
Richard Stallman <[EMAIL PROTECTED]> writes:
> But IMAP can be asked to download lots of files at once and will be
> chunking them all. So I wanted to have lots of chunk buffers, one for
> each file transfer. When the files are downloaded they can be put
> straight into the correct
But IMAP can be asked to download lots of files at once and will be
chunking them all. So I wanted to have lots of chunk buffers, one for
each file transfer. When the files are downloaded they can be put
straight into the correct mode for displaying the file.
So there might be
Luc Teirlinck <[EMAIL PROTECTED]> writes:
> Nic Ferrier wrote:
>
>So I wanted to hide them from the user.
>
> Which does not answer a question already asked by Miles: why is
> starting their names with a space not good enough?
Sorry, didn't see that from miles. Not sure why.
Fantastic! I nev
Nic Ferrier wrote:
So I wanted to hide them from the user.
Which does not answer a question already asked by Miles: why is
starting their names with a space not good enough?
Sincerely,
Luc.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://
")
Message-ID: <[EMAIL PROTECTED]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Richard Stallman <[EMAIL PROTECTED]> writes:
> Something that would help a great deal is if one could create a buffer
> that was hidden, ie: it did not ordinarily appear in the buffer list
>
Something that would help a great deal is if one could create a buffer
that was hidden, ie: it did not ordinarily appear in the buffer list
and was not returned by a call to:
(get-buffer buffername)
Why do you think this is necessary?
I don't see what problem this would solve.
On 6/9/05, Nic Ferrier <[EMAIL PROTECTED]> wrote:
> Something that would help a great deal is if one could create a buffer
> that was hidden, ie: it did not ordinarily appear in the buffer list
> and was not returned by a call to:
>
> (get-buffer buffername)
Why?
The goal of not annoying use
Related to the discussion about threads is the issue of making
asycnhronous network programming in emacs easier.
I wrote an article on how I tried and failed (for now) to write a good
async IMAP library in elisp:
http://www.tapsellferrier.co.uk/nics-articles/imapua-failure.html
One of the thi
14 matches
Mail list logo
