From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.help Subject: Re: opening large files (few hundred meg) Date: Fri, 01 Feb 2008 13:04:48 +0200 Message-ID: References: <1f94fef6-a335-4ce5-8d4b-7e87025a28dc@e32g2000prn.googlegroups.com> <87r6g1esga.fsf@gmx.de> <200801312255.m0VMt701019096@powdermilk.math.berkeley.edu> NNTP-Posting-Host: lo.gmane.org X-Trace: ger.gmane.org 1201864012 820 80.91.229.12 (1 Feb 2008 11:06:52 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 1 Feb 2008 11:06:52 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Fri Feb 01 12:07:12 2008 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1JKtiC-0004rb-OW for geh-help-gnu-emacs@m.gmane.org; Fri, 01 Feb 2008 12:05:49 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JKthl-0003sD-0u for geh-help-gnu-emacs@m.gmane.org; Fri, 01 Feb 2008 06:05:09 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JKthT-0003rr-Iq for help-gnu-emacs@gnu.org; Fri, 01 Feb 2008 06:04:51 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JKthR-0003rb-Ld for help-gnu-emacs@gnu.org; Fri, 01 Feb 2008 06:04:50 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JKthR-0003rY-HF for help-gnu-emacs@gnu.org; Fri, 01 Feb 2008 06:04:49 -0500 Original-Received: from romy.inter.net.il ([213.8.233.24]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JKthQ-000494-Vf for help-gnu-emacs@gnu.org; Fri, 01 Feb 2008 06:04:49 -0500 Original-Received: from HOME-C4E4A596F7 (IGLD-84-229-212-108.inter.net.il [84.229.212.108]) by romy.inter.net.il (MOS 3.7.3-GA) with ESMTP id KCA83351 (AUTH halo1); Fri, 1 Feb 2008 13:04:30 +0200 (IST) In-reply-to: <200801312255.m0VMt701019096@powdermilk.math.berkeley.edu> (message from Ilya Zakharevich on Thu, 31 Jan 2008 14:55:07 -0800 (PST)) X-detected-kernel: by monty-python.gnu.org: FreeBSD 4.7-5.2 (or MacOS X 10.2-10.4) (2) X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:51147 Archived-At: > Date: Thu, 31 Jan 2008 14:55:07 -0800 (PST) > From: Ilya Zakharevich > > > 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.