* opening portions of large file
@ 2005-03-14 15:33 Sébastien Kirche
2005-03-15 13:06 ` drkm
0 siblings, 1 reply; 4+ messages in thread
From: Sébastien Kirche @ 2005-03-14 15:33 UTC (permalink / raw)
Hi,
i have googled a bit but i have found no reference regarding the partial
opening of large files (read: without loading the whole file in memory).
I know that for a while Emacs 21.3 (? at least CVS version) has no more the
128 MB limitation about buffer size. But what about opening a large file,
say several hundreds of megabytes ?
I suppose that if the file size exceeds the main memory it will cause at
best lots of memory swapping and must be quite slow.
Is there any mode designed to load a large file by chunks corresponding to
the displayed buffer (à la UltraEdit-32 in the Windows world) ?
Regards.
--
Sébastien Kirche
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: opening portions of large file
2005-03-14 15:33 opening portions of large file Sébastien Kirche
@ 2005-03-15 13:06 ` drkm
2005-03-15 15:32 ` Sébastien Kirche
2005-03-15 16:21 ` Thien-Thi Nguyen
0 siblings, 2 replies; 4+ messages in thread
From: drkm @ 2005-03-15 13:06 UTC (permalink / raw)
Sébastien Kirche <sebastien.kirche.no@spam.free.fr.invalid> writes:
> Is there any mode designed to load a large file by chunks corresponding to
> the displayed buffer (à la UltraEdit-32 in the Windows world) ?
If you just want to open a specific region of a file, it's easy to
write a command to read the filename and the region bounds, an call
`dd(1)' to extract this region into an temporary file, an add
buffer-locally a generated function to `after-save-hook' to use
`dd(1)' to reinject the temporary file in the initial file.
If you want to Emacs decides automatically to use such a technique
depending of the file size, determining itself the chunks size,
displays the size in a transparent way (so the user never see he or
she are editing chunks), guarantees tools like Font Lock, Semantic or
nXML validation code to works well, ..., it's, well, IMHO, a quite
more difficult.
--drkm
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: opening portions of large file
2005-03-15 13:06 ` drkm
@ 2005-03-15 15:32 ` Sébastien Kirche
2005-03-15 16:21 ` Thien-Thi Nguyen
1 sibling, 0 replies; 4+ messages in thread
From: Sébastien Kirche @ 2005-03-15 15:32 UTC (permalink / raw)
Le 15 Mar 2005, drkm vraute :
> If you want to Emacs decides automatically to use such a technique
> depending of the file size, determining itself the chunks size,
> displays the size in a transparent way (so the user never see he or
> she are editing chunks), guarantees tools like Font Lock, Semantic or
> nXML validation code to works well, ..., it's, well, IMHO, a quite
> more difficult.
Ok.
> --drkm
Weird, that remembers me someone... but who ? ;)
--
Sébastien Kirche
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: opening portions of large file
2005-03-15 13:06 ` drkm
2005-03-15 15:32 ` Sébastien Kirche
@ 2005-03-15 16:21 ` Thien-Thi Nguyen
1 sibling, 0 replies; 4+ messages in thread
From: Thien-Thi Nguyen @ 2005-03-15 16:21 UTC (permalink / raw)
drkm <usenet@fgeorges.org> writes:
> it's, well, IMHO, a quite
> more difficult.
the general solution is "database-mediated" i/o, which is indeed more
difficult, but not out of reach. once EDB turns the corner to fully (or
at least, "maximally w/in reason") declarative schema design, file slice
editing will fall out of the mix for free. for now, there is bindat.el
and forms.el (building on these is basically where EDB is heading) to
ri{p,ff} off...
thi
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2005-03-15 16:21 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-03-14 15:33 opening portions of large file Sébastien Kirche
2005-03-15 13:06 ` drkm
2005-03-15 15:32 ` Sébastien Kirche
2005-03-15 16:21 ` Thien-Thi Nguyen
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 read-only IMAP folder(s) and NNTP newsgroup(s).