help-gnu-emacs
[Top][All Lists]
Advanced

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

Re: opening large files (few hundred meg)


From: Eli Zaretskii
Subject: Re: opening large files (few hundred meg)
Date: Fri, 01 Feb 2008 13:04:48 +0200

> Date: Thu, 31 Jan 2008 14:55:07 -0800 (PST)
> From: Ilya Zakharevich <address@hidden>
> 
> > The problem is not with the buffer size per se, it's with the fact
> > that Emacs needs to be able to address each byte of the file's text
> > with an Emacs integer data type, which is 29 bit wide on 32-bit
> > machines.
> 
> Are you sure?

See src/buffer.h, where it defines `struct buffer_text'.  It has these
members:

    EMACS_INT gpt;              /* Char pos of gap in buffer.  */
    EMACS_INT z;                /* Char pos of end of buffer.  */
    EMACS_INT gpt_byte;         /* Byte pos of gap in buffer.  */
    EMACS_INT z_byte;           /* Byte pos of end of buffer.  */
    EMACS_INT gap_size;         /* Size of buffer's gap.  */

and then `struct buffer' has this:

    /* Char position of point in buffer.  */
    EMACS_INT pt;
    /* Byte position of point in buffer.  */
    EMACS_INT pt_byte;
    /* Char position of beginning of accessible range.  */
    EMACS_INT begv;
    /* Byte position of beginning of accessible range.  */
    EMACS_INT begv_byte;
    /* Char position of end of accessible range.  */
    EMACS_INT zv;
    /* Byte position of end of accessible range.  */
    EMACS_INT zv_byte;

(On 32-bit machines, EMACS_INT is the 29-bit wide integer I was
talking about) So yes, I'm quite sure.

> I think it should be enough to address each char in the
> buffer, plus 2 "guard zones" immediately before and after the buffer,
> plus two "guard zones" at start and end of the file.
> 
> E.g., if the guard zone size is 1MB, then the "actual chunk of file"
> goes from offset 2M to offset 126M in the buffer; accessing anything
> from offset 1M to 2M "scrolls back" the chunk; accessing anything from
> offset 0 to 1M loads the chunk at start of file, etc.
> 
> Why won't this work?

Maybe it would, but I wasn't trying to describe some inherent
limitation of 32-bit machines, I was describing the limitation of the
_current_ Emacs implementation.  The OP wanted to know how can Emacs
be used to edit large files, not how Emacs can be modified.




reply via email to

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