From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: Re: Emacs 21.4 maximum buffer size limit Date: Sat, 13 May 2006 11:59:36 +0300 Message-ID: References: <2eda38240605121909r14aa3057pe54bc91dc00ec9b2@mail.gmail.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1147510787 11857 80.91.229.2 (13 May 2006 08:59:47 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 13 May 2006 08:59:47 +0000 (UTC) Cc: bug-gnu-emacs@gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat May 13 10:59:46 2006 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1FepyT-0001hX-7p for geb-bug-gnu-emacs@m.gmane.org; Sat, 13 May 2006 10:59:45 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FepyS-0004vy-ST for geb-bug-gnu-emacs@m.gmane.org; Sat, 13 May 2006 04:59:44 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FepyO-0004vt-Iz for bug-gnu-emacs@gnu.org; Sat, 13 May 2006 04:59:40 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FepyM-0004vg-Hn for bug-gnu-emacs@gnu.org; Sat, 13 May 2006 04:59:39 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FepyM-0004vd-Dh for bug-gnu-emacs@gnu.org; Sat, 13 May 2006 04:59:38 -0400 Original-Received: from [192.114.186.20] (helo=nitzan.inter.net.il) by monty-python.gnu.org with esmtp (Exim 4.52) id 1Feq0H-0001wD-JS for bug-gnu-emacs@gnu.org; Sat, 13 May 2006 05:01:37 -0400 Original-Received: from HOME-C4E4A596F7 (IGLD-83-130-243-9.inter.net.il [83.130.243.9]) by nitzan.inter.net.il (MOS 3.7.3-GA) with ESMTP id DIS01393 (AUTH halo1); Sat, 13 May 2006 11:59:36 +0300 (IDT) Original-To: void In-reply-to: <2eda38240605121909r14aa3057pe54bc91dc00ec9b2@mail.gmail.com> (message from void on Fri, 12 May 2006 22:09:45 -0400) X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:15090 Archived-At: > Date: Fri, 12 May 2006 22:09:45 -0400 > From: void > > This message concerns a "bug" in the latest version of Emacs (as well as all > previous ones). I find myself restricted with the current maximum-buffer > limit of GNU Emacs. Trying to edit a 264MB text file (data from a geophysics > simulation) is impossible without first splitting same file into multiple > pieces and later rejoining them. I'm aware that this limitation stems from > an inherent restriction of elisp, but I kindly request an ugly (or elegant, > if possible) hack for future versions of Emacs. Both vim and nano don't seem > to have such a low file-size restriction, and I've heard XEmacs can handle > text files up to 1GB in size. As much as I love working with GNU Emacs, I > really don't want to have to learn the arcane commands of vim to work with > files of such magnitude. The next version of Emacs will double its max buffer size to 256MB, but 264MB will be still out of reach. The usual solution to this problem is to build a 64-bit version of Emacs (assuming you have a 64-bit host around).