[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Reading huge files
From: |
Mathias Dahl |
Subject: |
Re: Reading huge files |
Date: |
Thu, 11 Jan 2007 10:49:10 +0100 |
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/22.0.91 (windows-nt) |
Stefan Monnier <monnier@iro.umontreal.ca> writes:
> You'll indeed need something like that. I'd recommend to use `dd'
> rather than `split' or `head&tail'.
Thanks for the hint, I will take a look at that.
> But note that the problem is bigger than you think: the above will
> need to work with floating-point arguments (since fixnums suffer
> from the 2^28 limit) and the %d format also suffers from the 2^28
> limit (or 2^31 in Emacs-CVS).
After I read Eli's comment about the integer problem I added back the
head-tail version into the code (configurable) and then I started to
notice problemd with integers in various places, so I started to look
into using float, which solved some problems (I am using %.0f instead
of %d now in the call to `format', for example). There still seems to
be some problems though.
> That's another good reason to use
> `dd' since you can use a 1048576 block size and thus divide your
> large floats by 1048576 before turning them into fixnums.
Umm, okay... (I did not understand half of that, but I probably will
after looking into it.. :)
> Please just use
>
> (defvar vlf-mode-map
> (let ((map (make-sparse-keymap)))
> (define-key map [next] 'vlf-next)
> (define-key map [prior] 'vlf-prev)
> (define-key map "q" 'vlf-quit)
> map)
> "Keymap for `vlf-mode'.")
Ah, of course! :) The reason I do that is that when testing and adding
key bindings, I cannot simply reevaluate that defvar (because it won't
"bite"), so I use a function to set the map instead and then I can
reevaluate a call to this function.
> Also, wrt features, it'd probably be good to "slide more smoothly":
> e.g. always keep 2 or 3 blocks in the buffer at the same time so you
> can comfortably look at the text at the boundaries between blocks.
> Next step: use window-scroll-functions or jit-lock to detect when
> reaching one of the ends so that we can automatically load in the
> next consecutive block.
Aaargh, all these feature-requests make me crazy! :)
- Re: Reading huge files, (continued)
- Message not available
- Re: Reading huge files, Mathias Dahl, 2007/01/09
- Re: Reading huge files, Leonid Grinberg, 2007/01/09
- Message not available
- Re: Reading huge files, Mathias Dahl, 2007/01/09
- Re: Reading huge files, Eli Zaretskii, 2007/01/09
- Message not available
- Re: Reading huge files, Mathias Dahl, 2007/01/10
- Re: Reading huge files, Eli Zaretskii, 2007/01/10
- Message not available
- Re: Reading huge files, Giorgos Keramidas, 2007/01/10
- Re: Reading huge files, Stefan Monnier, 2007/01/11
- Re: Reading huge files,
Mathias Dahl <=
- Re: Reading huge files, Markus Triska, 2007/01/11
- Re: Reading huge files, Mathias Dahl, 2007/01/12
Message not available
Message not available