From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: void Newsgroups: gmane.emacs.bugs Subject: Emacs 21.4 maximum buffer size limit Date: Fri, 12 May 2006 22:09:45 -0400 Message-ID: <2eda38240605121909r14aa3057pe54bc91dc00ec9b2@mail.gmail.com> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1190465723==" X-Trace: sea.gmane.org 1147500074 23018 80.91.229.2 (13 May 2006 06:01:14 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 13 May 2006 06:01:14 +0000 (UTC) Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat May 13 08:01:11 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 1FenBY-0001Z5-DR for geb-bug-gnu-emacs@m.gmane.org; Sat, 13 May 2006 08:01:04 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FenBX-0005Pl-HU for geb-bug-gnu-emacs@m.gmane.org; Sat, 13 May 2006 02:01:03 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FejZk-00017u-Jr for bug-gnu-emacs@gnu.org; Fri, 12 May 2006 22:09:48 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FejZi-00017h-Vb for bug-gnu-emacs@gnu.org; Fri, 12 May 2006 22:09:48 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FejZi-00017e-QK for bug-gnu-emacs@gnu.org; Fri, 12 May 2006 22:09:46 -0400 Original-Received: from [64.233.184.230] (helo=wr-out-0506.google.com) by monty-python.gnu.org with esmtp (Exim 4.52) id 1Fejba-0000Up-89 for bug-gnu-emacs@gnu.org; Fri, 12 May 2006 22:11:42 -0400 Original-Received: by wr-out-0506.google.com with SMTP id 71so470256wri for ; Fri, 12 May 2006 19:09:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=P5W1B3jnlsljwurTq6w6NLVja5AWypS43Bphdk2jtvUomtXZm4llkEs0JC0d+liwrFk4yTNk+v7J0nKjP9TIK4E859lyyKohvA7SFae2srTdnfLVOuP0DHDoDjcVM1+cKyqS557W8bNnDhw0nu0xafyYuqKp/gITelkl4KKWpNc= Original-Received: by 10.54.117.5 with SMTP id p5mr2481895wrc; Fri, 12 May 2006 19:09:45 -0700 (PDT) Original-Received: by 10.54.78.9 with HTTP; Fri, 12 May 2006 19:09:45 -0700 (PDT) Original-To: bug-gnu-emacs@gnu.org X-Mailman-Approved-At: Sat, 13 May 2006 02:01:00 -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:15088 Archived-At: --===============1190465723== Content-Type: multipart/alternative; boundary="----=_Part_15811_20962666.1147486185698" ------=_Part_15811_20962666.1147486185698 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Greetings, This message concerns a "bug" in the latest version of Emacs (as well as al= l 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 geophysic= s 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 see= m 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. Thank you GNU. ------=_Part_15811_20962666.1147486185698 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Greetings,

This message concerns a "bug" in the latest ver= sion 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 split= ting same file into multiple pieces and later rejoining them. I'm aware tha= t this limitation stems from an inherent restriction of elisp, but I kindly= request an ugly (or elegant, if possible) hack for future versions of Emac= s. Both vim and nano don't seem to have such a low file-size restriction, a= nd 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 arcan= e commands of vim to work with files of such magnitude.

Thank you GNU.
------=_Part_15811_20962666.1147486185698-- --===============1190465723== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ bug-gnu-emacs mailing list bug-gnu-emacs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnu-emacs --===============1190465723==--